Well, I am exaggerating a bit. But …
I am maintaining some small Firefox extension (SmTuning – my bunch of improvements to the SchemingMind web interface). To make things smooth, I tested it on some Firefox3 betas. It was a pain due to the famous insecure updates problem. Resolving it costed some time and effort, but I am glad with the solution.
Then Firefox3 final arrived and … everything stopped to work. My scripts and stylesheets were not loaded anymore, bundled images failed to display. Ups. I resolved this too, the fix was trivial, but here I feel something is terribly wrong. And is scheduled to be a big problem in the future.
Let’s go through both those problems.
Firefox authors decided, that it is dangerous to perform updates over plain unprotected HTTP. They are right, man in the middle attacks constitute a real threat. So, Firefox3 refuses to install the extension if it does not provide secure updates.
Still, this is the main reason many extensions are not yet updated to Firefox3. Why? To some degree, because the error message is unclear, and does not point to the solution. But mainly, because the first, natural solution offered is to use SSL. And because Firefox3 refuses to accept self-signed certificates here.
That’s of course not a problem for big players, but for a mere mortal is just too expensive. Buying a SSL certificate would double my hosting costs.
Fortunately, Firefox3 provides a good alternative – which, for some reason is underadvertised. It requires signing every distribution with a specifically crafted tool called McCoy.
McCoy works more or less as expected, but there are two problems:
- it must be used via GUI interface, so my extension building script can’t handle the whole process anymore;
- it completely rewrites the file being signed. By completely I mean exactly that, not only the file is reformatted, but differently organized, including different tag hierarchy and naming. Not the behaviour one would expect from the tool which is to sign.
It would be nice if somebody just documented how exactly the signature is calculated, so one could write an alternative tool.
OK, I am publishing updates rather rarely, so I live with McCoy. The idea of signing is a good one, and one can hope McCoy will be improved sooner or later.
Let’s now go to the problem which is trivial to patch, but very dangerous in the long term.
Firefox authors decided, that extensions should not access the
chrome: URLs anymore. There is some reasoning behind that, one would not like the extension to grab private data, or even check the detailed browser configuration (say - detect whether adblock is present). But …
… but the restriction turned out to include the extension own files.
Yes, it is trivial to solve, I can set contentaccessible=yes in the manifest file, and everything works as it used to work previously. But it is already proclaimed, that at some point in the future Firefox is to start to warn about extensions using this setting.
overlay.xul. And to use
data: URLs for graphics.
In short – I won’t do it.
It is amazing nobody considered trivial, natural solution to the problem. Couldn’t Firefox give an extension access to it’s own files (keeping the restriction for everything else)? I agree that SmTuning shouldn’t peek under – say –
chrome://adblock. But there is really nothing wrong if it reads under
Some harm already happened. We have plenty of extensions which declare contentaccessible=yes in spite of the fact they need nothing except their own files. It will not be possible to distinguish between them, and those making more complicated chrome reads.
I hope somebody reconsiders the matter before implementing warnings against extensions which set contentaccessible…