Here’s what we know about BrowserGate.

What is BrowserGate?

The BrowserGate report is an exposé by Fairlinked - the Alliance for digital fairness e.V.. Its Executive Summary has a good overview of their allegations against LinkedIn.

The BrowserGate Website is very thorough in its explanations and evidence. I recommend reading it.

What is LinkedIn doing?

In short, LinkedIn is collecting data on what browser extensions their users have installed on any Chrome-based browser. LinkedIn’s own affadavit has verified that they have extension detection mechanisms, and that they’re concerned about Chrome extensions.

They’ve been doing this since at least 2017, when they were scanning for 38 browser extensions. In 2024, they were checking for over 450.

Now, they try to identify whether you are using any of over 6,000 plugins. And they check this without asking or warning you.

How are they doing this?

The technical details are on the Browsergate “How It Works” page. But let’s talk layperson for a minute.

As prep, LinkedIn has stored a list of those >6,000 extensions it decided it was interested in.

Now we get to the user interacting with LinkedIn in a Chrome-based browser. On EVERY page load, LinkedIn tries to identify the extensions that the user has installed. It does this in 3 steps.

Stage 1: Asking Politely

First, LinkedIn uses official channels (Chrome’s externally_connectable messaging API) to try to contact every extension on its list.

This is the reasonable way for a website to try to interact with extensions it expects to see.¹

Some extensions will respond.

Others choose not to use the externally_connectable messaging channel because they do not want to interact with anyone. Those extensions will not respond.

If they don’t respond, LinkedIn moves on to Stage 2.

Stage 2: Peeping Through the Bathroom Window

This Is Bad. If an extension does not interact via the externally_connectable channel, it does not want to connect with you. Any attempts to connect to that extention or extract data from it are, functionally, hacking into the extension.

LinkedIn ignores this and tries to get data from the extension anyway.

To do this, LinkedIn exploits the fact that extensions sometimes have files that need to be available to the browser or other extensions. LinkedIn asks the extension to show it one of these files.

Per BrowserGate, [t]his is the equivalent of checking whether a door is unlocked by trying the handle. I think of it more as checking every window in a house to see if someone’s left a curtain open.

If the extension’s developer left that door unlocked, or the window curtain open, the extension will expose that file to LinkedIn.

If the extension has no web-accessible resources, LinkedIn gets nothing, and moves to Stage 3.

Stage 3: Checking if you Repainted

Ugh.

So, when LinkedIn sends info to your browser, it sends it in the form of an HTML file. That tells you what your browser needs to do to show you the webpage that you asked for.

That’s all that LinkedIn needs to do. Once the HTML is out of LinkedIn’s hands, they have presented you with the data you need, and their job is done.

After that, your extensions might make changes to that HTML. If you remember the “Cloud-to-Butt” extension from the mid-twenty-teens, it looked through the HTML, removed any text with the word “cloud”, and replaced it with the word “butt”.

Some extensions make changes that are more identifiable, by including the extension’s name or other fingerprints in the HTML after they’re done.

LinkedIn looks for these fingerprints in the final HTML, to try to identify extensions that may have affected the HTML it sent you.

Using This Data

With these three scraping mechanisms, LinkedIn makes a list of which extensions you have (from their list of >6,000). It sends those results back to LinkedIn Servers.

From there, we dont know what they do.

Their affadavit indicates they may use this data as part of their automated services to block users.

The part we at Unshittify find scary is that the data they scrape includes highly sensitive medical, religious, and political affiliation data, which they can trivially associtate with the professional data that logged-in users voluntarily provide to LinkedIn, as is necessary to effectively use the site.

Our Thoughts

This looks VERY bad.

Privacy Issues

We believe that a company collecting data on their users without consent is a grevious privacy violation.

The EU and other jurisdictions have laws like the GDPR - that law is why we have cookie consent banners everywhere. It’s why we get the option to select our cookie preferences!

