buttercup-desktop
buttercup-desktop copied to clipboard
buttercup
[ Feature Request ] Custom icon
Hello ! Great Project, but I would to see custom icon (for folder AND password without putting an url)...
Do you plan to do something like that ? Keeweb is clearer for example...
I'm ok to help you do that if you point me the best direction :)
Yep! I think that's something we'd want. We don't have bandwidth for it right now, but I'll accept this issue and we'll add it to the roadmap at some stage.
This would be quite a huge undertaking, even when it doesn't seem so. I'll try to briefly explain why. There are a couple of ways we could allow icons to be set:
- Storing image data in the vault alongside the entry
- Storing a URL to the image
The first way is much harder as we don't yet know exactly how we want to store this data. Storing binary data in our text based vault files is not ideal. We're currently not accepting work along this path just yet.
The second way is easier, but perhaps less pretty. You can see here in the browser extension that we have a way of fetching different types of icons. You could use the ICON type to request an icon URL, and by setting a property called maybe "icon url" in an entry you'd be able to test for a custom icon.
Thanks for your fast answer, I will try to give a shot. We can also use https://feathericons.com/ ? A menu to select icon from this website and store the url...
We don't want to mix rich icons (download from websites / favicons) with generic icon packs. Buttercup should support rich icons only - actual images like the following:
So whatever solution we add here should still result in images being chosen instead of the automatic favicons. That unfortunately means that it's a bit more difficult to achieve.
@DrGeek we do have our own set of icons ready to use, however the issue is not which icons to use, it's just that we need to think about how to do this in a way that is intuitive and easy to use.
We'll be sticking with detected icons, for now. Although this is a very small pool right now, in terms of available icons, in the very near future it'll be expanded to support all sites (though in a secure manner).
Which would be great if it would work. 90 percent of the time it doesn't and Icons do net get downloaded at all.
URLs like those are all displayin an icon, but none got downloaded for Buttercup:
https://hydrogenaud.io/index.php?action=login https://www.aimp.ru/forum/index.php http://www.blizzard.com www.ubisoft.com
Icon downloads are disabled in current versions, for security. We'll provide a service to download icons soon.
@nickbe Icons were previously loaded by making a request directly to the domain listed in the URL field. As every request includes information about the client (IP, user agent etc.), several users complained regarding the lack of security/anonymity. Rightfully so - Buttercup was making requests without consideration as to whether or not it was secure to do so.
We changed to a cached-icon collection (very few icons) to get around this for a short period of time. Once we support proxied icon fetching with on/off controls, this can be closed and icons will work as expected.
So why not simply let us decide via switch if we want to fetch the icons directly from the domains? Myself, I wouldn't care at all
This.. is a good point.. ultimately we don’t want to ever be seen being lax from a security and privacy standpoint.. but this would be fine for many a user, including myself. I’d entertain this option - default off or show a prompt on first boot to choose.
I humbly wanted to ask if we can now finally get the icon downloads back. With literally hundreds of entries - ALL with the same icon - my folder look like a mess.
What about a simple right click on icon „Get Icon from URL“? with a little „unsafe for untrustworty sites“ warning?
Then it‘s up to the user to decide. Please!
Uodate: Or is this planned for 2.0?
If someone would want to implement such support they're welcome to, but we don't have bandwidth to do this ourselves just yet. Asking repeatedly as to the status is pointless as if there was progress, there'd be an update posted here.
EDIT: For anyone willing to help, you would need to look at implementing icon fetching as an API here: https://github.com/buttercup/ui - After that, each application that consumes that vault component would need settings to indicate whether loading icons is OK or not.
Desktop app currently uses the old UI, but there's work being done to upgrade it to that same component - so doing the work there makes sense.
I really don't get it. The complete functionality was already in place. So whoever created it the first time should have no problem putting it back in place, but now let the user call the function manually.
@nickbe It was never working 100%, and broke on a lot of sites due to CORS issues. We can't easily just wind back the code - it'd be days of modifications plus trying to work out how to combat CORS issues on the browser extension, which isn't really possible. The browser requests from a web context and CORS will deny the requesting of and parsing of HTML pages to find their icons - that needs to be done on the native side. We need a cross-platform solution and that's not as easy as it sounds.
If it were trivial, we'd have re-implemented it by now.
We've considered using our hosted service for this (https://my.buttercup.pw), as it could be a mirror for fetching icons. Perhaps we implement it that way and pay for its hosting costs out of the opencollective donations we have - @sallar ?
As far as I remember fetching the icons was abandoned for security reasons. Now you want to connect to your server, which of course if secure - or not - who knows. So this does not make any sense
The security concerns of having the app request the icons directly are that the end service can see your requests, the IP they originate from etc. - Using our service would be secure in that all requests would be anonymous. We wouldn't even collect logs. So yes, it would be far superior to the abandoned approach.
Right now we don't have the bandwidth for any of this, so we'd definitely appreciate the help if someone's willing to implement something.
Sorry, but I don't see it that way at all.
If you want to store passwords for sites you want to login to (IP address can be tracked anyway then), then why would you have a problem getting an icon on demand from exactly the same site? You visit the site, you use passwords on this site and yet fetching an icon is ssen as a security concern..... I don't get the sense in that.
The way I see it we could solve this paradoxon by letting the user manually upload icons. (not comfortable, but well at least a solution). Is this easier to implement?
I would very much like to try and implement the feature myself, but I didn't manage to build the buttercup executable on windows so far because of errors during the build process. It seems that building on windows does not currently work, or that the dependencies have somehow changed or are partly undocumented.
If you could help here, then I'll try to implement something reasonable here.
why would you have a problem getting an icon on demand from exactly the same site?
You may be on a workstation or network where you do not want random requests going to service X. You may never want any requests going to any service - perhaps you store them but never need to access them yourself. What I'm trying to explain are concerns that others have given to us, and I definitely think they're valid, from a privacy perspective.
I don't expect everyone, or even most people (myself included), to care about such an issue. But I believe we should at least give people a choice.
letting the user manually upload icons
Too cumbersome, and not enjoyable imo. Also terribly inefficient.
We're going to go with our icon host, which is now live (and we're working on integrating it into our user interfaces). Icons will be fetched directly from it and cached locally, when the feature is enabled, only. Icons will be fetched by domain (not path), and the service will act as a proxy so that no IP-related information makes it to the target service. Our icon host won't track anything - no access logs - and it won't require any user data.
Also, by giving users a switch, there's no obligation to using it. This way, icons can be turned on to make the app that much more appealing, and you don't have to give it a second thought. It should be that simple imo.
I hope this addressed this request, as it's the best solution we could come up with to please the most users, while remaining secure.
If you want to see it getting build there's an MR on the UI library.