Cromite (Bromite fork)

qwq · July 20, 2023, 4:31pm

One of the main contributors to Bromite has now officially forked it and created Cromite.

Uazo has been maintaining a Bromite dev/test build for a while now over at GitHub - uazo/bromite-buildtools: my build machine for bromite development. In the latest release there’s an announcement that new releases will be in the new Cromite repository linked above.

Note: there aren’t any binaries released in the Cromite “releases” page yet.

anon30510143 · July 20, 2023, 4:43pm

We’ll probably want to wait and see how the project does for a while before considering it.

SkewedZeppelin · July 20, 2023, 5:10pm

still no 32-bit support and updates can take up to two weeks

not_a_homosapien · July 22, 2023, 6:40am

Cromite seems to be promising but It blocks automatic https upgrades and Content Security Policy reports; which harm security

jonah · July 26, 2023, 2:35am

I don’t see how blocking CSP reports harms security, and HTTPS-only mode is enabled by default. CSP reports can be used to fingerprint installed extensions:

github.com/LiCybora/NanoDefenderFirefox

Extension acts as fingerprinting beacon on strict CSP with report-uri sites

opened 03:39PM - 09 Dec 20 UTC

ntninja

Many websites nowadays use a security technology called [Content Security Policy… (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) to limit what attackers can do in case of compromise on the site. When deployed with strict settings this prevents any use of `eval` or `<script>` tags to execute JavaScript code on-the-fly: All of the page's scripts (and also CSS, etc) must be served from a set of trusted origins specified in the policy instead. This rule also applies to any scripts injected by extensions using `window.eval` or `document.createElement("script")`. The above would only render NanoDefender Pro ineffective on such sites, however CSP includes another feature that many sites use to monitor the issues caused by their CSP in the field called `report-uri`: Using this, a site can specify an arbitrary URL to be pinged whenever the browser detects a CSP violation. This again includes violations caused by extension scripts, like on the following example page (https://mm-csp-example.herokuapp.com/ was set up to test a related CSP issue with another extension): ```json { "csp-report": { "blocked-uri": "inline", "column-number": 33, "document-uri": "https://mm-csp-example.herokuapp.com/", "line-number": 214, "original-policy": "default-src 'self'; connect-src 'self'; font-src 'self'; frame-src 'self'; img-src 'self'; script-src 'self'; style-src 'self'; report-uri https://mm-csp-example.herokuapp.com/report_csp", "referrer": "", "source-file": "moz-extension://22f938b7-43d7-410d-91c6-80262d30dbd7/content/core.js", "violated-directive": "script-src" } } ``` This can even include “samples” of the blocked content like in the following real-world example of undisclosed origin: ```json { "csp-report": { "blocked-uri": "inline", "column-number": 33, "document-uri": "…", "line-number": 214, "original-policy": "default-src 'none'; connect-src 'self' …; font-src 'self' … data:; img-src 'self' … data: …; script-src 'report-sample' 'self' 'unsafe-eval' …; object-src …; manifest-src …; media-src …; style-src 'self' 'unsafe-inline'; frame-src …; worker-src …; report-uri …/csp", "referrer": "…", "script-sample": "(() => {\n try {\n let _…", "source-file": "moz-extension://22f938b7-43d7-410d-91c6-80262d30dbd7/content/core.js", "violated-directive": "script-src" } } ``` If that isn't a textbook example of a perfect fingerprinting vector based on the list of installed non-CSP-compliant extensions then I don't know. Even without the “script sample”, the combination of “just” the script name and line and column numbers is likely enough to unique identify every CSP violating extension in existence. And as I've discovered today, yours is by far not the only extension causing these kinds of reports to be generated. So how to fix this? Well, the [inject](https://github.com/LiCybora/NanoDefenderFirefox/blob/2006d69afdefbbb2dcd1b2dca31bb2a516efc4d1/src/content/core.js#L209-L224) function and everything calling it will have to be rewritten in terms of the recommendations of the MDN article on [Sharing objects with page scripts](https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/Sharing_objects_with_page_scripts). In particular this means: Accessing page objects only through the `.wrappedJSObject` accessor (“X-Ray Vision”) and exporting objects from the content-script to the page scope using `exportFunction`/`cloneInto` only. Unfortunately, this whole concept is completely foreign to Chromium-based browsers (where using `window.eval` and related techniques is indeed the right thing to do), so the whole code currently in place needs to be retained if you want to continue supporting non-Firefox browsers as well.