Silk, Fire and Another Loss For Privacy | Hacker News Reader

Silk, Fire and Another Loss For Privacy

jnorthrop.tumblr.com

51 pointsjnorthrop32 comments

It's worse than that for webservers.

I block all Amazon AWS/EC2 on my servers because it's never humans and I've yet to see a useful bot from there - they just suck bandwidth and cpu time. Since they have free, unlimited inbound, there's a bunch of nonsense going on.

Now I suspect silk is going to use the same IP range as amazon aws, so if you block aws, you block silk?

So no more using iptables to stop the traffic - maybe I can do it on another layer, allowing the ip via user-agent but of course bots will start spoofing that too.

Anyone know if silk will cache and serve content that is not fresh while ignoring no-cache headers?

Bonus points if anyone as access to a Fire and can test the ip range and header obedience (as well as pre-fetching aggressiveness).

Good question and I haven't seen a response yet. This may be a serious problem for Amazon since you aren't alone in your blocking of AWS/EC2 IP ranges. If users use the tablet and find that the Silk browser doesn't show them all the sites they want, then people will be disappointed in Amazon. Hopefully they'll separate/segment IPs to prevent users from not using the browser.

More likely, if AWS fails to fetch a page it will fallback on the browser to do the work. So the user will still get to the page they want, and your site will be blamed for being "slow" due to blocking AWS caching.

Why would they assume local connect would work when AWS times out or notices it was never able to fetch a page?

I think it will only be available via a buried setting that most users will never touch.

Fire seems to discourage any kind of advanced user, it's the king of "no"

  Bluetooth? No
  HDMI? No
  Camera? No
  Microphone? No
  micro/SD slot? No
  GPS? No
  3G? No
  Android Market? No  (only amazon's market)

It also brings yet another browser to worry about for website compatibility and will require simulation to test.

Why wouldn't they assume that? Amazon surely knows that some people block AWS servers (AWS customers sure know!).

You also have to realize that Amazon gets the advantage of crowd sourcing--in short order they should know who's blocking what and not even have to make the original requests to be blocked.

Not only that, but what's to prevent them from caching content after the first client makes a successful direct connection? After that, they can serve the cached content quickly to other Silk users. Circumnavigating such blocks may even be one of the driving forces behind developing Silk in the first place, since it allows Amazon to access content they can't easily reach otherwise.

> Why would they assume local connect would work when AWS times out or notices it was never able to fetch a page?

Retrying upon a 400 error is normal and permitted per the spec. Why would you not retry upon a timeout?

To be fair, blocking the whole AWS/EC2 ip range is not being a very good web citizen. Surely there are better ways of detecting and throttling bots?

I also block AWS/EC2 on my servers because it's a relentless source of badly behaved bots, freeloading SEO scrapers, and poorly misguided startup ideas (no, I don't want you to proxy SSL connections for my users--just think about it for a second, for crying out loud).

Now with Fire & Silk in the mix, how do you even go about protecting your content from Amazon, if they can get it directly from the browser, cache it, and make it available to their own paying customers (who might have been blocked by your firewall, for whatever reason)?

I can accept that since it's technically possible, they'll just do it, and resistance is futile. But if you want to locate bad netizens, AWS/EC2 is an excellent starting point.

Remember, this isn't just about publicly-available content, it undermines the entire trust model of TLS/SSL (and exposes some of its underlying weaknesses, hopefully spurring development of a better solution in the long run).

Silk is supposed to be dynamic and work on AWS when it helps and locally when it doesn't. In your case I'd assume Silk users would have a slower, but successful, time using your site.

Perhaps they'll still make it easy to identify so that you can give Silk users the best experience possible, but there's no way it's just not going to work.

If the Silk servers add an an X-Forwarded-For header to the request, you might be able to do it that way. I'd be pretty disappointed if they don't, actually.

When intercepting a regular HTTP session Silk is no more of a MITM attack than any ISP out there. I trust Amazon more than I trust AT&T or Verizon.

What disturbs me is that Amazon Silk will terminate SSL on their end by default.* This is the break from the past that's worrisome.

* Source: http://www.amazon.com/gp/help/customer/display.html/ref=hp_l...

"Amazon Silk will facilitate a direct connection between your device and that site. Any security provided by these particular sites to their users would still exist."

Between your device and that site doesn't sound like terminating at AWS. Also, the SPDY connection to AWS is secure which gets you a leg up on sites that aren't using SSL.

By terminate I mean Amazon's doing the SSL certificate verification on AWS and reestablishes a new connection (with SPDY) that they themselves sign. In this case, Amazon will be free to read and modify all data in flight, defeating the whole purpose of HTTPS.

"We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL."

read the sentence right above that: "We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://example.com)." that means that the SSL is terminated at amazon's servers, they see it in plaintext, then they send it via SPDY (re-encrypted) to your device. so it is always secure over the wire, but is plaintext readable by amazon. if you are worried about what someone on the wire can see, you are good. if you are worried about what amazon can see, you're not.

Let's not forget that this decryption and re-encryption[1] is going on in the AWS cloud, which is ostensibly shared infrastructure. Its not just what Amazon can see, but what other people who happen to be running on the boxes doing this re-encryption can see (through security vulnerabilities).

[1] I'm making the assumption here that re-encryption is actually occurring. It could be the case that its not and the phrasing was simply poor.

Yeah, that's what I find worrisome as well.

And I don't see how it's possible for them to proxy SSL content without being MITM and re-encrypting. They could stay entirely out of the way for HTTPS requests, but if that's how they were doing it, I think their FAQ answer would just say so. If, on the other hand, they're inline enough to do the Silk acceleration thing at all, they have to be able to decrypt the traffic.

