Archive for the FlashGot Category

Since last time I wrote about WebExtensions, a lot has been going on: for instance, I used to link a Mozilla Wiki article, and as you can see now I'm linking a full featured MDN entry :)

In the meanwhile, I've been among other things hacking the WebExtensions code itself to make it suitable for eventually porting my own extensions, NoScript and FlashGot, and all those which share similar requirements.

The key WebExtensions API needed by adblockers (one of the most popular browser extensions category), by anti-trackers like Ghostery and, of course, by security add-ons like NoScript, is WebRequest. Its first implementation as a JavaScript module (still the foundation of the current one, which is a thin wrapper over it) even predates WebExtensions themselves: genius e10s hacker Bill McCloskey started it as a brave experiment to see how realistic could have been migrating Adblock/Ghostery/NoScript to the still just rumored "next thing" in add-on development.

Unfortunately, the way this API was originally implemented imposed harsh limitations, both in Chrome compatibility and, more annoyingly, in suitability for the very kind of add-ons it was meant to support. But we've got good news: I've recently landed a couple of patches (after a long time spent away from Mozilla's code repositories), paving the way to the removal of the remaining Chrome incompatibilities and for the addition of new divergent features required by NoScript & Co. which by the way, if ever borrowed in Chromium, could even finally make a NoScript porting on Google's browsers and derivatives possible.

More specifically, Firefox 47 adds:

  • The requestId property in every WebRequest event, allowing listeners to track individual requests across their entire lifecycle (yes, it's incredible we had not implement it yet, and it was the main blocker for Ghostery as a WebExtension).
  • Reliable HTTP headers manipulation - they can be examined, deleted, added or modified both in requests (by onBeforeSendHeaders listeners) and responses (onHeadersReceived) as plain JavaScript arrays of name-value pairs.
  • HTTP response status code and raw status line reporting - without this, it was almost impossible telling the type of a redirection or even whether a request succeeded or failed and how.
  • Coming very soon:

    • The onErrorOccurred event (patch ready, will surely land in 48), also needed by Ghostery.
    • The requestBody property, which allows onBeforeRequest listeners to analyze the payload of POST and PUT requests and is required by NoScript's XSS filter.
    • An "origin" property, which is required not just by many features of NoScript's but also by other add-ons such as RequestPolicy.

    I'm very satisfied with the work done so far, and as soon as the 3 features above are completed, I'm ready to take on other areas where the Chrome extensions API (hence, for obvious reasons, WebExtensions in their present state) are severely lacking, such as script execution control and fine-tuned content blocking, which still prevent NoScript from migrating.

    During the past weeks I've grown intimate with the WebExtensions API source code and familiar enough with the "modern" Firefox development workflow. I'm sure this incoming spring will be a most interesting time, and I'm confident that summer will come with a brand new NoScript, reborn as a WebExtension :)

Notice to mariners: starting with NoScript version 2.6.6.9 (ATM still a RC) and next version of FlashGot (1.5.5.6, most likely) the packages (XPIs) of my Firefox add-ons won’t be signed anymore.

Almost no other Firefox extension gets signed these days (NoScript and FlashGot had been among the earliest and few for a long time), and AMO being the only authorized repository you can install the add-on from by default, there’s little or no point in keeping the relatively expensive and clunky signature machinery in place.

You probably noticed AMO lags quite a lot behind stable versions. That’s because the editorial staff manually checks every line of code published as “stable” for security issues and known performance problems. Therefore, if you’d like to always run the latest and safest (a good idea for a security tool like NoScript), you may want to switch to the fast lane, i.e. the automatically up-to-date beta channel, by installing 2.6.6.9rc1 now.

Well, already a dozen requests today only.

Unfortunately, Safari 5's support for extensions looks even more limited than Chrome's.

So, no NoScript (nor FlashGot, nor any half decent ad blocker*, for the matter) as a Safari extension for the foreseeable future...

* Looks like ad blockers are actually possible, see Dave Hyatt's comment below. Documentation of this feature is deeply buried inside a completely unrelated "Messages and Proxies" chapter, but whatever. NoScript is a very different beast though, and infrastructure to port just does not exist (yet?) :(

In the past few hours I've received many reports from users of the popular free avast! antivirus, who were abruptly prevented from using FlashGot because its FlashGot.exe component was mistakenly detected as "Win32:Trojan-gen {Other}", a generic identifier usually associated to false positives.

FlashGot.exe is digitally signed by InformAction Soc. Coop. and unchanged since some months ago, so if you installed it from AMO or from the FlashGot web site, which both serve downloads through secure connections, you can be sure it's not a virus.

If you're in this situation, first of all please report the file as a false positive to the avast! guys, pressuring them to adjust their flawed virus database.
Then, while you're waiting for their updated definitions, you can add an exception in order to keep FlashGot working:

  1. Right click on the avast! tray icon
  2. Select Program Settings
  3. Select Exclusions and push the "Add" button
  4. Type the following path mask:
    %APPDATA%\Mozilla\Firefox\Profiles\*\FlashGot.exe
  5. Push "OK"

Happy downloads!

Update 21:48 UTC

They fixed it, just update your avast! virus definitions.

Just googled for Vista TCP Limit on behalf of FlashGot user.
The first 500 results at least are all reported as malicious sites, including the top two, Softpedia and MSFN.
Luckily enough for P2P addicts, Firefox's Safe Browsing -- even if backed by Google's data -- doesn't seem to agree ;)

Update Sat Jan 31 2009 16:32:50 GMT+0100

Looks like it was a more general Google bug, fixed now.

Bad Behavior has blocked 861 access attempts in the last 7 days.