Especially with sync enabled we often do not have any icons for sites we show in the new AS panel. We should consider loading them from the network.

Bear in mind that we have avoided doing this (and favicon sync) in the past because it leaks user behavior to the network they're on, even to the point of being able to fingerprint individual users. iOS, however, does fetch for top sites… and even fetches the page to know which icon URLs to use. (I personally find that to be a bit over the top.) At the very least, make absolutely sure that no cookies are sent, and consider not fetching favicons over HTTP at all. You might also consider putting this behind a pref.

Comment on attachment 8834180 [details] Bug 1322564 - Permit loading icons from network for Activitystream https://reviewboard.mozilla.org/r/110212/#review111620 Yeah, this bug was more about starting a discussion and looking at the advantages/disadvantages. How about we move this to mobile-firefox-dev and see what others think. Your commit message looks like a good starting point for a mail. From my point of view there are two things I'd like to get more opinions about: * User: The browser making requests "to websites" and not initiated by the user * Site owners: The browser loads some assets without an user actually "visiting" the page Especially data consumption and privacy is something I'm worrying about. We will have the same discussion about images from websites that we want to use in the AS UI: We can't store all of them. But we might know the URL. Do we want to fetch them when needed? If I remember correctly the desktop add-on does the same like what Richard described iOS does and downloads what ever is needed to display it in the UI. The desktop team might worry less about data usage though.

Some rambling thoughts: *if* we had something along the lines of tippy-top-sites, then we'd run into this issue less often, so network loading becomes less relevant. (That also depends on whether synced sites are likely to be top-150 or not though.) Actually getting an equivalent is hard though: we already ship acceptable icons for the alexa top 5 (which we could also use to always override the site-supplied icon). tippy-top-sites is a 1MB large bundle of png's which we definitely don't want to ship (moreover they only provide one resolution). An SVG/VectorDrawable equivalent might be acceptable for including in the app, or we could maybe get an icon bundle via DLC. (I don't think we send cookies for our icon downloads, since we're using a raw HttpURLConnection - but I've not dug into it enough to be sure.)

Yeah, that's something I was considering too. It would be interesting to know the hit rate of tippy-top - maybe the desktop team has some numbers, I'll ask them on IRC. Regarding Android: Yep. The goal was to load an icon pack via DLC. :)

(In reply to Andrzej Hunt :ahunt from comment #4) > … or we could maybe get an icon bundle via DLC. Initial install download size is only one part of the pressure we're under. We also have to consider bytes-to-first-use (which includes DLC) and install footprint. Downloading content can't be an end-run around calculations of Fennec's size. Downloading content via DLC helps with lots of things (initial size, downloading only what's needed, OTA updates), but if all clients download the content and always keep it, you might as well ship it as part of the APK -- every client pays the price, so we might as well have Google host the content and delta it for us. Committing to storing a meg of PNGs… well, that's 20% of Opera Mini just in icons, isn't it?

*If* we can get svg/vectordrawables, we'd likely be closer to 1kb per image, i.e. 150kb for tippy-top-sites - which is better, but still seems wasteful (and creating svg versions would be a considerable amount of work). I still have doubts about the hit rate (I don't think I've visited more than 20% of the sites in tippy-top-sites, once you then take the subset that I've only visited on desktop but not on mobile, AND which were synced AND were selected for AS, there might be a handful of useful icons where tippy-top-sites would be useful to avoid network loading - then again I'm not sure how representative I am). Tippy-top-sites is also useful for just having better looking icons, but that doesn't necessarily have to be provided via DLC - fetching individual icons on demand is also possible (and in fact very easy in the current favicon downloading framework). I'm guessing there are privacy/history-leakage concerns if we were to host icons on mozilla servers though...

(In reply to Andrzej Hunt :ahunt from comment #7) > I'm guessing there are > privacy/history-leakage concerns if we were to host icons on mozilla servers > though... The opposite — we've actually considered doing hosting a favicon proxy in order to implement favicon sync, because a single stream of HTTPS icon requests to a Mozilla CDN, with icon paths hashed, is waaaay less identifying than fetching from the open internet, and we're pretty good at hosting services like this with minimal logging and anti-anonymization techniques -- consider all the pings users already send us from every place they go online, even including location uploads to MLS. (Not to mention this being way more efficient than opening half a dozen new TCP connections, all of which will time out on a satellite connection…)

All open Activity Stream bugs are moving from the whiteboard tag, "[mobileAS]", to the Firefox for Android component, "Activity Stream", so that I can keep better track of these bugs as the new triage owner; I will send out an email shortly with additional details, caveats, etc.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.