Now, we at Unshittify are US-based, and unfortunately we don’t live in California, so we don’t get the protective benefits of the GDPR or other privacy laws. But we’d say that meeting the GDPR’s privacy protection and data collection consent requirements is a decent baseline bare minimum that a company should be meeting.

It appears that LinkedIn is blatantly flouting those requirements.

It is unacceptable that LinkedIn did not give us the opportunity to refuse consent for this data collection, especially given that they are collecting this data in ways that disregard built-in consent checks.

LinkedIn appears to be far overstepping the bounds of the data collection necessary to enforce their terms of service, and has barreled straight into cartoonishly villainous mass surveillance and corporate espionage.

Both the breadth and specificity of the extensions they are searching for is obscene:

The scan doesn’t just look for LinkedIn-related tools. It identifies whether you use an Islamic content filter (PordaAI — “Blur Haram objects, real-time AI for Islamic values”), whether you’ve installed an anti-Zionist political tagger (Anti-Zionist Tag), or a tool designed for neurodivergent users (simplify). Under GDPR Article 9, processing data that reveals religious beliefs, political opinions, or health conditions requires explicit consent. LinkedIn obtains none. BrowserGate

There is no excuse for them to be checking if a user is potentially Muslim, or neurodivergent, or disabled. There is no reason for them to try to identify anti-zionist or anti-woke users.

And even without those specific searches, the breadth of what they search for would allow LinkedIn to profile their users. How do we know they aren’t using that to hide jobs, suppress applications, decrease search position?

How do we know they won’t sell that profile, linked to our real name, face, location, and professional information, to the highest bidder?

Will they give it to the government without a warrant? Will they give it up if the government threatens to break up their monopoly?

Are they using this data to gain an unfair advantage over their (meager) competetors? To identify their competetors’ customer lists?

Are they identifying what standard security software and extensions different companies use? Are they willing to sell that data? To whom?

LinkedIn, by scraping this data, has a tremendous amount of very dangerous data available to them, and the BrowserGate report has made a convincing argument of at least 17 laws across at least 8 different jurisdictions that LinkedIn may have broken in collecting it.

No single company should have the power to do this. No company should feel like they are that far above the law.

What now?

We’re individuals. What can we do? LinkedIn is, functionally, a monopoply. It’s the place to look for and post jobs. We don’t have power here, do we?

We have some power.

We recommend the following actions.

Do not use LinkedIn.

If you can help it, use something else.

On the Job Search side, ZipRecruiter, Indeed, 80,000 Hours, looking at Google Maps for companies near you and going to their website to look at listings. Anything to avoid their site.

On the Job Posting side: if you have any authority about this at your workplace, try to get your job listings posted somewhere other than LinkedIn, to help protect your potential applicants.

Use a Non-Chromium Browser

LinkedIn’s extension scraping only works on Chrome-based (chromium) browsers. Using a different browser prevents them from viewing your extensions.

Unfortunately, a lot of web browsers are based on Chromium, including Google Chrome (obviously), Microsoft Edge (surprisingly), Opera, Vivaldi, and Brave, among others.

Both Safari and Firefox are not Chromium-based, and therefore are safe from LinkedIn’s scraping. We use and currently recommend FireFox, because it is open source, available on all major platforms, and has good privacy protections.²

Use a clean browser - or curated extensions

This is the weakest way to protect yourself.

If you must use a Chromium browser, only access LinkedIn from a browser with one of the following setups:

• No extensions - to prevent LinkedIn from getting extra data about you.
• A very curated set of extensions - to present a specific persona to LinkedIn (and anyone else who gets their data)
• OR a very confusing set of extensions entirely unrelated to you - to attempt to poison population-level data they’re collecting.

Call Your Legislators

In the US, find out who represents you on a state and federal level.

Then call them. Or email them. Or write them a physical, hand-written letter.

Tell them you want them to introduce and/or support data privacy laws like the GDPR, and anti-monopoly laws like Digital Markets Act. Tell them you want them to be able to effectively go after companies that do shit like this.

Right now, in the US, we can’t do much about this. There’s a class-action lawsuit in California, but the rest of us are out of luck.

