hackademix.net

Today Mozilla released Firefox 87, introducing SmartBlock, a new feature which "intelligently fixes up web pages that are broken by our tracking protections, without compromising user privacy [...] by providing local stand-ins for blocked third-party tracking scripts. These stand-in scripts behave just enough like the original ones to make sure that the website works properly. They allow broken sites relying on the original scripts to load with their functionality intact."

As long time NoScript users may recall, this is exactly the concept behind "Script Surrogates", which I developed more than ten years ago as a NoScript "Classic" module.

In facts, in its launch post Mozilla kindly wants "to acknowledge the NoScript and uBlock Origin teams for helping to pioneer this approach.".

It's not the first time that concepts pioneered by NoScript percolate into mainstream browsers: from content blocking to XSS filters, I must admit it gets me emotional every time :)

Script Surrogates unfortunately could not be initially ported to NoScript Quantum, due to the radically different browser extensions technology it was forced into. Since then, many people using NoScript and other content blockers have been repeatedly asking for this feature to come back because it "fixed" many sites without requiring unwanted scripts (such as Google Analytics, for instance) to be enabled or ad-blocking / anti-tracking extensions to be disabled.

Script Surrogates were significantly more powerful, flexible and user-hackable than SmartBlock, and I find myself missing them in several circumstances.

I'm actually planning (i.e. trying to secure time and funds) to bring back Script Surrogates as a stand-alone extension for Firefox-based and Chromium-based browsers, both on desktop and mobile devices. This tool would complement and enhance the whole class of content blockers (including but not limited to NoScript), without requiring the specific installation of NoScript itself. Furthermore, its core functionality (on-demand script injection/replacement, native object wrapping/emulation...) would be implemented as NoScript Commons Library modules, ready to be reused by other browser extensions, like already happening with FSF's in-progress project JS-Shield.

In the meanwhile, we can all enjoy Script Surrogate's "light", mainstream young sibling, built-in in Firefox (and therefore coming soon in the Tor Browser too). Yay Mozilla!

I've just received an email from Stephen Etheridge (Avast):

Hi there, I am a Product Manager for CCleaner and I'd like to share some information regarding a recent incompatibility between CCleaner and Firefox 79 regarding extension settings storage.

The issue is covered in the following threads:

• CCleaner Forum - CCleaner deletes NoScript Settings on Firefox
• NoScript Forum- CCleaner wiping out extensions settings in Fx 79

As I am sure you are aware, this relates to the Firefox 79 change described here.

I wanted to share what information we have about this so that you can help your users avoid issues when using CCleaner. Here's what we know:

Users Affected

• Use Firefox with a logged-in Firefox account
• Have ‘Sync’ enabled in Firefox

Behaviour Observed

• For most Firefox extensions tested, settings data in storage-sync-v2.sqlite-wal and storage-sync-v2.sqlite-shm is wiped but then later restored
• For NoScript, this data seems to be permanently deleted and not restored
• We have observed that the v2 syncing process can take some time, depending on the amount of settings data
• From your forums, it seems it *may* be possible to restore the NS preferences from an old sqlite file, if one exists

Next Steps

• The CCleaner team is working on a hotfix release as an urgent priority. The fix will prevent CCleaner from removing 'storage-sync-v2.sqlite-wal' and ' storage-sync-v2.sqlite-shm'.
• We expect to be able to release this very soon (days rather than weeks)

In the interim, below is some info that you can share with your users to prevent CCleaner from removing these files, until we can release a fix.

Temporary Workaround

This workaround is best suited for somewhat technical users. It applies to CCleaner's Custom Clean only (not the Health Check method).

• If using CCleaner Professional, temporarily disable Smart Clean for Firefox (so CCleaner doesn’t clean Firefox automatically when you close it)
• Open Firefox and access your extensions
• Close Firefox
• Open CCleaner and go to Custom Clean
• Click on Analyze
• Double-click on 'Firefox - Internet Cache' (expand the window to see the full pathnames, if needed)
• Right-click on '...\storage-sync-v2.sqlite-wal'
• Select 'Add to Exclude list'
• Right-click on '...\storage-sync-v2.sqlite-shm'
• Select 'Add to Exclude list'
• You can re-enable Smart Clean for Firefox if you previously disabled it in Step 1

Notes:

• This avoids the issue while still allowing Firefox to be cleaned normally.
• File exclusions apply to Custom Clean only (Health Check does not read the Exclude list).

