Both should if your goal is to not have a reusable fingerprint (which for a privacy focus would be). Server should change more frequently since it has access to less information about the browser. Server based fingerprinting is fairly unreliable, client side uses Javascript to generate more bits of unique data.

The bottom result (the % certain one) is just a fuzzy match of similar fingerprints AFAICT.

The test is simply showing two fingerprints for your browser. One, the server fingerprint, is one that any tracker can see. The other, the client fingerprint, is what can be used if you have Javascript enabled.

Instead of inundating you with test results, this one is simple - check to see if your fingerprints change between browsing sessions. If they don’t change, that means you can be tracked. In which case you can mess with settings and try again.

So server code is your fingerprint based on what a server is able to see. This would be your fingerprint with JS disabled, essential. Client code is the JS generated fingerprint.

For the emojis I have no idea.

One of the points of Libre Wolf is to make you unique, but each session should be unique.

You can find some additional setting tweaks here: https://librewolf.net/docs/settings/

The “letterboxing” feature is an additional uniqueness feature you could consider enabling.

I’m particular you could check your result in this experiment: https://fpresearch.httpjames.space/

Try it in both normal and in a private tab, then record those results, reopen Libre Wolf, and try again.

The ad serving companies (Google) don’t care about what happens after the click (yet). As far as I’m aware no “handshake” process exists that would allow an advertiser to communicate with the as server and validate a click (such a process could be abused).

Most likely the advertiser would be using some form of client side analytics, so the click wouldn’t show up in their statistics, meaning the advertiser would see a huge discrepancy between the clicks they saw in the campaign and the clicks the ad server reports.

That’s what I thought at first, but the person who wrote the article is named Simon, and based on the context given in the article I’m assuming that was a test unit he had on his desk, but the planned implementation is in bathrooms.

Considering it only detects if someone in the bathroom is vaping and not who, disciplinary action just isn’t really possible with your typical school restroom.

The article that user links is referring to GrapheneOS (and other OSS software) as not being “free software” - and they (GNU) delves into it more here.

Basically, GNU is saying software shouldn’t claim to be free and open source if they contain non free binaries / other non-free blobs.

The nuances between FOSS and OSS can be confusing. GrapheneOS is not claiming to be FOSS.

Or just skip it entirely, I use the Consent-O-Matic extension which has a surprising amount of features.

I’ve had to carrier unlock two devices from T-Mobile. You’ve already returned it, but if anyone else faces a similar situation: for whatever godforsaken reason, DMing them on Twitter is the way that has always worked for me. There is back and forth, but usually they set you right.

Just download it from a third party and compare the checksum with the official information. Granted, the official checksums on their website are behind a few steps, but you already tried on public Wi-Fi - once you generate the link a “Verify your Download” section should appear.

Brave has been off limits for me ever since I saw my QAnon nutjob father using it lol.

Usually they just check your IP against a list of known VPN IP ranges. But they could also be blocking all IPs from data centers and only allowing residential IPs.