How do you deal with hostile browser extensions?
replies(5):
I am trying to detect Google Translate and print a warning then.
It really sucks when extensions do fudgy stuff in global space and sometimes break your stuff though, agree. Best approach I've found is to have a help page you can link to so people can go through the typical steps of "disabling all extensions, clearing cache, etc, etc" when things break in very unexpected way and you find no causes for it.
Having this idea and opening a random page (from The Guardian) on DevTools, somehow somebody's inserted scripts and iframes pointing to twitter.com.
I am not a fan of Grammarly or their technical model, but I don think it’s fair to attribute malice when it is adequately explained by stupidity.
It’s been a long time since I did any front-end work: should both Grammarly’s extension and your own code use namespaced property names?
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.
Many years ago I had performance issues with a site and the only reason I knew it was due to an extension is I dug into it with the dev tools and managed to identify Dashlane as the problem.
For more advanced CSP bypass with extension, you can:
1. Inject JS code into any webpage with a CSP.
2. Create an event listener for your content script and reacting according to it.
3. Use your content script to communicate with the background script.
4. Use the background script to communicate with any website, including blocked websites by the CSP.
Basically, any website <-> extension content script <-> background script <-> any website.
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.
Ultimately, as someone in the extension space for more than a decade now, Google is really at fault... Manifest v3 is just crappier than it should be in a LOT of ways (entirely outside the politics of the ad blocker changes - which is a whole different can o worms).
Overall, I think the quality of the chromium codebase feels a lot lower than it used to.
on edit: fixed some grammar
I'm concerned too, but from the angle that writing on the internet is becoming less human, more robot protocol. Even when it's from humans.
As if bots weren't enough of a problem, imagine when social media is just people clicking on buttons: "write a funny response", "write a comment in disagreement", "write 'same'", etc.
There should be an easy "view source" for extensions inside Chrome and extensions should be mandated to ship non-minimized code.
- Access your data for all websites
- Display notifications to you
- Access browser tabs
I guess we know why Grammarly never has any problems raising more funding.
Are you referring to the "Object captured as exception" error which Sentry refuses to give any guidance on? We just end of filtering these out client-side.
It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.
This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.
There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.
A lot of times the reason sentry can’t do much is because the browser JS VMs have terrible/non-existent stack traces, especially true with things like unhandled rejected promises.
I see people where I work not do this, and it drives me crazy. Our director of engineering will literally add tickets for himself to do things that would take less time to just do. At least I hear "I took a page from your book and messaged the person instead of adding a ticket for myself to message them" often, which is a good sign.
also, yeah, what the neighboring comment said - you do seem to think I should consider working for free...
I've done this. It irks me too, but sometimes I'm in organizational mode, and sometimes I'm in execution mode. :)
Also, I work in an environment[0] where all work is required to go through the formal tracker documentation flow (and all code changes must be approved by a second party).
So the ticket step is non-optional, and in fact required before work can begin -- we name branches with the ticket ID, so that Pivotal[1] can track the GitHub lifecycle.
[0] PCI-DSS, SOC 2, etc
[1] RIP :(
Yes, I totally agree. The point of processes is to enable a company to manage huge amounts of potential work. Sometimes, processes can get in the way of just doing the simple thing we all know needs to be done.
Buuuut, I've been on the other side of that, too. Someone asks me to make some change. Sure! That's a reasonable idea and it would improve things. Making the change would take about 20 minutes. However, 437 different systems expect that thing to have its current behavior, and updating them to use the new behavior would be quite the project. In a vacuum, the change is simple and shouldn't take long to implement. Not many things operate in a vacuum, though.
For example, it would take like 5 minutes to do a "find all" in the Nginx source code and fix the misspelling of "referrer" as "referer". It would take a lot longer to update the standards with the correct spelling, and every client and other server to use it, would be slightly more challenging.
I'm talking about things like fixing a typo, where it literally takes multiple times the work to write the ticket than to grep for it, fix it, and push a PR.
There are already extensions for this purpose.
replai.so and dozens others
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!
[0]: https://chromewebstore.google.com/detail/microsoft-editor-sp...
Your observation is spot on.