I feel like the first thing we should talk about is how this is effectively a keylogger, similar to Windows 10's inking and typing setting, albeit with likely poorer security. Collecting everything you type into a web browser (or MS Office) and sending it to them seems like a really bad idea.
Grammarly shared its tokens with all websites
101–110 of 176 posts
Re: Grammarly shared its tokens with all websites
#102I think Chrome's (and now Firefox') awkward extension sandboxing is partially to blame, though. When you add an extension page script, you get access to a page's DOM, but you're completely isolated from the page's own JS: You get your own JS context and window object without any modifications the page may have done to it. That's usually reasonable as a page can mess with the built-in methods of its context, so if an…
Chrome and Firefox have _very_ different behaviors here.
In Chrome, there is no way at all to get hold of the page's JS objects.
In Firefox, the default behavior is that you don't interact with them, but you can explicitly ask for them and once you have them you can work with them. Depending on what you do with them, you may or may not be creating security bugs, of course.
Critically, in Firefox you can have your separate clean builtins _and_ be interacting with actual page JS objects at the same time.
There are arguments for and against both models, of course.
Re: Grammarly shared its tokens with all websites
#103I nearly missed this bit at the bottom: > Grammarly had fixed the issue and released an update to the Chrome Web Store within a few hours, a really impressive response time. Nice to see a company take this kind of thing appropriately seriously (although of course it should never have happened in the first place).
Re: Grammarly shared its tokens with all websites
#104What's the etiquette for disclosure timeline on something like this? It feels like 99.9999% of end users won't see this public disclosure, and waiting enough time for auto-updates to be applied would be ideal. Public disclosure as soon as the patch is available lets bad actors know about it while the vast majority of users are still vulnerable.
Re: Grammarly shared its tokens with all websites
#105Earlier quoted context omitted.
Yes. Google offers ADMX templates for controlling Chrome which can be deployed through group policy. It includes an extension blacklist, which accepts wildcards. In my case, I put a * in there. It also has an extension whitelist, and a list of "force-installed apps and extensions". https://support.google.com/chrome/a/answer/187202?hl=en This is one place where Google actually did really do their homework, IMHO.
Is something comparable available for Firefox?
Most software patching solutions have a way to push files though, and you can use something like this: https://www.itsupportguides.com/knowledge-base/tech-tips-tri...
Re: Grammarly shared its tokens with all websites
#106Re: Grammarly shared its tokens with all websites
#107Kind of tangential, but does anyone else worry that systems like these will start to dictate what is "correct" language. Basically pushing narratives subtly through "correcting" totally acceptable speech.
Re: Grammarly shared its tokens with all websites
#108I feel like the first thing we should talk about is how this is effectively a keylogger, similar to Windows 10's inking and typing setting, albeit with likely poorer security. Collecting everything you type into a web browser (or MS Office) and sending it to them seems like a really bad idea.
Why is this story not bigger news? Grammarly is excreting ads into my eyes before nearly every YouTube video I watch, yet I don't see any mainstream sites covering this.
Of course, in the case of Microsoft or Google, you presumably either have disabled the setting or you place your trust in their security practices that it is okay, because they are top tier companies, and most people send them all their private data anyways.
There are a LOT of things out there that collect everything you type these days, and rarely to people want to define them as keyloggers.
Re: Grammarly shared its tokens with all websites
#109Earlier quoted context omitted.
I personally stay far away from password managers, especially as browser extensions. I'd really recommend everyone look at how many of their Chrome extensions have the permission to "access your data on all websites", and consider whether or not they really trust the companies or individuals who made those extensions with that permission. It's eye-opening to people when I ask them about an extension they have, say "H…
> I personally stay far away from password managers I am curious how you manage your passwords.
Beyond that, the "never reuse passwords" adage is horribly oversold. If it handles my money, my email, or my web hosting, it needs to be unique. Passwords for places I comment are commonly reused and not as sophisticated because it is not seriously impactful to me if someone gets a hold of them.
Reuse passwords for sites that can't meaningfully harm you if they get compromised. Minimize how many accounts can harm you by not saving your credit card info in most of them, uncheck that box when you pay for stuff.
I'm also insanely liberal about deploying 2FA. I have it everywhere it's available, even sites with common/stupid passwords. So a lot of sites I don't bother with unique passwords will still be somewhat protected if my password is compromised. I'm also subscribed to haveibeenpwned with every email address I've ever used for anything.
Re: Grammarly shared its tokens with all websites
#110Earlier quoted context omitted.
Extensions modifying pages is fine, but often an extension wants to show custom UI on top of the page. It’d be much more secure to allow the extension to do that without requiring it to put this into the page. For example, currently you have the DOM of the page, and the extension’s UI is injected into it. It would be preferable if you’d treat each tab as if it was like This way an extension that wants to show secure…
As long as the extension UI is rendered where the page can also render something, it will be vulnerable to phishing. E.g. https://www.seancassidy.me/lostpass.html
If it’s a message in the browser chrome itself, and not as in the page, it is possible to add distinguishing UI.
With the current system, it’s literally impossible to distinguish the UI