Use "Amazon 1 Button" Chrome extension to sniff all HTTPS websites
blog.kotowicz.net
blog.kotowicz.net
1) I wish there was a way by which an extension could declare its access patterns in much more fine-grained manner (kinda like CORS headers). Then I can prove to my users that my extension cannot do the sort of ugly crap that Amazon is doing.
2) Second is an API to expose details of an XMLHTTPRequest's (or maybe even 'document' object's) SSL server certificate. Even a binary blob will do: I can parse it in JS. Without this, you can't do "certificate pinning" for extensions.
Chrome extension permissions are too coarse-grain. Why is DOM write permission not separated from DOM read perms?
If Google doesn't crack down on abusive extensions like this, they risk users losing trust in the Chrome "brand". Just my 2 cents.
I keep them mostly disabled - just can't fathom why a simple extension (e.g. to pretty print JSON) seems to need the access levels on the install warnings.
The cert I use for my backend doesn't need to be part of the existing trusted CA infrastructure if I control the clients.
A way for users to restrict some permissions of an app would be good, but a UX/support problem when they disable something that breaks core functionality.
1) Users can enable or disable any permission they like 2) This is transparent to developers - i.e. if you access geolocation, you'll always get one. It just won't be the right one if you don't have permission. 3) The extension is allowed to query which permissions I've given. So devs can handle blocked permissions more gracefully if they choose.
http://developer.chrome.com/extensions/activeTab.html
At least these extensions are .js files that you can read and that Chrome does tell you what it can access (and lets you see that after they are installed). A lot better than the situation for desktop software.
This whole "scorched earth"-style permissions model that users can't make educated decisions about is what annoys me about current platforms like Chrome, Android and iOS.
JavaME had an interesting model where the app asks permissions after it is installed (e.g. internet access, local file system access) for each thing it wants to do. And the app has to consider the fact that the user can decide not to grant that particular permission. Of course, once you decide to trust the app, you could disable the prompts.
iOS does the same for the permissions it supports (access to photo library, contacts, GPS/location, twitter accounts, etc etc), but a lot of things are always allowed (such as internet access). Facebook also lets you deny specific permissions to apps on their platform. I've always wondered why Android and browser extensions don't let you line-veto deny permissions.
App authors also might shut off the app in less you give it all the permissions, which will cause users to just say yes every time.
Which, of course, is ironic given that every update to the facebook app on Android asks for more and more permissions, to the point where it can do almost anything now.
The "news" part of this is that the extension allegedly reports all the URLs you've visited to amazon, including https ones, plus some reporting of site contents to alexa.
Someone who's hired isn't an affiliate, he's an employee.
Generally, the usage of the term "affiliate" (ie., sales affiliate) is a corporatism designed to make a wage slave job sound better than it is.
It has a Privacy section in the settings that lets you enable Wait For Click so URLs are only checked upon explicit request. It also lets you exclude domains or URL regular expressions from automatically checking the URL, forcing those to be Wait for Click.
Plus, it comes with smart defaults. Default excluded domains include popular banks, Gmail and Google Docs. Default excluded regular expressions match Google/Yahoo/Bing SERPs and various protocols that you probably don't want checked.
All it takes are some smart defaults and a small amount of development [2], and you can protect your users' privacy. It's worth it.
[1]: http://kerrick.github.io/Mostly-Harmless
[2]: https://github.com/Kerrick/Mostly-Harmless/blob/d61d79aa85a6... (20 LOC in my extension)
We allowed users to share post-it note style comments on web sites with their friends; for example, I could leave you a little note on the hackernews front page, and the next time you go to the site you would see the not sitting on top of it.
In order to do this, we had to check every page you visited to see if there was a slide for you on it. We cared about privacy, so we took a hash of each URL and sent it instead of the URL itself. While we would know what site you are on if we happened to get a hit (i.e. you had a note on the page), we wouldn't know what site you were on if there was no note.
Of course, this was all based on the users trusting us to not change our code. There was nothing preventing us from changing how we sent the URLs. The level of access extensions get is SCARY. I don't think users realize what exactly they are allowing when they install them.
Your site URL hashing system is also pretty close how Goggles works, only instead of notes, you get to draw MS paint-like scribbles. http://goggles.sneakygcr.net
Each website is uniquely keyed by a hash of the URL, so Goggles doesn't know the website's URL even if there is a hit. (It does send the page title to the server though because popular sites go on a leaderboard; i'm not so sure about that decision though since it can leak some privacy...)
Browsers are doing a much better job at protecting/restricting bookmarklets than extensions and I wish more of these kinds of notetaking apps/tricks use bookmarklets instead. For example, I just now discovered that Chrome will prevent Goggles from working on certain HTTPS sites like hacker news because it loads javascript from an http:// URL, which is a great design decision from the Chrome team.
Amazon wasn't being evil, just incompetent. Never attribute to malice what can adequately be explained by stupidity...
This behavior looks premeditated to me.
It's pretty clear they "might do this" so they can data-mine your browsing activity, which is now associated with your account, and serve you more targeted ads and product recommendations. So I guess we have to extend your catch-phrase with "...and never attribute to stupidity what can be adequately explained by greed."
No, it's not evil, it's the the point of the extension -- to do product search.
If you don't like the product, you don't have to use it, but you can't say you want it, and then say it's evil for doing exactly what it says on the tin.
That simple empty script allows them, at any point in the future, to remotely inject scripts that'll have full permissions over any website you visit, without having to push an extension update or have it as part of their core extension code.
They can also choose to send it to specific individuals, or only for specific websites (their script URL gets the visited page as an query string argument), making something like this extremely difficult to detect.
And of course, this could also be abused by someone who hacks their servers. He could, for example, inject a script that sends the user/password whenever you login to a bank or paypal.
Having remote code execute on every page you ever visit is either extremely stupid or an extremely smart way to spy on people without being detected. When the code is part of the extension itself and not remote it: 1) has to be signed (making abuse harder for a malicious hacker) and 2) can be more easily audited, as all users of the extension would get the "spying code" (making abuse harder for a malicious company)
edit: wording
They can't otherwise scrape search results as you, and getting the info as an anonymous user isn't nearly as valuable. So they need you, via an extension or toolbar, to (perhaps inadvertently) opt-in to letting them collect the data 'over your shoulder'.
We wrote about one, incidentally, a few months ago, that has hundreds of thousands of installs: https://www.tinfoilsecurity.com/blog/building-a-browser-exte...
The described technique looks like it might get me some of the way there, but it's kind of a square peg to my round hole. My google/stackoverflow searches aren't getting me very far; I found a reference to jmeter acting as an https client proxying http, but that looks like a similarly deep hole. Maybe it's easier than it looks; I don't know.
I'm no browser expert, but I'm not particularly afraid of javascript.
Advice?
1) Would a plugin such as Disconnect.me stop this from happening? (Yes, I am aware of the irony...)
2) What's the best way for a non-technical person to monitor traffic to ensure that plugins are not "phoning home"?
1. Unlike that other "privacy" cough extension, Disconnect doesn't send any data (user or otherwise) to Disconnect servers. In other words, Disconnect doesn't output user data that can be intercepted by a MITM attack. Disconnect does grab a config file on startup (https://disconnect.me/help#syncing), but unlike in the Amazon case, the file is both transferred over HTTPS and encrypted (with the Stanford Javascript Crypto Library). Also unlike in the Amazon case, the file has a limited functional scope (which third-party sites to block) so is less susceptible to being rewritten in an abusive way.
2. One of our other Chrome extensions, Collusion for Chrome, will actually show you requests that are coming from other extensions. The more technical approach, which isn't that hard and I'd like to see more people try, is to run a packet sniffer (recommended: http://www.wireshark.org/) or proxy server (recommended: http://www.charlesproxy.com/).
TLS already encrypts. What threat model prompted your decision to use JavaScript cryptography?
It seems so many exploits rely on Javascript.
Would a user ever be willing to sacrafice a little "user experience" (accomplished with Javascript) for protection against easy exploits?
Is that question ever left to the user?
Not if a website provides Javascript-free means of interacting with it; and demands that the user enable Javascript (=you "must" enable Javascript to use this site).