Update 2020-08-06

Further email from Stephen Ethereidge:

I'm happy to tell you that we have released a fix for this today in CCleaner v5.70.

CCleaner Professional users will be updated automatically if they have automatic updates enabled. CCleaner Free users can update via the following link:

Download: https://www.ccleaner.com/ccleaner/download/standard

Release Info: https://www.ccleaner.com/knowledge/ccleaner-v5707909

CCleaner Free Installer MD5: 19430f70ccf57837eca389ee422e8882
CCleaner Free Installer SHA-256: 825e7adc69360a9820be17603ec93aace7e998d3278b33b16048d9452f1ba860

Please accept our apologies for any inconvenience caused to your users.

As the readers of this blog almost surely know, I'm the author of NoScript, a web browser security enhancer which can be installed on Firefox and Chrome, and comes built-in with the Tor Browser.

NoScript has received support by the Open Technology Fund (OTF) for specific development efforts: especially, to make it cross-browser, better internationalized and ultimately serving a wider range of users.

OTF's mission is supporting technology to counter surveillance and censorship by repressive regimes and foster Internet Freedom. One critical and strict requirement, for OTF to fund or otherwise help software projects, is them being licensed as Free/Libre Open Source Software (FLOSS), i.e. their code being publicly available for inspection, modification and reuse by anyone. Among the successful projects funded by OTF, you may know or use Signal, Tor, Let's Encrypt, Tails, QubeOS, Wireshark, OONI, GlobaLeaks, and millions of users all around the world, no matter their political views, trust them because they are FLOSS, making vulnerabilities and even intentionally malicious code harder to hide.

Now this virtuous modus operandi is facing an existential threat, started when the whole OTF leadership has been fired and replaced by Michael Pack, the controversial new CEO of th U.S. Agency for Global Media (USAGM), the agency OTF reports to.

Lobbying documents emerged on the eve of former OTF CEO Libby Liu's defenestration, strongly suggesting this purge preludes a push to de-fund FLOSS, and especially "p2p, privacy-first" tools, in favor of large scale, centralized and possibly proprietary "alternatives": two closed source commercial products are explicitly named among the purportedly best recipients of funding.

Beside the weirdness of seeing "privacy-first" used as a pejorative when talking about technologies protecting journalists and human rights defenders from repressive regimes such as Iran or People's Republic of China (even more now, while the so called "Security Law" is enforced against Hong Kong protesters), I find very alarming the lack of recognition for the radical importance of the tools being open source to be trusted by their users, no matter the country or the fight they're in, when their lives are at risk.

