Disable fingerprinting via favicon

Will let @gp weigh in

Looking at this, a few angles for what Orion could do. I haven't checked if it does any of these:

1. Clear cache/cookies/history feature should also clear the favicon cache, as there's not really a compelling reason to make this persist long-term.
2. Private mode should not leverage/use/read from a favicon cache.
3. When containers/sessions are implemented, each container/session should have its own isolated favicon cache (along with all other caches). Clearing a container/session should erase the favicon cache.

I think these 3 things would effectively mitigate these issues, since

1. The root of this issue is persistence of state between sessions that are otherwise not "trackable".
2. There's no need to not cache favicons in normal mode - users can be tracked by cookies just fine.
3. This becomes an issue when you can get normal -> private persistence, or when the user thinks they have carried out an action that would clear cookies/identifiers, like closing a private window, or clearing a "container" or session, and this doesn't happen (i.e. favicon cache persists).

gp

Thank you!

Empty Cache already clears the favicon cache.

We can look into private mode requesting favicons on-demand.

joystmp

So something needs to be done about favicon of favorites and bookmarks in Orion, apart from what gp already mentioned.

What is your suggestion?

I'm unsure if that is a problem - it strikes me the specific risk about favourites/bookmarks can be addressed by locally storing a cached copy of each, at browser/profile level, but not making an entry in the cache table. That at least avoids a cached entry being created by Orion itself.

That way, browser behaviour when visiting a website will be identical whether the site is favourited or not.

If your concern is about the user's traffic being fingerprintable as a result of a series of sequential fetches of favicons from a wide range of servers, that would be a valid concern. However, your options are quite limited, and this gets more complex. You now have to start implementing a range of different and complex threat model scenarios - a "local attack" scenario won't want to leave favicon caches lying around on the device. A "network observer" scenario will want to minimise fingerprintable DNS/HTTPS requests being made at browser open.

One option could be to "passively" cache favicons.

If a site is saved as a bookmark, we can say the "local attack" scenario is rejected. If you are concerned about this, browse in private mode and don't use bookmarks, as someone can just look at your bookmarks.

If you save the site as a favourite, you could:

1. On bookmarking the site, fetch the current favicon (which is likely in the cache, since 95% of the time a newly added favourite will be currently open), and store it in a "favourite icon cache".
2. On subsequent visits to the site, update the "favourite icon cache" with the currently served favicon.
3. Important edge case is importing bookmarks from another browser - either you accept that is a fingerprintable operation, and deal with it... Or you have a runtime tickbox option to say "fetch favicons for sites on first visit", which avoids doing a mass request for favicons at import time. That wouldn't be a wise default, as users will get confused as to why some sites don't have favicons, and won't want to visit every one of their 2000 bookmarks one by one!

This feels like a separate suggestion though in itself (for quite a niche and extreme threat model scenario), and not really linked at all to the paper from above.

gp plus one for this solution, I was right about to submit a feature request for this "total fetch" of favicons every time cache is cleaned.
is there a dedicated thread I can upvote?

There is a marked issue with favicons.
For starters, it has to reload all favicons in existence every single time you login, even for websites that are visited not so often, which opens up a plethora of implications for privacy minded folks.
Also they are used maliciously to deliver vectors and malware and the like.
https://github.com/jonasstrehle/supercookie
See this for example, an open source program

Orion purports itself to be the privacy focused browser, so it must take the measures to mitigate even the most novel favicon silly techniques used, such as sandboxing and limiting favicon writing from websites.

The cache management seems to be an interesting feature
https://stackoverflow.com/questions/1831123/are-cross-domain-favicons-a-security-risk

gp Since this post is related to https://orionfeedback.org/d/9585-history-isnt-completed-gone-despite-asking-orion-not-to-have-it, we're implementing the first two of the suggestions to mitigate this issue now.
(For the third suggestion, Orion doesn't as of now have containers as suggested in https://orionfeedback.org/d/43-something-like-firefox-multi-account-containers-by-default/, but different profiles do have different favicon stores)