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.
>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.
>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
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
'Confirm, with appropriate supporting data, that their bid requests made with QUIC are not anti-competitive, and justify why bid requests are being used by a new and opaque request protocol under conditions where competitors are bound to use TCP with its extra round trip overhead.'
Which just looks like they have no idea what they're talking about.
Things QUIC isn't:
- Limited to Google(rs)
- "Opaque" as-is, it's just that the JS APIs are bad. It's still experimental software after all.
I don't think the people that wrote this know how QUIC works and what its benefits are.
The problem is not QUIC, it's the request API the adblockers use to filter the content. QUIC is a fast, documented protocol used by way more people and organisations that aren't Google.