LinkedIn is far from the only actor doing this. Browser extension fingerprinting is not new. LinkedIn‘s size, scope, network effects make this especially concerning.
They have! It's these developers either not knowing or not caring about it which is the issue!
I did a blog post about this a while back showing how they do it, and how you can get around it, it's not very complex for the devs.
> Chrome have fortunately recently released a "extension side panel" mode, and since only DOM changes can be easily identified, using the chrome extension side panel would be virtually un-detectable however this is far less intuitive to use and requires the user to perform some action to open the sidepanel every time they want to use the extension.
As an end user I could not find an option to open the side panel
Yeah I mean it's not very commonly used by extensions. I quite like it as it's completely isolated and not detectable.
I built my first extension which uses it as the primary interface yesterday: https://github.com/Am-I-Being-Pwned/PGP-Tools
Yeah I agree. All new extensions should have this for their web_accessible_resources.
With that said, the chrome web store ecosystem has bigger problems infront of them. For example, loads of extensions outright just send every URL you visit (inc query params) over to their servers.
Things like this just shouldn't happen, imagine you installed an extension from a few years back and you forgot about it, that's what happened to me with WhatRuns, which also scraped my AI chats.
I'm working on a tool to let people scan their extensions (https://amibeingpwned.com/) and I've found some utterly outrageous vulnerabilities, widespread affiliate fraud and widespread tracking.
There's nothing to patch, scanning is not possible.
It's either the extension's choice to become detectable ("externally_connectable" is off by default) or it makes unique changes to websites that allow for its detection.
If it were just a matter of detecting changes to the DOM then this could only detect extensions that alter the LinkedIn website itself. I agree that would be much harder to make undetectable, but this seems like it goes beyond that.
As mentioned, there's a way to expose your extension to the web even without making changes. The other way is a key called "web_accessible_resources".
All of these are opt-in by the extensions and MV3 actually force you to specify which domains can access your extension. So, again, each extension must explicitly allow the web to find it.
Seems like it. Which is serious but far from what I thought when I read the title. I suspect 90% of LinkedIn users don't even have a single browser extension installed.
I would debate that. Most work computers have some extensions installed by default. That's millions of laptops. Ex. Snow Inventory Agent, ad blockers etc.
GrapheneOS is Android's last hope. They're making great progress with deals with smartphone manufacturers. However, the threat of remote attestation looms eternal. I have essential apps that I cannot afford to lose and if they refuse to work on a non-Google phone the usefulness of GrapheneOS is severely degraded.
If attestation ever became ubiquitous the difference between iOS and Android would cease to exist for me. I'd need a black box that lived in a desk drawer for interfacing with specific services and otherwise I'd cart around a camera in my pocket that happened to double as a linux tablet.
No, the solution is having a linux micro-computer. You buy an iPhone shitphone to do banking and whatnot, and never touch it, then just do everything you need off a retroconsole since it runs literally 120% of the other apps a phone would.
Yeah, some bits (parts of the GUI & some of the default apps) are still closed.
But I think there is a good chance they will finally open those now - never really made any sense to keep them closed and preventing the community from contributing. Rumors had it it was due to non-cooperative investors.
Not Jolla is finally independent again, so at least in theory they can finally do the right thing. :)
So if we pretend a list is a function from an index to an entry for the moment
```
Enum.take(list , 2)
```
Is more like
```
Enum.take(list, [1,2])
```
So if you apply that to a list of length 1 or zero, you just get either list[1], or []
The difference is that Enum is maybe a total function - the domain of the function is always well defined, while Map take is trying to be dressed up as a total function but its really something thats only partial.
So the type system needs a way to describe a map that has "at least these keys" a bit like the enum case. So that requires some polymorphism.
But thats the point, an llm is a vastly different object to a calculator. Its a new type of tool for better or worse based on probabilities, distributions.
If you can internalise that fact and look at it like having a probable answer rather than an exact answer it makes sense.
Calculators cant have a stab at writing an entire c compiler. A lot of people cant either or takes a lot of iteration anyway, no one one shotted complicated code before llms either.
I feel discussion shouldnt be about how they work as the fundamental objection, rather the costs and impacts they have.
reply