Holy shit this is detailed. Can you believe the hubris to silently collect all this information on users?

#privacy

https://browsergate.eu/how-it-works/

The Attack: How it works

Every time you open LinkedIn in a Chrome-based browser, LinkedIn’s JavaScript executes a silent scan of your installed browser extensions. The scan probes for thousands of specific extensions by ID, collects the results, encrypts them, and transmits them to LinkedIn’s servers. The entire process happens in the background. There is no consent dialog, no notification, no mention of it in LinkedIn’s privacy policy. This page documents exactly how the system works, with line references and code excerpts from LinkedIn’s production JavaScript bundle.

BrowserGate

@paco

I'm more concerned with the fact that extensions *can* be detected this way. Web pages should not be able to detect the presence of extensions. If they can, that's a security vulnerability.

@argv_minus_one @paco Agreed 1000%. I've heard that this could be done and I've always wondered why browsers didn't prioritize making it an effort to block all of this.

Really there are a scary level of things that just don't get the attention they should. Like why can browsers access your clipboard by default? I don't just mean write stuff. They can use an event to read it... Browsers seriously need to make a better effort to keep sites from getting access to any of this potentially identifying/privacy violating stuff...

Of course Chrome probably does this on purpose.

@nazokiyoubinbou

Sites can *read* the clipboard??? Yikes! That could expose passwords!

@paco

@argv_minus_one @paco Yeah. They also can use it to subtly modify clipboard contents. I first became aware of this from a website where it would detect me copying text from it and then modify the clipboard contents to include what I had copied but also inject an advertisement for its own site. (It was especially annoying because it had a character limit, so cropped what I had actually copied.)

In Firefox look for dom.event.clipboardevents.enabled to turn that off. However, bear in mind this denies all direct clipboard access. For example, clicking on "copy link to clipboard" no longer works. It's a two-way street. They can't read or write to the clipboard without that. Some things (like Matrix clients for me) won't let me paste without it.

I don't know the Chromium equivalent

@argv_minus_one @paco BTW, much more than passwords.

For example, if you copy a credit card info to the clipboard such as some managers might do or gift cards or etc. That's a payment info in the clipboard right there... SSNs, IDs, etc could also rarely end up in the clipboard for various reasons.

It's a nightmare waiting to happen.

@nazokiyoubinbou @argv_minus_one @paco Granted, browsers can only read the clipboard after user interaction and asking for permission (https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API#security_considerations ).

But I’ve also not encountered a useful-enough benign example of reading a users clipboard without them actively pasting. Most things like formatting content can be done by just intercepting the paste event.

Clipboard API - Web APIs | MDN

The Clipboard API provides the ability to respond to clipboard commands (cut, copy, and paste), as well as to asynchronously read from and write to the system clipboard.

MDN Web Docs