Direct login favicons

[Chris]

Hi,

After a through search through the forums, I notice that the issue of
favicons for direct logins has come up a few times.

Personally, I'm a heavy user of direct logins from various physical
locations. I have two issues with the icons. One of my direct logins
loads a favicon from a secure site, and therefore pops up an
authorisation window every time Clipperz loads. Another direct login
tries to load a favicon from a page that does not respond with a file
not found for at least 2 minutes, so the favicon has an image
placeholder until that time when it is replaced by the standard
Clipperz favicon.

Some solutions have been discussed, such as user specification of
favicon locations. I think that a simpler user option of toggling
favicon loading all together may be simpler to implement, if the time
needed to be spent on fixing this problem is an issue!

Thanks Marco and Giulio for providing a tool that has become a core
productivity and security tool for me at work.

Cheers,
Chris

[Giulio Cesare Solaroli]

Hello Chris,

we found favicons a very convenient way to help using our application.

We are aware of all the issues you have listed, but we have not found
yet a reasonable fix.
Removing favicons altogether is a very lousy way to fix the problem
that we would really would like to avoid.

If only Javascript could read the actual content of the favicon (or of
any other image) we probably know how to fix all these issues quite
nicely.

Regards,

Giulio Cesare

[claylong]

What about a simple favicon cache for each direct login? While it
might be too complicated to allow the users to select their own icon
for logins, maybe the weird loading issues could be resolved by
storing local copies of the working icons.

Just a thought.

Clay

On Jun 30, 7:52 am, Giulio Cesare Solaroli <giulio.ces...@gmail.com>
wrote:

> Hello Chris,
>
> we found favicons a very convenient way to help using our application.
>
> We are aware of all the issues you have listed, but we have not found
> yet a reasonable fix.
> Removing favicons altogether is a very lousy way to fix the problem
> that we would really would like to avoid.
>
> If only Javascript could read the actual content of the favicon (or of
> any other image) we probably know how to fix all these issues quite
> nicely.
>
> Regards,
>
> Giulio Cesare
>

[Giulio Cesare Solaroli]

Hello Clay,

"local" copy of favicons could be easily stored using the data://
protocol (at least for all browsers but IE). The problem is that I
haven't find a way to let the browser convert the content of the image
found at a given URL to its base64 representation needed for the
data:// protocol.

It could be possible to have a web service handling this conversion,
but this would leek some privacy info that we would like to protect.

Any concrete ideas on how to improve this problem are really welcome. :)

Giulio Cesare

[Jason Schmidt]

Giulio,

How about a three-part attack consisting of a web service that batches the fetching of favicons in a secure fashion, a simple security preference, and the ability for advanced users to manually enter data?

Yes, I know this does still leave one small whole were data can be gathered regarding a user with the web service, but I'll address that in a moment.

First, add a data type to the list (Text, URL, Date, Password) for FavIcon.  If a user enters an already-created data:// base64 string, they could then manually associate the favicon they want with the direct login they want.  For advanced users, that would provide an even higher degree of control, including the ability for some fun customization.

Next, when a new card/direct-login needs a favicon (not manually provided), have the client create an encrypted request for the domain's favicon that gets uploaded to Clipperz.  It is my understanding that the server first verifies a person's right to data before assigning their user ID in the session.  Even though the server doesn't know what data is contained inside the cards, it then knows that session X is authenticated for data-set Y.  This could be done in the same method as that handshake, encrypting the request using a key provided by the (already authenticated) server.

Then have the server batch all the requests to happen at once during a regular interval.  Make sure there is enough time between batches so that multiple requests can build up.  That way outside loggers cannot associate which incoming connection to the server requested which favicon at what time.  Encrypt the data:// string using the same key as originally used for each request to provide the data securely back to the client.  Additionally, the server can then internally cache the favicon in case any other user ID makes the same request, drastically reducing the traffic load to the favicon file and speeding up the service as a whole.

The only thing this does *not* protect against is an unscrupulous Clipperz server collecting a list of which user ids requested which favicons, although it still doesn't say who the user id is in the real world, or how many cards they have for a given domain.  This could be further minimized by putting a simple on/off toggle in the preferences (account) section of the application to disable requests for favicons altogether.

Technically speaking, the fact that Clipperz requests all the favicons every times it loads could be seen as a current security risk, since a simple packet-sniffer can detect those requests combined with the fact that they were all requested in a short period of time right after connecting to a Clipperz server, which very clearly implies that a person has at least one direct login to said site.

What do you think?

-Jason Schmidt

[Giulio Cesare Solaroli]

Hello Jason,

relying on an external service is a possible solution, but we are
trying to avoid it.

I am investigating the canvas object, as this seems to be able to load
an image, and return its content; this could allow us to store its
content as a data:// url string that could be safely stored and loaded
without leaking any security info.

I will keep everybody informed about the progress we will make on this topic.

Thanks for your attention.

Regards,

Giulio Cesare