LinkedIn will not be the last company to try to pull this - heck, they probably aren’t the first. We need legislation with teeth to be able prosecute privacy violations like this. And we need those prosecutions to make it too costly for businesses to risk doing this sort of thing.

And to do that, we need to call our legislators.

Conclusion

Basically: This sucks green and purple donkey dick. I wish I had a better way to tie this together.

I found a a few folks who seemed to think the report is overblown - I didn’t find that particularly convincing, but I do think it was worth checking out, for a more balanced understanding of the situation.

In the end though, I still believe that LinkedIn’s data scraping, sans consent and sans notification, is an enormous violation of our right to privacy. At best, this is a sign that we should be breaking up LinkedIn’s monopoly.

I look forward to seeing the California class action lawsuit play out, and to seeing what the EU, UK and Germany have to say about this.

This morning¹, Sonarr and Radarr could not access our hard drives. The hard drives were still there, still running, and still available, but for some reason our Docker containers couldn’t access them.

Luckily, we think this won’t be too hard to fix.

The Background

For anyone new here², we’re running a NAS³ on Overkill - my old, off-brand laptop from 2017. It has an internal hard drive, but most of our storage is a set of external hard drives, configured for RAID⁴, connected via two USB HDD bays.

That USB data transfer is the weird part of our system. Most consumer hard drives connect via SATA - a data transfer standard - but Overkill doesn’t have any available SATA ports to connect to.

Overkill does have plenty of USB ports. So we bought a pair of USB two-bay hard-drive docks, and are using them. It does decrease the maximum read-write speed, and most folks online suggest against using RAID over USB for a variety of reasons, but this was a cheap, reasonable option, and Jude has the expertise to mitigate problems.

And problems we have found.

The Symptoms

We have a very limited list of symptoms.

1. This morning, Docker containers running on the internal hard drive (namely, the ones running Radarr and Sonarr) could not access the hard drives in our RAID array.
2. From the command line, Jude could verify that the hard drives were still present and reachable.
3. All drives in the RAID array passed their SMART testing (the internal monitoring system on the hard drives), indicating that the drives were undamaged.

The Theory

We think that a power fluctuation caused this problem.

Unfortunately, one of the reasons you shouldn’t use RAID over USB is because the USB docks are sensitive to power fluctuations. Power over USB isn’t enough for the docks to run the hard drives, and that often causes damage to the drives.

We had mitigated this problem by powering these docks with their own power cables, plugged into the power strip that we ran for Overkill.

But we did not include a UPS⁵ between the computer, the hard drives, and the wall.

Our theory is that last night, our house experienced a brownout, power dip, or other power flicker, which momentarily underpowered the dock, momentarily closing its data connection to Overkill.

Our house is in an area prone to power outages, and we get power dips and power flickers fairly regularly. Our UPS downstairs was giving some weird beeps yesterday evening. Even though we didn’t visibly see a brownout happen, we suspect that means there was a power fluctuation.

If Overkill lost connection to the RAID array, then the Docker containers running on Overkill’s local drive would have lost access to them too - and likely didn’t have a way to reconnect to them once they were available.

Luckiest Family in the Universe

If this is accurate, then we were very lucky - a serious power fluctuation on running drives can damage them badly, but ours are fine.

This means one of three things:

1. The power fluctuation was small enough that it affected the docks’ ability to connect to Overkill, but not the ability to run the hard drives.
2. The power fluctuation may have stopped the docks from running the hard drives, but it happened while there were no read or write commands, so the hard drives were not running and were not damaged by the sudden power loss.
3. Our theory is wrong.

We don’t have another theory, so we’re going to thank our lucky stars, acknowledge that we were very dumb for not putting this system on a UPS, and do some work to prevent relying on luck in the future.

The Plan

We have 3 parts to this plan.

Short Term - UPS

We’re going to put Overkill and the hard drive docks onto a UPS. We want them to have a nice, stable power source. If the power goes out, the UPS will yell, and we can safely shut down Overkill ourselves.

