Bugzilla

(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 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?

(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?