←back to thread

Et Tu, Grammarly?

(dbushell.com)
279 points dbushell | 5 comments | | HN request time: 0.515s | source
Show context
dbushell ◴[] No.43514309[source]
How do you deal with hostile browser extensions?
replies(5): >>43514670 #>>43515016 #>>43515058 #>>43516270 #>>43516486 #
1. eadmund ◴[] No.43515058[source]
I don’t think that ‘hostile’ is really fair in this case, when ‘insufficiently competent’ will do (albeit at the cost of more syllables).

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?

replies(4): >>43515091 #>>43516294 #>>43516464 #>>43516925 #
2. dbushell ◴[] No.43515091[source]
yep, it's in Grammarly's interest to namespace or scope their CSS in a way that doesn't conflict. Not doing it adequately goes both ways, website CSS could break their extension, or their extension could break the website.
3. QuadmasterXLII ◴[] No.43516294[source]
We tried applying cunningham’s law widely and it created disastrous incentives. It’s better to assume profitable yet destructive incompetence is malice.
4. chuckadams ◴[] No.43516464[source]
Any sufficiently advanced stupidity is indistinguishable from malice.
5. MartijnHols ◴[] No.43516925[source]
Unfortunately browsers don't really provide good solutions for extensions that need to inject or change sites. Look at Google's owner in-browser translate extension, its DOM manipulation breaks many interactive apps as well. There are no tools available in browsers for it to not need to do that.