Bookmarks, Toolbars (fingerprinting)

I saw Saving bookmarks, customize toolbar (locked topic).
And I remembered reading, that it was possible to fingerprint someone through the favicons of their bookmarks. I also remember, that for people with custom DPI, enabling toolbars would create fingerprintable screen dimensions not fixed by letterboxing.

Are these issues present in TorBrowser, or are they fixed?

If there are/were any other issues connected to bookmarks and toolbars. I think it would be great to collect them in one place (easier to find), so feel free to make a post about it.

1 Like

In the past I read somewhere on the web about several downsides to having favicons enabled. IIRC, there were a few security/privacy issues and last but not least, the bloating of the bookmarks.html file should you archive it and import it later. There is no good reason for favicons to be enabled, period.

I proposed they be disabled in Tor Browser, see here for the thread:

Bookmarks cannot be fingerprinted directly. But visited links, likely to often be from your bookmarks, and during your session as Tor Browser does not retain history, used to be an attack vector (and still is to a small degree)

First RFP (privacy.resistFingerprinting) has timing mitigations which severely hamper side-channels attacks to determine redraws, and even without RFP, Firefox upstream has made it really hard for websites to detect visited links: you can read more here - https://github.com/arkenfox/user.js/blob/662eddbc2124d9d09774da7d5bc385f45c287c0d/user.js#L378-L388


favicons themselves are meant to be isolated by first party (meaning each site would have to download it’s own copy) but this may be one of those things left to do/check (I know there were a couple of “minor” loose ends with FPI: first party isolation). However, RFP’s timing mitigations make this side-channel attack much harder.

You can read how this attack works here - https://github.com/jonasstrehle/supercookie - ignore the browser results. There is a bugzilla - https://bugzilla.mozilla.org/1691728.

But here’s the kicker: regardless of RFP timing mitigations, regardless of FPI/partitioning - there’s another bugzilla - 1618257 - Firefox fails to load favicon from HTTP cache : Firefox fails to load favicon from HTTP cache - which seems to suggest that Firefox, because of a bug, is immune.

tl;dr: favicons - don’t worry about it


As for theming and toolbars, the answer since TB11, is no. Previously issues like theme density could affect the inner window startup size, and without letterboxing, this would cause entropy (fingerprint wise you would stand out), but since the Proton redesign this no longer happens, and letterboxing also mitigates any new window sizes. And nothing can read your theme colors etc: e.g. custom, system, dark, light

What you’re talking about are the myriad things that can affect measurements: such as system scaling, layout.css.devPixelsPerPx, devicePixelRatio, DPI, and zooming. Zoom is reset to 100% per site and tab, and new windows seems to handle all the above just fine. A new window size is only checked once, on creation. But there is a bug where the new window doesn’t take the letterbox borders into account - you can read it here - Letterboxing since 32220 affected by layout.css.devPixelsPerPx (#40081) · Issues · The Tor Project / Applications / Tor Browser · GitLab (hey that’s me) - it eats 2 pixels width and 1 pixel height, and the letterboxing doesn’t re-trigger (it needs a resize event), so you end up at e.g. 998 width by 999 height

Hope all that answers your questions :footprints:

1 Like