As others pointed out, that is at odds with the previous paragraph ("We will establish a secure connection from the cloud to the site owner on your behalf").

Also, unless they stop doing the Silk combining thing entirely, I don't see how it's possible not to peer inside the requests. They can either pass along the traffic without knowing what it is (meaning they can't cache, or combine, requests or responses, because they don't know what's in those requests and responses), or they have to see inside.

This, to me, means they're taking liberties with the meaning of "direct connection" in the snippet you quoted, and, if I'm being pedantic, I don't see how the final sentence ("Any security provided ... would still exist") is literally true at all. Seems to me that being end to end, encrypted by a key only you and the other end, know, is a form of security that does not still exist in this architecture.

(Somewhat off topic, but when using earlier-generation Kindles with whispernet 3G, over 3G, all traffic is proxied through Amazon's datacenters, even for SSL, and I have no idea if it's secured end-to-end all the way to the device, or decrypted in Amazon's datacenter, and possibly re-encrypted to send OTA to the device. There's no way to tell.)

According to Ars Technica's article on Silk, it is possible to turn off the split browsing mode and use Silk as a regular web browser, so people who have privacy issues with this can turn it off.

Deleted comment

People don't have to be technical enough to understand or circumvent, that's why there are experts out there pointing these things out and helping people configure their stuff.

The only valid point here is that most people aren't informed of the privacy issues and this really needs to stop being a valid excuse once and for all.

Yup. Also pointed out here (http://news.ycombinator.com/item?id=3051585), sourced to the official terms and conditions (http://www.amazon.com/gp/help/customer/display.html/?nodeId=...).

There is no such thing as privacy on the internet. Only the illusion of privacy exists.

I don't think this is quite accurate; it's actually somewhat similar to say that there is no privacy in the real world because you have to travel through public property to get anywhere.

Anyone could follow you to any store, keep ultimate tabs on where you go and who you meet. Except that isn't a problem, it doesn't happen. And it's not that people don't see you go places; it's very unlikely that you can make it from your house to the grocery store without a bunch of people seeing your car and its unique identifier of a license plate.

The thing is that it is almost always different people that see your car on each trip, and those people would be hard pressed to connect your license plate back to your name or your house address.

This is true on the internet when your mail, your news source, your social network all are separate entities that have no real way to link between each other. Many people knowing a tiny portion of your identity is very nearly the same thing as none of them knowing anything; and with only the smallest amount of effort that is easily possible to achieve on the internet.

Imagine your ISP is some guy that goes wherever you go and sees whatever you see and hears whatever you hear and so on.

Now imagine that the guy is willing to share that information with others due to court order or a nominal fee.

Your analogy works if you imagine the privacy issue is other internet users seeing what you are doing while they are going about doing whatever it is they are doing.

Unless you have a direct connection to the Internet that does not go through a third party everything you do on the Internet is open to the possibility of being tracked. You use a gateway to get to the Internet and you are not the gatekeeper.

Even still, the ISP only keeps logs of what URLs you visit and as far as I know they are almost never mined in any way that correlates to your identity.

At the worst it is like someone knows all of the addresses I go to in real life, which is still way way less knowledge than private messages to friends and colleagues or the contents of my email, or even what friends and colleagues I am contacting. Actually, it's even less than that because going to gmail or secure.google.com indicates exactly nothing to the ISP about your behavior, for pages like that it would be like someone having knowledge that you are a member at the local library without knowing what books you have checked out; hardly the most privacy infringing knowledge possible.

Additionally I naturally access the internet from at least 3 different ISPs on any given day, so even then it is still less concentrated than a single monolithic entity like Facebook.

With regards to court order; literally anything can happen with a court order. You can claim that phone calls or paper letters aren't private because a court order could allow police to read their contents, but I think that is really stretching the truth.

"Even still, the ISP only keeps logs of what URLs you visit and as far as I know they are almost never mined in any way that correlates to your identity."

As far as you know is dead right. The ISP knows who you are and what you are doing. Why do you think they receive subpoenas all the time to reveal the identities of people? The entertainment industry has an entire extortion racket going simply because they can ask a court to force an ISP to tell them who you are.

Everything you do on the internet has the possibility of being observed. It may not be active but it can be done. We have privacy because we aren't important enough to be heavily watched.

The only thing we have is SSL and I for one am not convinced it is as totally secured as many believe it is.

Privacy in the sense of 'what websites do I visit' or 'what am I posting on Facebook' is one thing; privacy in the sense of 'how much money does online banking say I have?' is another issue entirely.

That is true.

Depends on how trustworthy we think security certificates are in the long run.

Just playing devil's advocate here: They mention "aggregate user behavior", so they could be building a large, aggregated Markov chain that stores no user data whatsoever -- just site transition data for the world.

I haven't read in-depth analysis of how they do their stuff, though.

I work for a bank. If Silk does indeed terminate SSL, we will block this browser from accessing online banking. We block OperaMini browsers, which also terminate SSL, for exactly the same reason - your sign-on credentials will be IN THE CLEAR on a 3rd party site.

As the bank is the one offering the security guarantee and talking the risk, we cannot afford to have credentials in the clear on some else's site -- ever.

There are alternative browsers available:

http://www.amazon.com/gp/search/ref=sr_kk_1?rh=i%3Amobile-ap...

That doesn't fix the problem for unaware users, but at least the option to use other browsers still exists.

Reply on news.ycombinator.com