search

mozilla-lockwise / lockwise-ios

Firefox's Lockwise app for iOS
https://mozilla-lockwise.github.io/lockwise-ios/
Mozilla Public License 2.0
244 stars 46 forks source link

Favicons for entries to improve human readability (entry list) #178

Open sandysage opened 6 years ago

sandysage commented 6 years ago

When I view the entry list in Lockbox, I want to be able to easily identify entries based on their associated favicon.

sandysage commented 6 years ago

Solutions may come from shared places database for bookmarks/history or activity stream (new tab) (Medium to Large, very dependent)

nickbrandt commented 6 years ago

@sandysage I know this story is a ways out for development, but in terms of design we will probably need some additional clarity around what limitations we have with this. It looks like things like bookmarks/history are using a website's favicon.ico file, which in many cases is only 16x16 pixels in dimension. If we need to plan for that being the least common denominator, then we will want to ensure the favicon usage in the app is at that size.

joeyg commented 5 years ago

@sashei @devinreams I'm interested in taking this on. It is pretty straightforward in Swift but I'm wondering if the preference would be for it to be part of application-services somehow. Thoughts?

sashei commented 5 years ago

hey @joeyg, what approach are you thinking about for getting the favicons (high level fine obviously :)? I think this is a part of application-services longer-term roadmap but if you're interested in doing something else in the meantime I'd be open to it! what do you think @linuxwolf ?

joeyg commented 5 years ago

@sashei I thought about creating a FavIconStore that listens for changes to the DataStore and then downloads and caches the assets. Not sure where to store info about no icon being available (to prevent re requesting the asset).

I found libraries in Swift and Rust so it could go in either place. https://github.com/leonbreedt/FavIcon/blob/master/README.md https://github.com/untitaker/rust-webicon

linuxwolf commented 5 years ago

Ideally, what we broadly do for iOS needs to be done for Android (and vice versa), in a roughly similar way.

Below are some important considerations for me. A quick glance at both proposed implementations shows me the following is almost entirely in how the libraries are used, and doesn't necessarily prevent/promote one or the other.

Privacy

Requesting favicons (and nothing else) carries some privacy concerns; we'd need to be sure users have appropriate controls to prevent requests to non-Mozilla sites without their consent. The consent is implied when a user opens a website by way of tapping "launch website"; grabbing favicons does not carry that same implicit consent.

Caching and Refreshing

However caching in employed, it ought to be wiped when the user resets or uninstalls (this is probably a given), so that we respect the user's device storage. Further, in respect to a user's device storage, is a worthwhile bound to the storage. It may be necessary to provide some provisions to clear the cache, maybe?

Once cached, some provision to refresh the cache is necessary, again that minimizing the privacy concerns mentioned above.