Live data from Hacker News

Firefox 85 cracks down on supercookies

blog.mozilla.org

561–570 of 786 posts

Re: Firefox 85 cracks down on supercookies

#561
post #161
post #83

Earlier quoted context omitted.

I run a network ad-block dns (pihole) and consistently 25-33% of all my network traffic is blocked as ads. It's much more than I ever imagined. Now I'm used to a different internet, when I'm using internet off the network it's like WTF is this?

I run Pi-Hole on my network as well; it's wonderful. I'm terrified that it will stop working soon though, as companies start to use their own DNS servers, which I've heard is happening.

I'm not sure I understand how this is related to pi-hole.

Your computer sends the raw domain name to pi-hole (e.g. ads.google.com), and pi-hole returns 0.0.0.0 if it's on the block list.

There's nothing Google or anyone can do to make pi-hole stop working.

Re: Firefox 85 cracks down on supercookies

#562
post #68

Per-site caching negates the principal selling point of centrally-hosted JS and resources, including fonts. The convenience remains, but all speed-related perks (due to the resources being reused from earlier visits to unrelated sites) are no more... which is actually great, because it reduces the value that unscrupulous free CDN providers can derive from their "properties". It also means that I can remove fonts.goog…

This sounds overdramatised: caching once for a website you frequent still works just fine, with all the speed benefits on subsequent loads. You're definitely not going to be noticing that the browser now has to build a few more caches than "just the one".

Re: Firefox 85 cracks down on supercookies

#563
post #83

Earlier quoted context omitted.

I run a network ad-block dns (pihole) and consistently 25-33% of all my network traffic is blocked as ads. It's much more than I ever imagined. Now I'm used to a different internet, when I'm using internet off the network it's like WTF is this?

