https://www.theverge.com/2018/4/18/17253784/google-domain-fr...
Tech companies being "on users side" (if they ever were) is now officially over.
Hopefully they don't expect users to be on their side when the regulations are coming.
141–150 of 519 posts
https://www.theverge.com/2018/4/18/17253784/google-domain-fr...
Tech companies being "on users side" (if they ever were) is now officially over.
Hopefully they don't expect users to be on their side when the regulations are coming.
Earlier quoted context omitted.
AFAIK There was some effort to make this TLS 1.3 SNI header encrypted but some influential groups blocked that (I think I read something about ability to route and control traffic easily). Really sad :(
What do you encrypt the header to ? Options include: - Start an encrypted unauthenticated conversation with the server first: that adds at least one extra round-trip, so most people won't do it, so it's easy to block all connections that do - Encrypt it to a key you have from the previous connection: doesn't help the initial connection and you already have session resumption for the rest - Encrypt it to a well-known…
Eh, people will do whatever the TLS libraries have as default. Optimizing for an extra RT is way above what most app developers do.
Earlier quoted context omitted.
The fact that they posted the e-mail from Amazon, so readers could direct the blame at them. You can’t read that blog post and say it’s the most unbiased and objective way they could have presented this, especially if they want to remain on good terms with Amazon, who has done nothing wrong at all.
I thought it was 100% objective, straight across. I don't see any barbs or negativity toward Amazon whatsoever, just the facts about that situation and an honest discussion of the facts looking forward.
Earlier quoted context omitted.
Unfortunately, federation is not an effective tactic against censorship: https://news.ycombinator.com/item?id=16871352
Peer-to-peer, on the other hand, is.
Earlier quoted context omitted.
I can imagine why someone cares if someone else pretend being that someone....
No, the trick works the other way around; they pretend they want to talk to someone, but then talk to someone else. They never pretend to be someone else.
Earlier quoted context omitted.
I agree. The intent is noble, but this headline makes Amazon look like the bad guy for disapproving unauthorized use of one of their domains, which is quite reasonable.
Hardly reasonable. Domains are (in reality, if not in legislative fantasy) property of ICANN and merely rented by everyone else.
Can someone explain how does one serve content on a domain they don't own, like in this case Souq.com? Do they shove their content to something like product reviews or what? EDIT: I realized they use souqcdn.com. Does this mean it works because their clients use "souqcdn.com" to resolve to CloudFront CDN's IP address and then they craft a different Host header (like "Host: api.signal.org"). Also how can they possibly…
Essentially when implementing encrypted channels with TLS, the domain name is still clear text in the SNI field, making the censorship circumvention scheme vulnerable to deep packet inspection. The technique is to modify the SNI field in TLS traffic to innocent domains. Major anticencorship efforts have all adopted this approach. Tor has it as meek.
A while ago Google has disabled such usage for Tor. This is just another cloud vendor shutting down another anticensorship vendor.
The real implications here are two things. First, domain fronting is built based on the deterrence of collateral damage, i.e. as a censor you wouldn't want to block TLS traffic with google.com SNI in it, but this deterrence viewed from the perspective of cloud providers is unwanted risks. Second, domain fronting in practice is abused by malware too much (in fact Tor is also a major malware enabler) and cloud providers can't accept this.
This is nothing to do with censorship. AWS has many clients and does not want its network to be blocked because of a single customer. Tough for Signal but that's how it is when dealing with businesses (especially one that so many others rely on). The same thing just happened with Telegram in Russia which explains the preemptive messages: https://arstechnica.com/information-technology/2018/04/in-ef...
Capitulating to foreign censors for business reasons has something to do with censorship.
It's not a single company here, thousands of businesses rely on AWS and don't want their service disrupted because of Signal.
They're spoofing identity of non-consenting parties. The cause is noble, but it isn't what the headline would imply. Amazon isn't saying "You can't host encrypted services on our platform", they are saying "You can't use TLS and load balancing hacks to pretend to be us in oppresive countries". And >The idea behind domain fronting was that to block a single site, you’d have to block the rest of the internet as well. I…
I agree. The intent is noble, but this headline makes Amazon look like the bad guy for disapproving unauthorized use of one of their domains, which is quite reasonable.
This might be the only possible outcome given a corporation's legal responsibilities to its shareholders etc, I don't know all that well enough, but I think it's still justified to lower my opinion of Google and Amazon because of this.
Earlier quoted context omitted.
But the result may be Amazon getting blocked in those countries, which could cause Amazon financial and logistical harm. I'm all for Signal helping people bypass state censorship, but they're attempting to bring third parties into the fold and use them as fodder for the cause.
That's the whole point of this, by blocking Amazon, these countries would be taking down a large part of the Internet inside their borders. We're not talking Amazon your one stop shop for dildos and bobble heads, but AWS, which powers a lot of other websites. The countries listed, like Egypt, know that you can get away with torture, but don't touch the people's memes.