Silk, Fire and Another Loss For Privacy
jnorthrop.tumblr.com
Silk, Fire and Another Loss For Privacy
1–10 of 33 posts
Re: Silk, Fire and Another Loss For Privacy
#2According 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.
Re: Silk, Fire and Another Loss For Privacy
#3Just 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.
Re: Silk, Fire and Another Loss For Privacy
#4It'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).
Re: Silk, Fire and Another Loss For Privacy
#5According 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]
Re: Silk, Fire and Another Loss For Privacy
#6It'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 -…
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.
Re: Silk, Fire and Another Loss For Privacy
#7There is no such thing as privacy on the internet. Only the illusion of privacy exists.
Re: Silk, Fire and Another Loss For Privacy
#8According 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]
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.
Re: Silk, Fire and Another Loss For Privacy
#9It'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 -…
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.
Re: Silk, Fire and Another Loss For Privacy
#10When 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...