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:
- 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".
- On subsequent visits to the site, update the "favourite icon cache" with the currently served favicon.
- 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.