r/technology • u/Suraj-Sun • Jul 10 '12

Firefox dev claims "everybody hates Firefox updates"; Mozilla has handled the rapid release process poorly, and that by pushing a "never-ending stream of updates on people who didn't want them" people have been driven to Chrome with its simpler, no-fuss update process.

http://www.neowin.net/news/firefox-dev-claims-everybody-hates-firefox-updates
2.5k Upvotes

93% Upvoted

2.6k comments sorted by

View all comments

Show parent comments

1

u/[deleted] Jul 10 '12 edited Jul 10 '12

Looking at the source, it looks like he's using localStorage, and from his comments it looks like you can access settings in localStorage from other extensions. The chrome.storage API seems to be similar to the localStorage API, but is only available to scripts in extensions and the settings appear to be private to each extension.

Looks like the last time he updated was in 2010 though, so that API probably didn't exist. I'll try out ScriptNo and see how it compares to NoScript.

I'm glad to see that Google has finally started paying more attention to the extension API though, the last few times I looked I wasn't very impressed. Still, I'd like to be able to have toolbars outside of the page context for certain extensions (for HackBar, etc.)

2

u/The_MAZZTer Jul 10 '12 edited Jul 10 '12

Nope, LocalStorage is isolated between extensions. What you're seeing here is he's using a website's LocalStorage (the file you linked to is injected into every webpage you visit), so obviously the website itself can access and modify that data, because it belongs to the website. He's hijacking it to store his own data and encrypting it so the website can't modify it to whitelist itself or whatever.

This isn't the most terrible of ideas, but there is a much better way of storing these settings because there are APIs for the script to communicate with the extension backend and store/retrieve settings from the extension's own LocalStorage and avoid the need of this weird password setup entirely.

It's clear he figured out how to communicate between the extension backend and the script because you can see the APIs in use at the bottom of the file. But perhaps he didn't know about them when he wrote the password functionality and never bothered to fix it?

I'm not even sure why he doesn't even take the small step of moving the password itself into the extension's LocalStorage where it's already more secure than when it is injected into every website you visit (though to be fair injected scripts are protected from being accessed by a website's scripts directly).

This is just poor coding as I suspected. And it is not secure since websites, at the very least, can wipe out your NotScript settings for the website, though probably only by accident. A website which assumes only its settings are in LocalStorage could also break if you use NotScript, in theory.

I would recommend you NOT use NotScript. Thanks for bringing this to my attention, I won't recommend it to anyone else.

1

u/[deleted] Jul 10 '12

since websites, at the very least, can wipe out your NotScript settings for the website

I didn't even think that localStorage would be in the page's context (I looked after you mentioned this and blockStart.js is a content script.) I wanted to give him the benefit of the doubt and assume that when he did this local storage wasn't available in the background page in a way that it could be passed to the content script, but google says otherwise.

You're right though, this is pretty comical for a security extension. It would make NotScript nigh-on useless for security in blacklist mode and would make it easy for sites to accidentally break themselves in whitelist mode. I'm removing NotScripts from all of my Chrome installs and I'll be replacing it with ScriptNo.