coderobe

Easy, just dox yourself first.

The main creator of this has been posting about his progress for months, personally I've been following its development ever since I first saw it. It's such a neat project that I can totally believe this being entirely organic growth.

If the "Get Started" button - the first thing you see on the website without scrolling - does nothing but yield a white page that asks for an email address, you're alienating a lot of interested users.

Attempted unjustified use of donation funds is not really any less questionable just because it didn't get past the treasurer - especially if the treasurer is, uh, constructively dismissed right after.

Holding off on the purchase after that event is the least they could've done.

>- Security: Can you read my customers' traffic?

Yes, anything that (re)terminates TLS will be able to - including this - and there is no way around it short of hosting it on-prem.

Marketing it as end-to-end security the way the author is doing is ... wrong.

>As long as the origin has SSL, the communication is secure end-to-end.

It cannot be secure end-to-end, as your edge location is quite literally performing a MITM. That aside:

How are you validating the TLS cert that the origin presents?

Going by the info on your website, the possibilities are as follows:

Scenario 1: The SAAS provider presents a TLS cert not valid for customer-domain.com when accessed as customer-domain.com

Scenario 2: The SAAS provider presents a TLS cert valid for customer.saasprovider.com when accessed as customer.saasprovider.com

Assuming scenario 1, you would need to validate the certificate out-of-band as the traditional trust chain does not validate for the given domain. Assuming scenario 2, you would need to rewrite the URLs from customer.saasprovider.com to customer-domain.com to prevent the users from following generated resource URLs to the origin domain. Or am i missing something?

>SSL is terminated at an edge location that is closest to the users.

So this is routing plain text http for most of the connection and at the same time giving the managed edge location direct access to the traffic and a valid tls cert for the domain? Isn't that mostly snake oil then, as the secure connection never originates from the target service?

Been using AndOTP for months and i love that it supports android's keystore and device credentials for authentication. I had switched to it from Authy, which was quite heavy.

Aegis' design looks a lot less dense than AndOTP on the screenshots, though it seems to be widely recommended. I'll have to check what that's all about

it's a nice quality of life improvement unless you're running low on space. 7+ gb is a lot, especially on embedded devices with low soldered storage - like microsoft's own products! coincidentally instead of offering upgradeable internal storage they upsell really hard on the models with more storage in their surface lineup

if anything, this should be a toggle- if only an opt-out toggle.

fwiw, you can install a linux system including an entire graphical stack with web browser and mail client in that space, twice.

Yes.

>And besides: If Sinatra starts a server listening for incoming traffic, why does it still seem common to run a regular webserver like nginx in front of that server?

This is a common technique used for tls-termination and management of 'virtual hosts', among other things.

The mentioned "issues" don't seem to be Sinatra-specific, but rather about the authors shallow understanding of the topic as a whole

a little tape on the camera would do just as well, wouldn't it?

un-AMPed url: https://www.theguardian.com/commentisfree/2015/sep/28/boredo...

How so? If google wanted to save bandwidth, they would simply up the cache time of their page(s), baking some version into the browser only saves the very first load. Doesn't seem like a decent strategy to face potential backlash for baking in their search page when the same thing, sans the initial load, can be accomplished with other techniques