This will hopefully prevent data loss.

Medium Term - Backup Systems

We’re still working on a 3-2-1 backup system. That means 3 copies of the data, in 2 different formats, with 1 copy offsite.

There’s a reason Overkill’s drive is named fragile:\. We don’t have that set up yet.

We’ve purchased some 16 TB hard drives for a full backup system, and we’re working on a cloud solution as well. We’ll update when we have this finished.

This wil protect us when we do have data loss.

Long-Term - Monitoring

We already want to add monitoring to Overkill⁶. We’re expanding that plan to include UPS monitoring.

If the UPS activates, we want Overkill to immediately cancel any read/write commands to the external hard drives.

If the UPS gets below 50%, we want Overkill to safely shut down.

This may require a new UPS. We’re still looking into it. We’ll update as we have more info on this.

This would automate our protection.

Conclusion

Like I mentioned, the internet warns against using USB docks for RAID arrays of hard drives. We’re doing it with the full knowledge that it could all come crashing down.

But we do think we can make it work.

And if adding a UPS doesn’t prevent this issue, we’ll try something else.

A doddering old fool thinks he knows better than Debian distributors

Jude

We were really hoping we would get to set up our media server and NAS this week. That…did not happen.

But every DIY project has the occasional failure. We may as well share this one, so you don’t try to make the same mistakes as us.

The Goal

Convert an old laptop to a media server, as a start to replacing our Fire TV Stick.

Hardware

The hardware we’re using is an old laptop from Eluktronics, with the following specs:

• GPU: NVIDIA GeForce GTX 1060
• CPU: Intel Core i7-7700HQ Quad Core
• RAM: 32 GB DDR4
• Boot Drive: 1 TB M.2 SSD
• Secondary Hard Disk: 1 TB 2.5” SATA III

This laptop is from 2017. Its name is Overkill.

We also have QTY 4 of Western Digital’s 4TB Red NAS 3.5” HDDs. This is what we want to use as storage for our NAS long-term, but we don’t have a dock or enclosure for them, so for now, we have to make do with the two 1TB hard drives already housed in Overkill.

Considerations

We already know we want to use Jellyfin for our media server.

Reddit suggests one of three services/Operating Systems for NAS management for Jellyfin: UnRAID, TrueNAS, or OpenMediaVault.

Not using UnRAID or TrueNAS

UnRAID requires a one-time payment, which is better than a subscription, but still isn’t something we want to do.

As of February 5, TrueNAS has two software suites, one that’s free and Open Source, and one that’s a paid enterprise subscription. This would be okay, since the primary difference was premium support initially, but it appears that they’re starting to move previously free features and incoming updates behind a paywall. We at Unshittify aren’t a huge fan of segregated features in the first place, and we fear this is a sign of further enshittification to come. So we’re not going to suggest or try TrueNAS right now.

OpenMediaVault

That leaves OpenMediaVault.

It has a lot going for it. It’s an OS based on Debian with the GPLv3 License, so it’s FOSS with Copyleft protections. It comes with the easy configuration we need for the media management systems we want to make and use.

But OpenMediaVault (OMV) is also is very opinionated - if it detects that you’re using a Graphical User Interface (GUI) (as opposed to a command line interface (CLI)), it will refuse to install. If you somehow manage to install it, but you have a GUI,¹ it will then refuse to run.

This is annoying, but it has understandable reasons behind it.

• OMV should really run on a dedicated machine.
  • Requiring a CLI prevents users from running it on their general purpose machine, or their daily driver laptop or PC, since most of those are GUIs.
