The answer would seem to be an option to not load favicons in the first place, and another option to flush them at will. Any comments?German software designer Jonas Strehle has published a proof of concept on GitHub that he says demonstrates a method in which the favicon’s cache can be used to store a unique identifier for a user that is readable "in the browser’s incognito mode and is not cleared by flushing the cache, closing the browser or restarting the system, using a VPN or installing AdBlockers."
Any way to disable "favicons"/"supercookies"?
Forum rules
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
-
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Any way to disable "favicons"/"supercookies"?
This appears to apply to all OS's, so I'm posting here. According to https://gizmodo.com/favicons-could-be-t ... 1846229089 "Favicons Could Be the Supercookie That Tracks You Everywhere".
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
Re: Any way to disable "favicons"/"supercookies"?
Oops. I also posted about this haha
Systemd Free - MX Linux, Antix Linux & Artix Linux
Re: Any way to disable "favicons"/"supercookies"?
browser.chrome.site_icons set to false
Re: Any way to disable "favicons"/"supercookies"?
You know, this just isn't true, and unreliable even if it worked.So when the browser requests a web page, if the favicon is not in the local F-cache, another request for the favicon is made. If the icon already exists in the F-Cache, no further request is sent.
By combining the state of delivered and not delivered favicons for specific URL paths for a browser, a unique pattern (identification number) can be assigned to the client.
When the website is reloaded, the web server can reconstruct the identification number with the network requests sent by the client for the missing favicons and thus identify the browser.
Think about this: By measuring requests for favicons you will cause the browser to request these icons. So the page reload will show an "all visited" status because favicons have been requested and stored in the browsing cache.
So this works ONLY ONCE, and then you'd be in a status of "all visited". So reconstructing the identifier on a new visit/a visit elsewhere based on "what has been visited of the sites tested" will not work, and as such you can't correlate one visit to another or track anyone on the web.
In addition, the tracker attempting this would be relying on volatile cache entries that can be purged at any time from one site to the next.
So, before you cripple your browsing experience by switching off favicons, use your brain.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
Paper is now out: https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf
The attack works. The injected fingerprint can persist for more than one session: server detects first page load - with generic favicon - as requesting apge contents but not the favicon, and for that session, will return all subsequent favicon requests as a 404. From there, you bombard the browser with subdomain redirects, each requesting a different 'fingerprint' favicon, and see which result in the browser requesting a favicon and which do not. The 404s mean the browser does not modify the favicon cache fingerprint (no new entries, no removed entries). However, even if the fingerprint only persisted for one session that is sufficient to bypass 'incognito mode' and match a previous session with the new one (and allow egregious behaviour like inflating flight and hotel booking prices for destinations you've previously browsed, something that switching to incognito mode is usually proof against without need to go full Tor + Tails).
Mainline Firefox has a bug that is also a solution to the attack: it caches the favicon, but regardless of a cache entry it requests a favicon every time anyway! Problem solved, data leak eliminated without losing the pretty little pictures, at the cost of an unnoticeable increase in bandwidth usage. More elegant solutions are possible to save a few bits, but seem frankly unnecessary.
In addition flushing the favicon cache can be added to the clear-cookies-and-so-on sequence, as could having Incognito mode ignore any existing favicon cache entries, but if the former mitigation is in place those become more belt-and-braces options than necessities.
The attack works. The injected fingerprint can persist for more than one session: server detects first page load - with generic favicon - as requesting apge contents but not the favicon, and for that session, will return all subsequent favicon requests as a 404. From there, you bombard the browser with subdomain redirects, each requesting a different 'fingerprint' favicon, and see which result in the browser requesting a favicon and which do not. The 404s mean the browser does not modify the favicon cache fingerprint (no new entries, no removed entries). However, even if the fingerprint only persisted for one session that is sufficient to bypass 'incognito mode' and match a previous session with the new one (and allow egregious behaviour like inflating flight and hotel booking prices for destinations you've previously browsed, something that switching to incognito mode is usually proof against without need to go full Tor + Tails).
Mainline Firefox has a bug that is also a solution to the attack: it caches the favicon, but regardless of a cache entry it requests a favicon every time anyway! Problem solved, data leak eliminated without losing the pretty little pictures, at the cost of an unnoticeable increase in bandwidth usage. More elegant solutions are possible to save a few bits, but seem frankly unnecessary.
In addition flushing the favicon cache can be added to the clear-cookies-and-so-on sequence, as could having Incognito mode ignore any existing favicon cache entries, but if the former mitigation is in place those become more belt-and-braces options than necessities.
Re: Any way to disable "favicons"/"supercookies"?
Not sure why you're posting this here. Your post obviously talks about Chrome (we don't have "incognito mode", for example) did you just copypasta?
Also you're clearly ignoring what I wrote above.
Also you're clearly ignoring what I wrote above.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
'Private' mode, 'InPrivate' mode, 'Incognito' mode, whatever you want to call the particular flavour of "window opens without access to previous session data" mode. What you want to brand it is not particularly relevant to its functioning.
As are you. I explained directly - as well as linking the paper that details it further - why the attack does indeed work, and why your claim:Also you're clearly ignoring what I wrote above.
Is incorrect. The attack does not work that way.By measuring requests for favicons you will cause the browser to request these icons. So the page reload will show an "all visited" status because favicons have been requested and stored in the browsing cache.
It's all detailed in the linked paper if you do not wish to read my post. Or you can skip that too, and look through the code of an independently implemented proof-of-concept. Or you can also try that PoC here. I tested with Palemoon, and it successfully wrote and read a persistent ID. While that PoC brute-forces the reading and writing of the Id with very obvious redirects, it could in theory be implemented by serving unique URLs to the user and allow them to unknowingly navigate themselves down the selection tree during normal browsing.
Re: Any way to disable "favicons"/"supercookies"?
All nice and good if you have full control over the specific server requests for favicons, but my point is that for the normal web you don't, not for a sampling of existing websites. This means that "writing" to the favicon cache would never be under your control.
Unless I completely miss the premise behind this kind of "supercookie" to fingerprint users based on websites they have visited, and it is actually something something that requires a user to visit a tracking server first to set this up THEN have that server's code be deployed on countless other sites also visited by the user to "follow them around"; which is, frankly, very unlikely.
Unless I completely miss the premise behind this kind of "supercookie" to fingerprint users based on websites they have visited, and it is actually something something that requires a user to visit a tracking server first to set this up THEN have that server's code be deployed on countless other sites also visited by the user to "follow them around"; which is, frankly, very unlikely.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
If people are so concerned about favicons being some sort of issue.. Why not just flip browser.chrome.favicons and browser.chrome.site_icons then grab your collection of foil hats (which actually conduct signals not block them) and move on believing whatever nonsense gets media attention.
Re: Any way to disable "favicons"/"supercookies"?
As far as I can tell the demo fails to persistently fingerprint Pale Moon, anyway.
- Ran the demo, got E2 95 14 21 C9 95
- Went to permissions, demo.supercookie.me
- Clicked "forget about this site"
- Ran the demo, got 62 70 01 A3 87 90
- Opened a private browsing window
- Ran the demo, got 78 A7 58 B3 B0 40
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
"One hosts to look them up, one DNS to find them and in the darkness BIND them."
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Re: Any way to disable "favicons"/"supercookies"?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
The goal is to add a fingerprint using a website you control (e.g. UnscrupulousAirLineTicketSeller.com), and be able to subsequently read that fingerprint back either by:Moonchild wrote: ↑2021-02-25, 22:35All nice and good if you have full control over the specific server requests for favicons, but my point is that for the normal web you don't, not for a sampling of existing websites. This means that "writing" to the favicon cache would never be under your control.
Unless I completely miss the premise behind this kind of "supercookie" to fingerprint users based on websites they have visited
- The same website you control (confirming the same user has visited your site regardless of whether they are using Pirvate/Incognito/etc or have cleared browsing data
- A different website you control
- A third party website that is using the same favicon fingerprinting service
'Visibility of rapid fire redirects' is purely a red herring: If instead of rapid forced redirects normal page-to-page user triggered browsing is used, the same fingerprint reading and writing can still occur.
If Palemoon is already resistant, great. Best to make sure it stays that way by design rather than by accident (as mainline Firefox was).
Re: Any way to disable "favicons"/"supercookies"?
So the goal is to identify a user on websites directly controlled by the malicious actor -- that's not tracking, and doesn't need to use something as elaborate as this (if you control the websites it's as simple as using e.g. an invisible pixel strategy to trackrecognise a returning user, or even something server-side only that is completely transparent)
As already pointed out there are much more reliable ways to identify and track users on the public web, and if you're really that concerned that this will be used in practice, then you have to only flip a preference to disable favicons altogether. I don't see any point in further discussing this.
That's not very realistic of a tactic either. Your granularity will then be variable (=unreliable) and directly dependent on the bounce rate for the site. When was the last time you browsed 16 pages in a row on a new website you're visiting?
As already pointed out there are much more reliable ways to identify and track users on the public web, and if you're really that concerned that this will be used in practice, then you have to only flip a preference to disable favicons altogether. I don't see any point in further discussing this.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Any way to disable "favicons"/"supercookies"?
Correct, it's fingerprinting. The goal is to be able to re-identify the same browser even if the user has already taken the obvious steps to avoid other fingerprinting techniques (e.g. clearing cookies, clearing image cache, using private/incognito/etc mode, running noscript or similar, switching IP, etc).
The reason for bringing it up is that it is easily mitigated without the blunt-instrument method of entirely disabling favicons - which would be a non-unique but highly uncommon fingerprint in and of itself - by the minor bandwidth hit of re-requesting images that are already in the favicon cache (and with the minor side benefit of updating changed favicons more rapidly), and that that mitigation mechanism is now being implemented by other browsers in advance of live instances of the attack.
Re: Any way to disable "favicons"/"supercookies"?
The favicon cache serves two (or possibly three) purposes:
1) To save bandwidth. A 32x32 image per page is not a significant bandwidth hit in the internet of today, so this is mostly moot.
2) To save time. It means a page will 'load' the cached favicon before the server has even received the request to deliver the favicon.
Possible 3) If the server has an issue delivering the favicon, then the cache acts as a fallback to display an older favicon rather than displaying nothing. The downside is it can also mean displaying an out of date favicon if the cache does not re-request the favicon on every load, depending on how long before the cache considers the favicon stale.
2 and 3 can still be accomplished by using a favicon cache to display favicons to the user, even if you 'waste' a few kilobytes on re-requesting a favicon (and that 'waste' request eliminates the downside of 3). The favicon cache could probably be eliminated with only minimal impact to perceived performance, but removing favicons entirely is not a great solution: humans are far better at pattern matching a small image than they are at recognising a line of text, so visual search tasks (e.g. finding a particular bookmark in the bookmarks bar) are far faster with favicons than without.
Re: Any way to disable "favicons"/"supercookies"?
A simple "yes" was enough, thanks.