Talking of my own experience (but I'm confident most other successful and effective OTF-funded software projects have similar stories to tell): I've been repeatedly approached by law enforcement representatives from different countries (including PRC) - and also by less "formal" groups - with a mix of allegedly noble reasons, interesting financial incentives and veiled threats, to put ad-hoc backdoors in NoScript. I could deny all such requests not because of any exceptional moral fiber of mine, even though being part of the "OTF community", where the techies who build the tools meet the human rights activists who use them on the field, helped me growing awareness of my responsibilities. I could say "no" just because NoScript being FLOSS made it impractical/suicidal: everyone, looking at the differences in the source code, could spot the backdoor, and I would loose any credibility as a security software developer. NoScript would be forked, in the best case scenario, or dead.

The strict FLOSS requirement is only one of the great features in OTF's transparent, fair, competitive and evidence-based award process, but I believe it's the best assurance we can actually trust our digital freedom tools.

I'm aware of (very few) other organizations and funds adopting similar criteria, and likely managing larger budgets too, especially in Europe: so if USA really decides to give up their leadership in the Internet Freedom space, NoScript and other tools such as Tor, Tails or OONI would still have a door to knock at.

But none of these entities, AFAIK, own OTF's "secret sauce": bringing together technologists and users in a unique, diverse and inclusive community of caring humans, where real and touching stories of oppression and danger are shared in a safe space, and help shape effective technology which can save lives.

So please, do your part to save Internet Freedom, save OTF, save trust.

The problem

Google's "Manifest V3" ongoing API changes are severely hampering browser extensions in their ability to  block unwanted content and to enforce additional security policies, threatening the usefulness, if not to the very existence, of many popular privacy and security tools. uBlock's developer made clear that this will cause him to cease supporting Chromium-based browsers. Also EFF (which develops extensions such as HTTPS Everywhere and Privacy Badger) publicly stigmatized Google's decisions, questioning both their consequences and their motivations.

NoScript is gravely affected too, although its position is not as dire as others': in facts, I've finished porting it to Chromium-based browsers in the beginning of 2019, when Manifest V3 had already been announced. Therefore, in the late stages of that project and beyond, I've spent considerable time researching and experimenting alternate techniques, mostly based on standardized Web Platform APIs and thus unaffected by Manifest V3, allowing to implement comparable NoScript functionality albeit at the price of added complexity and/or performance costs. Furthermore Mozilla developers stated that, even though staying as much compatible as possible with the Chome extensions API is a goal of theirs, they do not plan to follow Google in those choices which are more disruptive for content blockers (such as the deprecation of blocking webRequest).

While this means that the future of NoScript is relatively safe, on Firefox and the Tor Browser at least, the browser extensions APIs and capabilities are going to diverge even more: developing and maintaining a cross-browser extension, especially if privacy and/or security focused, will become a complexity nightmare, and sometimes an impossible puzzle: unsurprisingly, many developers are ready to throw in the towel.

What would I do?

The collection of alternate content interception/blocking/filtering techniques I've experimented with and I'm still researching in order to overcome the severe limitations imposed by Manifest V3, in their current form are best defined as "a bunch of hacks": they're hardly maintainable, and even less so reusable by the many projects which are facing similar hurdles. What I'd like to do is to refine, restructure and organize them into an open source NoScript Commons Library. It will provide an abstraction layer on top of common functionality needed to implement in-browser security and privacy software tools.

The primary client of the library will be obviously NoScript itself, refactored to decouple its core high-level features from their browser-dependent low-level implementation details, becoming easier to isolate and manage. But this library will also be freely available (under the General Public License) in a public code repository which any developer can reuse as it is or improve/fork/customize according to their needs, and hopefully contribute back to.

What do I hope?

Some of the desired outcomes:

• By refactoring its browser-dependent "hacks" into a Commons Library, NoScript manages to keep its recently achieved cross-browser compatibility while minimizing the cross-browser maintenance burden and the functionality loss coming from Manifest V3, and mitigating the risk of bugs, regressions and security flaws caused by platform-specific behaviors and unmanageable divergent code paths.
• Other browser extensions in the same privacy/security space as NoScript are offered similar advantages by a toolbox of cross-browser APIs and reusable code, specific to their application domain. This can also motivate their developers (among the most competent people in this field) to scrutinize, review and improve this code, leading to a less buggy, safer and overall healthier privacy and security browser extensions ecosystem.
• Clearly documenting and benchmarking the unavoidable differences between browser-specific implementations help users make informed choices based on realistic expectations, and pressure browser vendors into providing better support (either natively or through enhanced APIs) for the extensions-provided features which couldn't be optimized for their product. This will clearly outline, in a measurable way, the difference in commitment for a striving ecosystem of in-browser security/privacy solutions between Mozilla and other browser vendors, keeping them accountable.
• Preserving a range of safe browsing options, beyond Firefox-based clients, increases the diversity in the "safe browsing" ecosystem, making web-based attacks significantly more difficult and costly than they are in a Firefox-based Tor Browser mono-culture.

I want you!

Are you an extensions developer, or otherwise interested in in-browser privacy/security tools? I'd be very grateful to know your thoughts, and especially:

1. Do you think this idea is useful / worth pursing?
2. What kind of features would you like to see supported? For instance, content interception and contextual blocking, filtering, visual objects replacement (placeholders), missing behavior replacement (script "surrogates"), user interaction control (UI security)...
3. Would you be OK with a API and documentation styles similar to what we have for Firefox's WebExtensions?
4. How likely would you be to use such a library (either for an existing or for a new project), and/or to contribute to it?

Many thanks in advance for your feedback!

As you may have noticed, NoScript Quantum's placeholders for blocked embeddings has an animation moving the NoScript snake icon from the center to the top left side when you hover it, in order to make the label more readable.
Some people can find this annoying, but fortunately in WebExtensions everything is made of standard web stuff, like HTML and CSS, and it's relatively easy to change the placeholder to any appearance you prefer.
In this case, to make it static and discreet, you could use the Stylus extension to create a new "Static NoScript Placeholder" with all the default settings and this content:

a.__NoScript_Placeholder__ {
    background-size: 64px !important;
    background-position: 0 0 !important;
    transition: none !important;
}