Wladimir Palant

And I am a fan of making such functionality part of the browser :P : one less addon to manage & trust! Aside: the amount of insecure code in addons is scary, see https://palant.info/categories/security/ , not to mention that addons are also a frequent cause of performance trouble (source: me, experienced several times). Thus, the more dubious addon code I'm able to replace with somewhat-well-maintained-and-audited Firefox code with many eyeballs on it, the better.

(At this point, you or a passerby will point at the Pocket fiasco and argue that there's too much stuff shoved into our browsers and just stahp it already. Fair, and I love lean software too. I'd still like this specific feature because A. it's not Pocket, B. it aligns well with what Firefox is doing these days, and C. it aligns with what I expect from my user agent of choice).

Then, supposing this ever makes its way into Fx, you can choose not to use it. And by the way, maybe like you, I will make the same choice if the Fx feature is too basic! But it will remain a win, for the users for whom it's good enough and who would never have bothered with an addon in the first place. Just like ETP vs. uBlock / PrivacyBadger / etc: ETP is a good basic "80%/20%" risk-less step in the right direction, and addons remains way ahead if you the user decide to bother a bit more.

> "telling Firefox to disable [HTTPS only] mode for a specific site doesn't always work."

This looks like a bug that you should report.

You assume that regulation can just make security magically happen.

I see no reason to assume that premise to be correct in practice. It's not like the US Government hasn't been breached countless times or had Supreme Court opinions leaked; and it's not like corporations that really tried and should be examples of best practice haven't also been breached. Also, what law can prevent insider attacks? There's already plenty of laws making that illegal.

There's no law that just "makes security happen" - and, actually, I would be fundamentally opposed to such a law because it turns security into a simple matter of compliance. "We're SCA compliant, therefore we're good!" And technology changes way too much - a security law that was written 10 years ago would be a disaster today. See South Korea's Banking Security laws for an example - they basically enshrined ActiveX in their law with roll-your-own-crypto to this day. And we know now that was a trash idea but nobody wants to take the blame for upsetting the security standards. https://palant.info/2023/01/02/south-koreas-online-security-dead-end/

Thing is: this is the third article on the topic I wrote in the past few days. Covering your options wasn’t the goal here, it’s in the first article: https://palant.info/2022/12/23/lastpass-has-been-breached-what-now/. Particularly the “executive summary” at the start.

As to the “speculations”: I have sufficient experience with LastPass press releases to assume the worst whenever they omit details that they should definitely know. On a number of occasions they covered security vulnerabilities that I found, and I know how they operate.

Mind you, I would be more than happy to learn that I’m wrong. But this isn’t a situation where “hope for the best” is a viable approach.

Note: I did not claim that LastPass is storing master passwords. They claim that they built their system in a way that they cannot. And I merely point out that this isn’t true: they could have built their system in such a way, but they chose not to, despite being warned about it repeatedly.

I said this in a reply comment, but it's likely Honey lost it due to mass reporting or _maybe_ (but unlikely) a manual decision, and now that time has passed, they've applied again (the badge "nomination" is just a form you fill in) after a short while and either the manual reviewer was unaware, or it just doesn't matter to the process, as the requirement are quite low.

It's possible larger extensions (1+ mil) have some sway/means to contact internally, but imo Google really doesn't pay much heed to "controversial"/topical things (perhaps apart from ublock). Or developers in general.

It becomes evident when you read some extensive related articles by Wladimir Palant (https://palant.info) [0] who does some pretty deep dives on the Chrome Store. I think he even developed Adblock Plus (the open-source version).

[0] I'm unaffiliated, just a reader.

Google spent all that time pushing Manifest V3 but does little to prevent this, and in some cases even encourages it. [1]

> To provide a more tangible example, Chrome Web Store currently has Blaze VPN, Safum VPN and Snap VPN extensions carry the “Featured” badge. These extensions (along with Ishaan VPN which has barely any users) belong to the PDF Toolbox cluster which produced malicious extensions in the past. A cursory code inspection reveals that all four are identical and in fact clones of Nucleus VPN which was removed from Chrome Web Store in 2021. And they also don’t even work, no connections succeed. The extension not working is something users of Nucleus VPN complained about already, a fact that the extension compensated with fake reviews.

[1] https://palant.info/2025/01/13/chrome-web-store-is-a-mess/

Don't bother. It's hard to do it correctly. If you look through the snippets (or the MDN docs[1]), the value is retrieved using the getParameter() function. You might be tempted to override the function by doing something like

gl.getParameter = () => "test"

but that's easily detectable. If you run

gl.getParameter.toString()

You get back

"() => "test""

whereas the original function you get back

"function getParameter() { [native code] }"

In general, don't try to fix fingerprinting via content scripts[2]. It's very much detectable. Your best bet is a browser that handles it natively.

[1] https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info

[2] https://palant.info/2020/12/10/how-anti-fingerprinting-extensions-tend-to-make-fingerprinting-easier/