The page isn't allowed to know what extensions you have, instead LinkedIn is looking for various evidence that extensions are installed, like if an extension was to create a specific html element, LinkedIn could look for evidence of that element being there.

Since the extensions are running on the same page as LinkedIn (some of them are explicitly modifying the LinkedIn the website) it's impossible to sandbox them so that linked in can't see evidence of them. And yes this is how a site knows you have an ad blocker is installed.

Page can know what your chrome extensions are, even when your extensions don't interact with the site, by fetching `web_accessible_resources`: https://browserleaks.com/chrome#web-accessible-resources-det... . uBO mitigates this partly by generating internal secret tokens for each request: https://github.com/gorhill/uBlock/tree/master/src/web_access... .

However, there are other proof of concept of another attack vector to bypass this by using timing difference when fetching those resources.

I help maintaining uBO's lists and I've seen one real world case doing this. It's a trash shortener site, and they use the `web_accessible_resources` method as one of their anti-adblock methods. Since it's a trash site, I didn't care much later.