Open Bug 1618257 Opened 4 years ago Updated 7 months ago

Firefox fails to load favicon from HTTP cache

Categories

(Core :: Networking: Cache, defect, P2)

73 Branch
defect

Tracking

()

People

(Reporter: solomops, Unassigned)

References

Details

(Whiteboard: [Bug prevents attack linked in comment 7][necko-triaged])

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.116 Safari/537.36

Steps to reproduce:

I have set up my test website using an nginx server via python flask interface.
I serve my favicon with the needed HTTP header parameters (immutable cache, expiration date in 6 months).

Actual results:

It creates a new entry on the favicon cache, but it never actually uses the favicon.
Everytime that i visit my website it issues a new request on the favicon.
I also manually checked that for a couple of other websites (linkedin.com is a typical example of immutable cache and expiration date) , and it had the same behavior.

Expected results:

In theory once the favicon is stored on the favicon cache, everytime the browser visits the website it will fetch the favicon from its cache and will not issue a new request.

Component: Untriaged → Networking: Cache
Product: Firefox → Core

Honza, do you know any reason why we are not using cache for favicon?

Flags: needinfo?(honzab.moz)
Priority: -- → P3
Whiteboard: [necko-triaged]

I need few answer first:

  • can you provide URL to your website so that I can reproduce the problem?
  • how exactly are you determining that there are multiple requests for favicon?
Flags: needinfo?(honzab.moz) → needinfo?(solomops)

Multiple requests means that even though I have visited before the website, the browser will still issue a request (one) on each visit, to fetch the favicon. This is not 'normal' since it has the favicon cache, and it can retrieve the favicon from that.Right?
My site will be online again soon, you can check for example linkedin.com.
What we expect :

  1. visit linkedin.
  2. fetch fevicon and store it on the favicon cache.
  3. close everything.
    4)re-visit linkedin.
  4. check if there is an HTTP request for favicon.ico (or whatever the name is).
  5. it should not issue a request since it is already stored on the cache.

Thanks :)

Flags: needinfo?(solomops)
Flags: needinfo?(honzab.moz)

Confirmed on linkedid.com with their favicon request. On second run I can see two requests: first is bypassing reading cache (need to find out why there is a bypass set), second is using the cached content from the first run. This was on Windows.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(honzab.moz)
Priority: P3 → P2
Summary: Firefox fails to use the favicon cache. → Firefox fails to load favicon from HTTP cache

The load comes from FaviconLoader.jsm:165:19. The channel has VALIDATE_NEVER | LOAD_FROM_CACHE set, though. Someone have to look deeper at this.

Any progress on that? Is it still open?

This bug right now hinders and ruins favicon based fingerprinting and tracking as can be found in
https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf
Solving this bug needs to take into account that fingerprinting vector and make sure that Firefox remains immune against that attack vector.