• Requiring a CLI is a big red flashing sign saying “If you are not comfortable using the command line, you are not ready to install this OS. You need to learn more before you try to do this.”
  • I know: This sounds kind of elitist. It sounds like gatekeeping. I promise, it’s not just an arbitrary blockade.
  • Maintaining a system that runs on OMV does require some amount of technical literacy. So you’ll either need to learn those skills to use OMV, or find another NAS/Media Server option that you already have skills for.
  • The CLI requirement doesn’t prevent people who are less experienced from figuring it out and running it. But will make someone who is really out of their depth pause for a second before they dive into the cold, black depths.
  • We want people to learn, that’s part of why we’re documenting our work. And hopefully these posts will help make this marginally more accessible to folks who otherwise wouldn’t have the skills to manage an OMV system.

As for us, we’re lucky. We have a dedicated machine, and Jude has extensive experience with Debian. Tatiana has significantly less experience with CLIs, but is capable.² But we had other circumstances that made OMV less attractive at the start of this process.

OMV Problems

We didn’t have all of our equipment ready - specifically, the fact that we were missing the Hard Drive bays for our WD Reds. If we tried to set up OMV as Overkill’s OS, it would only see the internal SSD (which is being used as a boot drive) and the internal HDD (which we are tentatively using as fragile storage).

But without the external hard drives, we don’t have enough drives to set up in a RAID array. And that means we’d be setting up OMV without RAID. That’s less than ideal, and we were worried that it would be tough to reconfigure it with RAID drives later.

We also kind of wanted a GUI. Tatiana is more comfortable with a GUI, and we suspect some of the readers would be more comfortable with a GUI.

And more importantly, having a GUI would allow us to do all the setup on Overkill. Yes, OMV is designed to install on a system that uses a CLI, not a GUI. But the services that OMV packages together have some configuration that is performed via webapp. So as designed, once we install and do initial setup on Overkill, we’d have to switch to another device, log into the web interface, and finish the configuration there. That’s annoying.

So instead of installing OMV, we decided to. . . install OMV. Kind of.

Most of what OMV does is install a list of packages. For the most part³, you can do that. It’s more tedious, but it gives you more control. And then we can use the webapps on Overkill.

So that’s what we did. And my god it was tedious.

Software

We installed the newest stable version of Debian⁴ (which has a GUI), then started setting up the tools that OMV would normally install.

This was a somewhat recursive process - identify a package we need, try to install. If it needs dependencies, try to install those. Repeat until it works, then move on to the next package.

The main ones we knew we needed had decent install instructions, and were:

• mdadm for RAID⁵ management
• SaMBa and NFS⁶ for NAS⁷ setup
• Jellyfin, for media management

The NAS Testing Plan

The plan was simple. We were going to use our Mac upstairs to rip episodes of the Angelic Layer anime from our DVDs, then upload it to the media drive on Overkill that we configured with SaMBa and NFS.⁶

That didn’t happen how we expected.

The First Hurdle - No Upload

First, Jellyfin doesn’t have an upload function. What?

Frustrating, but possible to overcome and troubleshoot later. For now, I’m sure we can just manually copy the files onto Overkill, right?

The Second Hurdle - No NAS

Apparently, we didn’t set up SaMBa right.

Theoretically speaking, SaMBa should’ve turned Overkill into a NAS, and should’ve made it so that the other computers in our house could access Overkill’s storage.

We wanted to mount Overkill’s drives as a virtual drive on our Mac (which was on the same wifi network). Then, on that second computer, we would just drag-and-drop copy our files over to Overkill’s storage.

Except, for some reason, the Mac couldn’t see Overkill’s drives. We tried to connect to Overkill, but it requested a login that we weren’t expecting, blocking our attempt to mount the drive.

Admittedly, this was probably entirely our fault - we think we didn’t configure SaMBa correctly.

We have not gathered the energy to try to fix this yet.

The Third Hurdle - Torrenting Stack Complications

So let’s back up. Adding new media should still be possible. Overkill just has to handle getting it.

We could manually rip disks, or we could use rips that someone else have made.⁸.

How hard can it be to make that happen?

Well, over the course of 3 hours, Jude was able to:

• Install qBittorrent to manage the torrent protocol for downloads
  • Easy! Success!
• Get Sonarr installed, to search for torrents of tv series
  • Hard. Boo.
  • This package was broken, and we had to install it from a script