Would you mind sharing the blocklists you use? I have gotten to a ratio like that, but I have noticed that it was causing more issues with regular websites for my guests, so I removed many of the custom ones. I'd like to try some others if you have suggestions.

  [i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  [] Status: Retrieval successful
  [i] Received 59896 domains

  [i] Target: https://mirror1.malwaredomains.com/files/justdomains
  [] Status: Not found
  [] List download failed: using previously cached list
  [i] Received 26854 domains

  [i] Target: https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
  [] Status: No changes detected
  [i] Received 34 domains

  [i] Target: https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
  [] Status: No changes detected
  [i] Received 2701 domains

  [i] Target: https://dbl.oisd.nl/
  [] Status: Retrieval successful
  [i] Received 1167690 domains

  [i] Target: https://phishing.army/download/phishing_army_blocklist_extended.txt
  [] Status: Retrieval successful
  [i] Received 21379 domains

  [i] Target: https://raw.githubusercontent.com/deathbybandaid/piholeparser/master/Subscribable-Lists/ParsedBlacklists/AakList.txt
  [] Status: Retrieval successful
  [i] Received 5 domains

  [i] Target: https://raw.githubusercontent.com/deathbybandaid/piholeparser/master/Subscribable-Lists/ParsedBlacklists/Prebake-Obtrusive.txt
  [] Status: Retrieval successful
  [i] Received 3 domains

  [i] Target: https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-blocklist.txt
  [] Status: Retrieval successful
  [i] Received 14724 domains

  [i] Target: https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-malware.txt
  [] Status: Retrieval successful
  [i] Received 412 domains

  [i] Target: https://raw.githubusercontent.com/hectorm/hmirror/master/data/adaway.org/list.txt
  [] Status: Retrieval successful
  [i] Received 9182 domains

  [i] Target: https://raw.githubusercontent.com/hectorm/hmirror/master/data/disconnect.me-ad/list.txt
  [] Status: Retrieval successful
  [i] Received 2701 domains

  [i] Target: https://raw.githubusercontent.com/notracking/hosts-blocklists/master/hostnames.txt
  [] Status: Retrieval successful
  [i] Received 209608 domains

Re: Firefox 85 cracks down on supercookies

#564
post #174
post #142

Earlier quoted context omitted.

In Javascript how are they able to retrieve something from the cache? Local, session, and cookies are domain locked.

They load the image URL and observe the loading time. If it's fetched quickly, they know it was from cache. The server (controlled by the advertisers) can intentionally add delay to those image requests that makes detection reliable.

I don't see how that helps you persist a tracking ID.

If you generate a random URL, you'll always get a cache miss.

If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was.

The only thing I can imagine is the server serve several images /byte1.png /byte2.png etc. and make them all X by 1 pixels, encoding a random value in the dimensions, assuming that's available to Javascript.

But if you encode the tracking ID in the image somehow, you don't care much whether it was cached or not, it's inherently persistent. It'd mainly be useful if you're trying to reconstruct a super cookie.

Re: Firefox 85 cracks down on supercookies

#565

Earlier quoted context omitted.

That idea of having JS files hosted elsewhere always struck me as a Girardian scam (e.g. "everybody else does it") and always getting voted down when I showed people the reality factor. Nobody seemed to think it was hard to host a file before this came along, just as nobody thought it was hard to have a blog before Medium. Of course this creates the apocalyptic possibility that one of these servers could get hacked (…

This. If you are loading some scripts that are actually required for your app or page to work right, why would you get them from someone else's infrastructure? Terminal laziness? Or is the assumption that XYZ corp has more incentive than you do to keep your page working? This never made much sense to me except for developer toys & tutorials.

It makes sense from a $$ and resource usage stand point. I have to assume the best here and believe that the people arguing on there being no merit to CDN hosting of shared libraries all forgetting the two most important things a business must consider.

Every byte sent will cost the business. If you can save that 2MB per user per cache life, you pay that much less on the internet bill for your hosting.

Every byte sent uses up some of your limited bandwidth while it is being sent. If your site is 10KB and you rely on 2MB of javascript libraries and fonts, offloading that 2MB is quite a significant reduction is resource usage.

These above two views seem vastly more important than terminal laziness, up-time management, etc.

Re: Firefox 85 cracks down on supercookies

#566
post #422
post #18

"In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image." Clever. And so frustrating that optimisations need to be turned off due to bad actors.

Note that the root of all evil here is Javascript being opt-out instead of opt-in (and effectively mandatory for a big chunk of the internet these days). Letting any website and their friends (and the friends of their friends) run turing complete code on the client PC probably sounded reasonable when the web was created but it seems incredibly naive in hindsight. It's not as bad as ActiveX and other plugins, but it's…

Couldn't this particular trick be done purely server-side?

Re: Firefox 85 cracks down on supercookies

#567

Use uBlock Origin, Multi Account Containers, Privacy Badger, Decentraleyes and CookieAutoDelete with Firefox. Make sure you aggressively clear cache, cookies, etc., periodically (with CookieAutoDelete). You’ll probably load the web servers more and also add more traffic on your network, but it will help protect your privacy since most websites don’t care about that. When websites are user hostile, you have to take pr…

Unless you’re clearing cache, local storage, and HSTS, They can still track you. We haven’t got to the other things that can keep state that don’t reside in the browser. Not to mention fingerprinting the device itself, I’ve seen fingerprinting minute differences in CPU since they aren’t all identical.

Re: Firefox 85 cracks down on supercookies

#568

Earlier quoted context omitted.

Especially anyone who works in law, government, banking, or healthcare.

I love that some of the most-sensitive information users are the ones hanging on to a completely-unsecured transmission method. Sure, tell me again about all those HIPAA and SOX requirements when we still have fax machines.

You have to keep in mind the time when these requirements to "use fax" for security came about.

There was a single telephone company (or it was shortly after there were plural "baby-bells") and the telephone network was a completely private, isolated, network that only the phone company (or baby-bells) even had access to. It was also a network that was heavily regulated such that the possibility of a random attacker from half a world away being able to tap into a phone call as it happened simply did not exist.

In that environment, placing a phone call was considered "secure" (or at least as secure as network isolation and regulation could cause it to become [I'm ignoring NSA style 'state secret' taps, those have likely always been available to NSA style agencies]). So it would have been seen, at that time, as reasonable to use fax machines for document exchange, because the "phone network" was considered to be secure against having a man-in-the-middle tapping off one's communications.

Wind the clock forward thirty years, and have the once isolated and highly regulated telephone network more or less become just another packet protocol on the general Internet, and the choice of using "fax" for secure document exchange sounds ludicrous.

The issue is that the regulations those environments operate under have not been updated in the ensuing thirty years to account for the fact that "phone network" is no longer the once isolated, mostly secure, network it once was. And if the regulations don't get updated, no lowly clerk at the front lines is going to lose their job by _not_ using the comm. system called for by the regulations.

Re: Firefox 85 cracks down on supercookies

#569

Earlier quoted context omitted.

How do you suggest implementing "sign in" without setting a cookie?

Sign-in cookies are always first party. That's completely out of context here where we're taking about tracking cookies.

I’m not familiar with a distinct “sign in cookie” either. Do you mean a server side cookie / HttpOnly?

Re: Firefox 85 cracks down on supercookies

#570

I have an android phone, using Brave on a Samsung flagship from 2 years ago. The test at amiunique.org tells me my User Agent string is unique. So, can we now fix the User Agent strings, please?

There's nothing to fix. The user agent string is a hot mess, but is only useful for server-side profiling, not client-side profiling. Client side, there are a million better ways to profile you, with the user agent string barely adding anything if worked in.
Post reply on HN