Allow whitelisted content origins to use page-icon protocol




8 months ago
2 months ago


(Reporter: ursula, Unassigned, NeedInfo)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fxsearch])



8 months ago
The page-icon protocol only works in a chrome privileged scope, would be nice to spec out the work needed to allow the page-icon protocol to be used in content space
Component: Bookmarks & History → Places
Depends on: 1283825
Product: Firefox → Toolkit

Comment 1

8 months ago
Yeah, here the questions are mostly about security. And I don't have answers, so we need someone from network and security to help us.

The protocol only hands-off image content types, and SVG documents. Currently those contents are local only (cached).
Priority: -- → P2


8 months ago
Whiteboard: [fxsearch]
(In reply to Marco Bonardo [::mak] from comment #1)
> Yeah, here the questions are mostly about security. And I don't have
> answers, so we need someone from network and security to help us.

Wennie, can someone on your team advise us here?
Flags: needinfo?(wleung)

Comment 3

5 months ago
Hi Jonathan:can you take a look at this? Thanks!
Flags: needinfo?(wleung) → needinfo?(jkt)
Wennie I actually don't think I am the right person to answer the security implications of exposing this protocol.

This is actually something we needed for containers in Bug 1315616 for extensions.

However we should restrict this protocol to web content being that it might expose the browsers history with the latency of cached icons. As it's not standards backed either it's another reason not to expose to the web.

Out of interest Ursula what use case do you envisage using this protocol for?

Dan is likely a better person to confirm the implications.
Flags: needinfo?(usarracini)
Flags: needinfo?(jkt)
Flags: needinfo?(dveditz)

Comment 5

5 months ago
potentially, we could just need to expose it to just a given whitelist of internal Firefox content pages.

Comment 6

5 months ago
This was filed so that Activity Stream could display icons while being unprivileged. Right now it uses data URIs to display favicons for things like top sites, but eventually we want to be able to use the page-icon protocol while also running in content.
Flags: needinfo?(usarracini)
Ah does it override about:newtab then.
We in containers basically guess at favicons for a similar use-case (although there is the annoyance of favicons from different containers too which I dunno how we should handle that). In our case we actually don't always have the favicon in the cache when the user loads the URL.

Comment 8

5 months ago
So Activity Stream doesn't actually "override" about:newtab, it just becomes the default about:newtab... aboutNewTabService.js finds outs if Activity Stream is enabled via a pref, and if so, lets about:newtab load Activity Stream's resource page instead of the other one. So it gets all the same behavior of the current about:newtab.
Blocks: 1315616
I spoke to Dan about this at the all hands and he seemed to think it was ok. If the icons were to be injected into web content we should check to see that a canvas element can't read in the URL so to prevent the page capturing history.

If the icons were just opened up to the new tab page we might be ok too. I don't think extensions have the ability to inject content scripts into the new tab page.

I still think it would be more useful to check the favicon store and if not present fetch the URL and get the icon this may actually reduce some of the privacy risk also.
Comment hidden (obsolete)

Comment 11

3 months ago
Duh, bug 1385864. Ignore above.
I'm adding a "whitelisted" to the title, since I don't think it should be exposed globally. In particular, just fetching the favicon for a page, it would be possible to extrapolate the user's history.
Summary: Allow content to use page-icon protocol → Allow whitelisted content origins to use page-icon protocol
You need to log in before you can comment on or make changes to this bug.