• Spend 90 minutes fighting to install nzbget, to try to search through torrents on UseNet.
  • Awful. Boooooo. Ultimately unneccessary.
  • nzbget is not a good Debian citizen. Installing it was awful.
  • Good news! UseNet still exists!
  • Bad news! UseNet costs $100/year to use!
  • It’s installed, but we ain’t dealing with this.
• Install Prowlarr, to search through torrents
  • Very difficult. Still a success. Meh. Boo.
  • This did not have a script to download it, but theoretically it shouldn’t be too hard to install it manually.
  • It was incredibly hard to install it manually. Installation, setting up a configuration, building an init script - it all took time and effort.
  • It eventually worked.

With this stack - Sonarr, Prowlarr, and qBittorrent - we were successfully able to find Angelic Layer!

But before we download it, we want get this set up in a way that will be easy for our users to request media.

The Stumbling Block - Jellyseerr

Jellyseerr is a service that allows Jellyfin users to request media to be added to the Jellyfin server. The user can go to the webapp to search and request a show that they don’t want to bother ripping, then those services we picked above to manage torrents will find it, download it, and organize it into our Jellyfin server.

We picked qBittorrent, Sonarr, and Prowlarr because they integrate seamlessly with Jellyseerr.

Perfect.

Except, Jellyseerr is experimental. There isn’t a good way to install it on Debian.

Jellyseerr doesn’t have a Debian installer. It doesn’t have a community-made installation script.

There are exactly two ways to install Jellyseer (on Debian). And we don’t like either.

1. A Docker Container

Neither Jude nor Tatiana are particularly familiar with Docker. We don’t want to deal with that.

Besides, if we were going to install Jellyseer with Docker, we should’ve just installed the entire stack with Docker.⁹

2. Build it from source

Building Jellyseerr from source requires Node 22. Debian only supports up to Node 20.

We could still make it work - we could make our own build environment. But we’d want redundancy. And we’d want revision control.

We’d want all sorts of customization to our build and dev environment that would make this system robust, safe, and unique to our needs - all things that Jude has the knowledge to do because of his decades of work. But it would also make it difficult to explain, difficult to share, difficult to get help with, and difficult to keep up-to-date.

We wouldn’t even be able to get support from the Jellyseer community.

Building Jellyseer from source and maintaining it afterwards would be a project in and of itself. One that would take away from the rest of the media server project - which for us includes the documentation we make for this website (which, again, building from source would make significantly more complicated).

No.

No. We’re not doing this. It’s been 2 weeks since we started working on Overkill - admittedly in between family emergencies, but still. We’ve been running face first into wall after wall after wall, and after every broken nose, we’re making it harder for other people to help us the next time. We’re hitting the Sunk Cost Fallacy, and we’re not falling for it.

We could build Jellyfin from source to hit a Minimum Viable Product. It’s possible.

But there is no good way for us to teach that process here. Jude has seen first-hand that it takes about 3 months of consistent teaching for a student to become proficient in a build/development environment. We cannot expect to put out a “How to build Jellyseerr from Source” article that will let someone else naiively follow along, and expect to have a successful build at the end.

We can’t do y’all justice by doing something too hard for anyone else to duplicate. And we can’t do ourselves justice by making a system that is more hassle to maintain than benefit to use.

The Plan

We’re starting over.

We’re going to reimage Overkill, and install OpenMediaVault¹⁰. We’ll deal with using our Macs and other laptops for the Web UI configuration.

We’re gonna use the Docker Compose All-in-One to install Jellyfin, and it will include everything we spent 2 weeks setting up the first time around. We’ll have to learn more about Docker, but between Jude and Tatiana we have enough to get started, and Docker is already extremely well-documented, with lots of resources to help us learn.

We will use the systems that everyone has been saying we should use. We’ll follow the guides that already exist.

And we’ll be able to document what we’ve done, what went wrong, and what went well.

There are tools available to help us climb over the walls and sweep away the stumbling blocks. We’re dang well going to use them this time.