HN Reader

My extension problem story is a bit different. We distribute an extension that makes it easy to switch between proxy servers for geolocation testing.

I ran my worst client demo ever a few months ago. It was like our product simply didn’t work. A lot of pulled hair and frustrating debugging later we discovered that a recent update to the 1Password extension broke ours. They were subscribing to an auth event, but not returning, this timed out so our subscriber was never called. So our extension would tell the browser to change proxy servers, then sit ready to provide credentials, but the request would never come. 1Password’s support team was better than grammerly’s, but it’s hard to convince an unknown PM to prioritize something, especially if you’re speaking to them via a support team.

We’ve since discovered that there’s some Russian extension you need for government websites that has the same issue.

If you're injecting scripts or styles into unknown pages, the least you can do is namespace your variables.

I passed this along to the engineering team.

How do you deal with hostile browser extensions?

I wonder what one variable could be injected to most break the web. I’m feeling:

  --primary-color: transparent

At work we have a lot of sentry errors related to browser extensions doing weird stuff.

Chrome’s Google translate is also notorious for breaking react based sites.

It ends up being a tedious triage process to ignore each new extension issue. We use the client side filtering to reduce our ingest volume. In general we have to have a lot higher thresholds to handle the noise vs our backends.

Hey. I’m an engineer at Grammarly Extension. First of all, I’m really sorry that our extension broke the UX on dbushell.com and caused the author to spend time and effort figuring this out.

That was never intentional, and we are using various techniques to prevent this from happening. Unfortunately, that wasn’t enough. The article clearly shows that there’s room for improvement.

We temporarily added an exception for dbushell.com as a quick fix. In the meantime, we’re working on a change to ensure proper style isolation; such issues must never be the case.

Thank you!

Do you know how they managed to inject stylesheets into every page bypassing CSP?

Makes me wonder if you can use this to hijack their plugin. At the very least you should be able to inject text into it, but you can probably render a pretty little login form as well, abusing the trust the user has in their extension. Is injecting elements into a document controlled by others really safe?

  - Access your data for all websites
  - Display notifications to you
  - Access browser tabs

> They could also, you know, not inject their code into every web page ever, unless the extension is actually used?

I guess we know why Grammarly never has any problems raising more funding.

I am happy with Microsoft's free grammar checker extension - Microsoft Editor [0], which supports foreign languages as well... although I still pay for Grammarly. Microsoft's works more smoothly and on more sites, including Hacker New!

[0]: https://chromewebstore.google.com/detail/microsoft-editor-sp...

Et toi

I've a similiar problem with Google Translate that breaks my web app. Users, using Google Translate, complaining my app is broken, but it was Google changing the state of my app from a higher meta level. Really bad practice..

I am trying to detect Google Translate and print a warning then.

Its frightening to see how many screenshares and recordings contain that green infestation as default on every website, not just the obvious visual disturbance (am i the only one who thinks the green is ugly and clashes with most websites colors?) that does not seem to bother users but the privacy and obvious attack vectors that come with it. Chrome can enable extensions only when needed why does no one do this? Why is this not the default on every browser?