Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Silk, Fire and Another Loss For Privacy

jnorthrop.tumblr.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Silk, Fire and Another Loss For Privacy

#11

Post by ck2 »

MatthewPhillips wrote: post #9
ScottWhigham wrote: post #6

Earlier quoted context omitted.

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.

Re: Silk, Fire and Another Loss For Privacy

#12

Post by esrauch »

talmand wrote: post #7

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.

Re: Silk, Fire and Another Loss For Privacy

#13

Post by jonknee »

ck2 wrote: post #4

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 -…

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.

Re: Silk, Fire and Another Loss For Privacy

#14

Post by mustpax »

ck2 wrote: post #4

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 -…

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?

Re: Silk, Fire and Another Loss For Privacy

#15

Post by jonknee »

ck2 wrote: post #11
MatthewPhillips wrote: post #9

Earlier quoted context omitted.

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 an…

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.

Re: Silk, Fire and Another Loss For Privacy

#16

Post by jonknee »

mustpax wrote: post #10

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.

Re: Silk, Fire and Another Loss For Privacy

#17

Post by MatthewPhillips »

ck2 wrote: post #11
MatthewPhillips wrote: post #9

Earlier quoted context omitted.

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 an…

> 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?

Re: Silk, Fire and Another Loss For Privacy

#18

Post by ryankshaw »

jonknee wrote: post #16
mustpax wrote: post #10

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.

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.

Re: Silk, Fire and Another Loss For Privacy

#19

Post by mustpax »

jonknee wrote: post #16
mustpax wrote: post #10

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

Re: Silk, Fire and Another Loss For Privacy

#20

Post by qjz »

mustpax wrote: post #14
ck2 wrote: post #4

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 -…

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

Post reply on HN