Code delivery happens in desktop apps too, when you download the binary from evilsite.com, or when you receive an auto-update, they can give you a different binary than the security professionals reviewed. That's assuming the professionals even reviewed the binary, and not the source evilsite.com claimed it was built from.
It would also be difficult for said professionals to detect IP-(range)-specific backdoors (with as much obfuscation as you like; only send on Tuesdays; encrypted using a string constant elsewhere in the binary), in App Store delivered binaries that are harder to vary per downloader.
Some web apps - [Cryptee](https://crypt.ee/threat-model) is a notable example - address this with a "trust on first use" approach, that makes any change to the (web) code require approval, but that's in the same realm as a desktop app, where you've trusted it on the first download, and trust it to have actually followed through on that promise.
That's certainly credible evidence for past use I overlooked, though it remains unlikely to be useful with the advent of per-origin cache isolation.
The Last-Modified header can be used in exactly the same way, and isn't blocked by this extension, which harkens back to my original point: this is an extension that appears to see significant use by non-technical users, yet it breaks a browser feature by default. There are plenty of other methods of identifying a unique user that it doesn't prevent, so this seems like a pretty unexpected feature users should take note of.
We use the ETag header to make use of browser caching - not just for performance, but as a component of offline support. Yes, we could add an additional header with the same information to work around this specific extension for application-specific functionality using it, but that would leave the browser-based features broken.
While the ETag header may have been usable for cross site tracking at some point in the past [1], browser caches are isolated per-origin in Firefox, so there's no longer a cross-site tracking concern. That leaves it usable to identify you across sessions only in a first-party context, just like cookies, IP addresses (to a lesser extent), the Last-Modified header, and any number of other identification techniques ClearURLs doesn't block.
[1] I'd be interested to see any credible evidence of ETag headers being used for tracking in the wild - I've only seen theorizing that it _could_ be used as such, prior to cache isolation being implemented in Firefox and Chrome.
It should be noted that this extension strips ETag headers from all responses by default, which can break sites in surprising ways. As a developer of a web application that relies on ETag headers for vital functionality, I see not-infrequent support inquiries from ClearURLs users who don't understand the technical ramifications of this feature - nor do they understand why so many of the websites they use are so broken.
`_` being assigned the result of the last statement evaluated is an IRB feature [1], not a ruby feature - hence the note that it is not a universal solution.
It's used in Rails to reduce the likelihood of un-sanitized user input in SQL fragments [1]. I think it would see a lot more use if additional input sources were marked as tainted [2].
I tried running the source images through FineReader Online, but the images with handwriting resulted in "was not processed: the recognized document contains errors". The website image worked, but was missing a few elements, like the other headings on the line with "Minimalist editor".
Running tesseract (4.0.0 using the LSTM engine) on the same images leaves a lot to be desired for handwriting, but does well on the (non-handwriting) website image (the source images are linked in the "OCR Image Processing Results" section).
Have a specific image you'd be interested in seeing tested? The article only contains a few examples that could be freely used, but images with sparse random text (e.g. [1]) do tend to have good results across all the services.
That's a good point not explained in the article: there are a huge number of use cases for OCR. In this case, the use is extracting words that can be used in full-text search, so structural extraction isn't a key criteria.
Edit: and now it's hopefully clarified in the article itself. :)
It would also be difficult for said professionals to detect IP-(range)-specific backdoors (with as much obfuscation as you like; only send on Tuesdays; encrypted using a string constant elsewhere in the binary), in App Store delivered binaries that are harder to vary per downloader.
Some web apps - [Cryptee](https://crypt.ee/threat-model) is a notable example - address this with a "trust on first use" approach, that makes any change to the (web) code require approval, but that's in the same realm as a desktop app, where you've trusted it on the first download, and trust it to have actually followed through on that promise.