Wandering Thoughts archives

My issues with Chrome's handling of extensions

This got long enough that I've pulled it out of the original entry into a standalone entry.

On an ongoing basis, two issues with Chrome extensions especially grate on me. The first is that Chrome extensions are disabled when you're visiting Google's website(s). This has a vaguely sensible excuse for security reasons (Google's website hosts the Chrome extensions), but the side effects are unpleasant since extensions provide significant portions of the browser interface for me (in the form of mouse gestures and middle mouse autoscrolling), plus I am not happy about losing the ability to block all JavaScript.

(No, I don't have Google whitelisted for NoScript in Firefox. Yes, I'm peculiar.)

The second is that NotScripts does not have anywhere near as good an interface as NoScript does. I'm not sure if this is a Chrome limitation or just that NotScripts has not gone the extra distance, but it sort of feels like a Chrome issue to me; given their other behavior with extensions, I find it all too easy to believe that Chrome has deliberately limited what GUI interfaces are available to extensions and forced NotScript to jump through hoops to get even as much as it does now. When I'm using NotScripts, it's less clear what the state of things is on the current page, it's harder and takes me longer to do things, and I feel that the interface is not as clear.

(For example, NoScript lets you deal with multiple JavaScript sources in one trip through its menu. On NotScripts, you can only modify one source at a time; if you have multiple sources, you get to click over and over on the menu. Another example is that I have a NoScript button for 'temporarily enable this site' right by the URL bar, which makes it very convenient; a lot of the time I click the button and I'm done. There is no equivalent I know of in NotScript.)

More impressions of Google Chrome

It's been a while since I started to use Chrome and in the time since last August I've accumulated more opinions, partly because I gave in and installed the Chrome equivalent of NoScript. The short summary is that I can't imagine making Chrome my regular browser instead of Firefox.

Here is my largest opinion in a nutshell: Chrome's support for extensions is not good enough. It really feels like Google fundamentally doesn't like extensions and supports them only half-heartedly, versus Firefox's wholesale embrace of them.

(This is probably not actually the case.)

The result of this is that using extensions on Chrome (especially interacting with them to control them) is more awkward and limited than using extensions in Firefox. Although I did not realize this back when I started using Chrome, it turns out that I interact with extensions quite a lot and so these issues grate on me as a little quiet background irritation.

(A detailed discussion of this got long enough that I've put it in a separate entry, ChromeExtensionIssues.)

I also have a number of issues with Chrome's interface and how Google is evolving it in various Chrome updates (I can't really call them 'releases' any more); there are things I don't like and things that are inexplicably missing. I could probably fix at least some of the things that irritate me if I worked at it and found the right magic options, but what it boils down to is that Chrome isn't attractive enough to get me to spend that much time on.

(I'm aware that I may wind up rather unhappy with Firefox 4 and future Firefox versions, since I've seen that they're into yanking around the interface in Chrome-like ways.)

Chrome continues to eat Flickr for breakfast, which is what I keep it around for. But my sporadic experiments with using it as a regular browser are basically a failure at this point and I can't imagine that changing. Fundamentally it feels as if what Google wants out of Chrome and what I want out of a browser are too far apart from each other.

Databases as a compromise damage limiter in web applications

Here is a thought that I have been toying around with lately: you could say that one attraction of using databases in web applications is that they limit the damage from an application compromise.

You can at least conceptually separate web applications into the 'computation' (such as it may be) and the backend data storage. Historically, many web application vulnerabilities have given the attacker various sorts of unfiltered access to the backend storage system (usually this is some variety of passthrough attack where parameters are not filtered enough).

When your backend database is an actual database (SQL or otherwise), all the attacker gets is, well, access to the SQL database. This is damaging, but generally the damage is confined to the contents of the database. However, when your backend storage is files in the filesystem unfiltered access will often give an attacker access to the entire filesystem, not just the directory hierarchy you are using as a data store; they can read and sometimes write all sorts of files outside of your 'database'. This is an unconfined breach (and in some situations can almost immediately escalate to code execution, for example by dropping files into places where they will be executed by further web requests).

Or to put it more simply: if your program never opens any files, it's a lot harder to persuade it to open the wrong one. Using a database gets you storage without having to actually open any files.

(I doubt that this is why very many people pick a database backend for their web application, though. There are lots of other reasons, including that someone else has already written the storage system for you.)

This thought came to mind lately because I have been thinking about relaxing DWiki's constraints on file IO. DWiki uses the filesystem for all of its storage, and as a result I made the storage backend very limited and very cautious about what it did; these limits are now starting to be inconvenient. But, of course, the more I relax the limits the closer I am to one mistake giving an attacker full filesystem access.