There is a fresh thing going around about LinkedIn scanning extensions installed in Chrome/Chromium:https://browsergate.eu/
-
@rysiek Thank you, I was wondering about a potentially-unlawful-under-GDPR aspect to this. Much obliged.
@clickhere Article 9, the first point:
https://gdpr-info.eu/art-9-gdpr/> Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.
IANAL, I am not saying 100% illegal, but an argument can be made…
-
There is a fresh thing going around about LinkedIn scanning extensions installed in Chrome/Chromium:
https://browsergate.eu/The website claims "LinkedIn is Illegally Searching Your Computer", and implies the purpose is to find "religious beliefs, political opinions, disabilities".
tl;dr:
- yes, LinkedIn is scanning through a list of 6k+ extensions on Chrome;
- yes, this is bad;
- but the website is disingenuous in making unnecessarily overblown claims.🧵
@rysiek Thanks for the write-up of the details
Website is classic use case of seeking for attention with clickbait titles - we all can do better than that
It took time to figure out that mentioned fingerprinting is limited to Chromium based browsers and use of extensions
-
@rysiek@mstdn.social wtf why does Chrome allows an untrusted website to do that???
-
@rozie@mastodon.online @rysiek@mstdn.social
I don't think extensions having static IDs are the problem. My problem is: why is an external website allowed to access extension assets (without extension allowing it explicitly)? That sounds like a security nightmare. -
@rozie@mastodon.online @rysiek@mstdn.social
I don't think extensions having static IDs are the problem. My problem is: why is an external website allowed to access extension assets (without extension allowing it explicitly)? That sounds like a security nightmare.@Orca @rysiek I'll need to take a closer look how exactly it's made.
I was aware of the technique where extension interacting with the site (so, in a way, trusting it, but only in a way) was also allowing this site to interact with own files. With fixed ID it allowed to check if extension is present. And this is one of described techniques. Those extensions probably declare interaction with LI (or any site) via web_accessible_resources.
Without fixed ID it (fetch of the file) wouldn't work.
-
@Orca @rysiek I'll need to take a closer look how exactly it's made.
I was aware of the technique where extension interacting with the site (so, in a way, trusting it, but only in a way) was also allowing this site to interact with own files. With fixed ID it allowed to check if extension is present. And this is one of described techniques. Those extensions probably declare interaction with LI (or any site) via web_accessible_resources.
Without fixed ID it (fetch of the file) wouldn't work.
@rozie @Orca this is correct. But extensions would have had fixed IDs anyway, these are needed for other things. The problem is making it possible for fetch(chrome-extension://<extension_id>/some/file.ext) to work.
Yes, that requires the extension to declare the file via web_accessible_resources, so yes, this is also partially on the extension vendors. But this is such a glaring privacy problem that one can and should blame Google for not closing this hole.
-
@rozie @Orca this is correct. But extensions would have had fixed IDs anyway, these are needed for other things. The problem is making it possible for fetch(chrome-extension://<extension_id>/some/file.ext) to work.
Yes, that requires the extension to declare the file via web_accessible_resources, so yes, this is also partially on the extension vendors. But this is such a glaring privacy problem that one can and should blame Google for not closing this hole.
-
@rozie @Orca Firefox absolutely has fixed IDs for extensions; for example "uBlock0@raymondhill.net" is the fixed ID for uBlock Origin and you can use it in policies.json to automagically install it and configure it (say, when you are deploying to a fleet of laptops).
For example:
https://support.mozilla.org/gl/questions/1271181This also answers the question of "why are fixed IDs for extensions necessary".
-
@rozie @Orca Firefox absolutely has fixed IDs for extensions; for example "uBlock0@raymondhill.net" is the fixed ID for uBlock Origin and you can use it in policies.json to automagically install it and configure it (say, when you are deploying to a fleet of laptops).
For example:
https://support.mozilla.org/gl/questions/1271181This also answers the question of "why are fixed IDs for extensions necessary".
-
-
@rysiek @Orca No, Firefox has random IDs locally: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources
It's still accessible, just isn't known. And enumeration would be hard.
-
R relay@relay.infosec.exchange shared this topic
). I mean internal one. It's random in case of Firefox. But it's fixed and the same as the external external one in Chromium. That's why extension's files can be accessed.