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.

<body bgcolor=0>

>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

On a more serious note,

> alias www='python -m SimpleHTTPServer 8000'

that'll only work on systems where python is python2

> alias speed='speedtest-cli --server 2406 --simple'

speedtest-cli automatically selects a server, invoking it without any opts at all is perfectly fine

> alias ipi='ipconfig getifaddr en0'

the interface name is not predictable, nor portable - `ip a`

Most if not all of these aliases seem rather pointless after all

This article covers gems like `alias c='clear'` - very handy! scnr

I'm sorry but how is this native? It's an electron app...

Up in Germany

They ask google to:

'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.

I'm using a Hackintoshed Lenovo Y50-70 (FHD model) running MacOS Sierra and i can only recommend it so far, all of the configurations that are being sold are very compatible with macOS. It even comes with a dedicated GPU which is great for GPU-intensive tasks on different OSes - it's disabled whilst running macOS because of missing drivers for nVidia optimus though.

The license is still valid on the latest build BTW.

There should be no A-labels on bare gTLDs, so "https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents)

the period has to be there because it breaks spec btw

To whoever edited my title: The bug report title is inaccurate. It's specifically about HSTS preloads, which is why my original title stated that instead of "gTLDs".

It would probably work, but it would break spec.

This causes funny behavior like https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large

Chrom(e|ium) will suggest to navigate to http://google if you're opening google.com

Not necessarily just a field trial. AFAIK it was bundled with a recent ChromeOS update, causing logon to fail when MITM'd

Client and Server exchange a list of capabilities at the beginning of a TLS connection, if the proxy just filters out the protocols/versions it doesn't understand, server/client will agree on a different version (like 1.2).

Rejecting anything it doesn't understand sounds like a bug to me. If it sees that it's TLS, it should attempt a protocol downgrade. There's absolutely no reason for this to break, as TLS 1.3 exists alongside TLS 1.2 (For now).