Jump to content
Enpass Discussion Forum

Why are favicons not downloaded directly?


ttk
 Share

Recommended Posts

Hi, 

one of the reasons why i preferred Enpass over other password managers like Lastpass and 1password was that the developers just distribute the binary, and everything else like sync and so on was completely in my own hands. No connections to other servers, nothing. This was great, since i believe a password manager should do as little communication as possible. Until now i was very happy with Enpass. 

But now i have some serious questions about the new favicon feature. The announcement says that Enpass downloads it from the developer's server, and you need to enable the feature on each client separately, so i assume each client downloads the favicons separately. So, in concern of data security and privacy, i'd like to know why this decision was made. 

Each website provides its icon as https://url.tld/favicon.ico. Why isn't Enpass able to download this file directly, but instead phoning home with all URLs which are stored in my vault? Why is it dependant on some kind of managed service now? Why aren't the icons stored in the vault in the same way as attachment files are stored?

If you guys have a reasonable explanation for this design decision, i'd like to hear it, since a password manager is a tool of high trust. Since Enpass downloads the icons when the vault is unlocked, and sends all the URLs to the developers, what guarantees me that it doen't do the same with all password data? I do not want to audit it's connection attempts with tcpdump every time an update was made. 

At least the other cloud based password managers do the sync with their servers with the encrypted vault file. 

Link to comment
Share on other sites

Hello @ttk and @Fabian1,

Thanks for writing  in!

The concerns highlighted in this post are absolutely legitimate and stand well-grounded in the the purview of data security and privacy from a user's perspective. Enpass firmly believes in the notion "Security is paramount" and the same has been(and will be) the basis of every feature of Enpass.

Many users had reported such issues and to address the same we request you to visit here for a comprehensive knowledge on how Enpass upholds data sovereignty with the website icons enabled.

Thanks!!

Link to comment
Share on other sites

On 10/3/2019 at 2:25 PM, Kashish said:

Hello @ttk and @Fabian1,

Thanks for writing  in!

The concerns highlighted in this post are absolutely legitimate and stand well-grounded in the the purview of data security and privacy from a user's perspective. Enpass firmly believes in the notion "Security is paramount" and the same has been(and will be) the basis of every feature of Enpass.

Many users had reported such issues and to address the same we request you to visit here for a comprehensive knowledge on how Enpass upholds data sovereignty with the website icons enabled.

Thanks!!

Hello @Kashish

I am currently reading the linked text.

I am a little bit shocked because the explanation isn’t right.

It is that much easy to collect the favicons.

All the data is included in the head of the html output file of a request.

For me that explanation in the text doesn’t make sense.

 

- request to www.my-page.com

- get the html source

- look for the header and collect the favicon meta entries

- follow the path/url

- got the favicon

 

I did this in the past multiple times. No problem.

 

With the decision providing an own server you always have to pay and maintain an additional thing.

You also have the whole traffic. I cannot understand this.

 

Currently, the favicons are not embedded to the Enpass items.

I prefer this.

 

Maybe an optional and additional way.

I like to see:

- edit an entry

- in the context menu to the image “fetch favicon”

- embed the requested image to the entry


I like  Enpass and I appreciate the work of the team.

 

Thanks.

 

Regards.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...
On 10/11/2019 at 6:21 AM, pio93qwertz said:

I am a little bit shocked because the explanation isn’t right.

From the linked text/explanation:

Quote

The Enpass app anonymously sends a POST query to our server over HTTPS protocol with all the domains in saved URLs. It does not contain any of your personal information. All the URLs in your Enpass items are stripped out to the domain part only...

The only identifiable information that reaches our server is your IP address, and our server does not log or cache it anywhere to identify you, so we do not know which websites a particular user has saved in Enpass. We cannot strip that out from the request since it is part of the HTTPS protocol.

I find the explanation reasonable and the privacy/security-first design sufficient. Insinuating that if Enpass sends an anonymous POST query of an entry domain (for the purpose of requesting an associated favicon) then it naturally follows that Enpass might send entry credential info...is ludicrous. O.o

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Will this wrong behaviour fixed?
And of course we have the best Favicon if we go the way to choose them by ourself.
AE sizes that be needed in webpages:

Apple Touch Icon: 57x57, 60x60, 72x72, 76x76, 114x114, 120x120, 128x128, 144x144 und 152x152 Pixel

Windows tiles: 70x70, 144x144, 150x150, 310x150 und 310x310

classical favicon: 16x15 , 32 x32

Some should hit;) In the code allways ask for the biggest size.

That makes a sour taste. Use our Iconway or none, really?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...