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.
Insecure updates
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.
Content (in)accessible
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.
My extension bundles some javascripts, CSSs and images, injecting them into the pages. And it stopped to work.
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.
So how should I use my graphics and scripts to do it right, I asked. The Firefox guys answer is – don’t. I am expected to amalgate all javascript and CSS directly inside my overlay.xul. And to use data: URLs for graphics.
This is just stupid! Either I am to make an incredible mess out of my code (and note, that for example I share some javascript code between the overlay, and the preference window), or to build some compilation process to embed scripts and convert graphics while building the extension (a lot of work, plenty of possible errors, and far more difficult debugging and testing).
It is also inefficient. If I use the same image (say - a chess piece) many times on the page, I must repeat whole image that many times. And browser must decode it that many times, keeping that many copies, with no chance to cache and reuse. Any ideas of reusing parsed CSS or JavaScript (even if not present currently, possible in the future) are also killed on the spot.
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 chrome://smtuning!
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…
RSS
Feedly
Email