(In reply to Selek Respa from comment #7)

This bug right now hinders and ruins favicon based fingerprinting and tracking as can be found in
https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf
Solving this bug needs to take into account that fingerprinting vector and make sure that Firefox remains immune against that attack vector.
Totally agree.

I also think that it would have been appropriate to notify about the ulterior motive behind this defect report at the latest when the paper got published. This underhanded approach of reporting a defect just leaves a bad taste, really.

The behavior may be an actual defect in the classical sense, but I'm just wondering what would have happened, had this been addressed "in time" by the developers. It would seem that the researchers would then have triumphantly proclaimed that all major browsers are prone to their newly found attack. Must be somewhat disappointing that it didn't get fixed "in time" to make it into the paper that way.

:mayhemer my understanding this was intentional to prevent what is in the paper; however probably never documented and the flags don't match reality.

Perhaps it's special casing applied to "TYPE_INTERNAL_IMAGE_FAVICON" or it's this code: https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/toolkit/components/places/FaviconHelpers.cpp#570-574 which probably explains the two loads with differing caching also.

To provide additional details and context about our disclosure process: Our bug report was submitted to Firefox in February 2020 while we were still trying to understand how different browsers fetch/process/store favicons. Once we had devised the technique detailed in the paper and run experiments to see which browsers were susceptible, we informed all vulnerable browsers (June 2020). Our disclosure process took place before we submitted our paper and many months before publicizing our findings (February 2021), to allow browsers ample time to address this issue and prevent any users from actually being tracked in practice. Not notifying Firefox at that time was our oversight because we were focused on notifying the vulnerable browsers. In hindsight, we agree that we should have proactively notified Firefox. We hope that the continued conversations we had with other vendors to get the bug fixed shows that we had the best interests of web users at heart, and that neglecting to circle back with Mozilla once we found the security bug was an oversight rather than due to malice on our part.

@polakis
The fact that you still call it a "security bug", when it actually protects people from your very nefarious new fingerprinting method shows me that this part of your post cannot be true:

we had the best interests of web users at heart

By making them more trackable? As Jonathan Kingston already said "this was intentional to prevent what is in the paper".
So you making an account here pretending you (polakis) and Kostas Solomos were doing us a favour, is trying to take us for a fool.

There is no sugar coating for what you tried and it would have been best this bug is immediately:
CLOSED / WONTFIX

Since a Mozilla representative already said this is a security feature and "intentional to prevent what is in the paper".

(In reply to DiegosGonzales from comment #11)

Since a Mozilla representative already said this is a security feature and "intentional to prevent what is in the paper".

:jkt isn't a "Mozilla representative". He used to work here and still contributes, but he also didn't say it definitely was - he thought the behaviour was intentional, but already noted it is undocumented. There's no denying it's confusing either way, ie why are favicon requests not using the http cache like other requests. In particular, the load flags at https://searchfox.org/mozilla-central/rev/4dac9993b609fccc87e82682614faf2a44cda306/browser/modules/FaviconLoader.jsm#147-150 would suggest that we should be using the cache without validation.

To the best of my knowledge, our "favicon cache" is not implemented via the http cache. We have a separate cache for favicons that is used for e.g. bookmarks/history, because we don't want to make a bunch of network requests when you open the browser or search through history / bookmarks. Otherwise, http(s) requests for favicons are cached using whatever logic / behaviour our networking layer specifies. I don't know whether this is different to other browsers, and I'm not sure if there's any special sauce we use wrt http caching for loads of content type TYPE_INTERNAL_IMAGE_FAVICON.

So there's still some work to be done in this bug - at a minimum, we should understand what behaviour is intentional here and what isn't, and whether there is a way of improving caching without creating a privacy leak. Tim, I see you wrote patches that touched some of this logic in bug 1277803. Our chrome favicon loading has changed since then (notably in bug 1453751). Dave, you touched the JS / frontend side of the loads again in bug 1503696 which seems very related (and e.g. https://github.com/whatwg/html/issues/4176#issuecomment-438729175 suggests that we thought, at least at the time, that we did load favicons from cache, "even" without revalidating them). There's also still an open spec issue at https://github.com/whatwg/html/issues/4176 . Are either of you able to investigate further here?

Flags: needinfo?(tihuang)
Flags: needinfo?(dtownsend)

The html spec says that we should cache them (in that no particular caching behaviour is called out for icons and caching is the default). We go a little further in that we in most cases disable revalidation because at one point we used to load favicons in the bookmarks menu from xul:image elements directly loading the url which meant anytime you opened a bookmark menu we would re-request the favicon causing a privacy leak. Forcing a load from cache largely resolved that. The favicon cache (which is different from the network cache) was implemented in part to help resolve this. It is used to get favicons for display in the UI without touching the network however to my recollection the icon on the tab itself was still loaded using a normal network request using the network cache.

Bug 1453751 completely changed how we find and load favicons and when written I didn't notice this special validation behaviour causing us to start validating again which ended up breaking at least one website in bug 1503696. IMO the website is at fault there but given the number of regressions we were seeing from bug 1453751 it seemed simplest to just revert to the previous behaviour in case more sites were affected.

So, I believe that we should still be caching favicons and I'm not aware of any special casing for fingerprinting. It is possible something changed since I worked on this but I'm not seeing anything in a quick skim of the code. I also can't reproduce this. I have a personal website that marks its favicon as immutable and it is loaded from the cache as expected. Honza mentioned seeing this on linkedid.com but I couldn't see the issue there either. Do we have a reliable way to reproduce this?

Note that the code at https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/toolkit/components/places/FaviconHelpers.cpp#570-574 is mostly a red herring. It is part of the favicon cache and isn't used when normally browsing websites.

Flags: needinfo?(dtownsend)

Afaict, the TYPE_INTERNAL_IMAGE_FAVICON added in Bug 1277803 doesn't change the caching flag for the channel used to load the favicon through the imgLoader. It only provides a hint for imgLoader to use the correct OriginAttributes for the channel. I think it won't change the behavior of the cache for Favicon and has nothing to do with the fingerprinting issue.

And I cannot reproduce this issue through linkedin.com, the Favicon was correctly cached and used when reloading or loading other pages on LinkedIn.

Flags: needinfo?(tihuang)
See Also: → 1691728

(In reply to Selek Respa from comment #7)

This bug right now hinders and ruins favicon based fingerprinting and tracking as can be found in
https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf
Solving this bug needs to take into account that fingerprinting vector and make sure that Firefox remains immune against that attack vector.

For sure an interesting read. It's also left me with a minor headache trying to understand it.

I guess I vote for this so called bug should not be fixed.

Is there a layperson's explanation how retrieving the favicon.ico file on every page fetch prevents a user from being tracked? I would think that once a facicon.ico has been cached then there is no need for the browser to keep on requesting the icon thus not leaving a foot-print on every page fetch.

(In reply to Myron from comment #15)

Is there a layperson's explanation how retrieving the favicon.ico file on every page fetch prevents a user from being tracked? I would think that once a facicon.ico has been cached then there is no need for the browser to keep on requesting the icon thus not leaving a foot-print on every page fetch.

I don't think it has anything to do with footprint/fingerprint. The theory is that the tracking method is done by placing "a unique combination of entries in the favicon cache". See https://arstechnica.com/information-technology/2021/02/new-browser-tracking-hack-works-even-when-you-flush-caches-or-go-incognito.

Whiteboard: [necko-triaged] → [Bug prevents attack linked in comment 7][necko-triaged]
Assignee: nobody → mbucher
Status: NEW → ASSIGNED

When browser.chrome.site_icons is disabled nothing happens

Oops, sorry. Wrong information.

Severity: normal → S3
Assignee: manuel → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.