Show tagged entries
Monday, June 27. 2011
The (Dutch) law, that requires a user to agree before storing data, doesn't only apply on HTTP cookies. But in fact any kind of data that is stored on the users computer. Such as; HTML5 storage, flash cookies. But also desktop applications, etc.. The law also states that cookies "required" for certain functionality, are allowed without confirmation. Personally I don't see how anything will change, with this exception in place. And I wonder how many experts were involved into making this law. But that is a subject for another article perhaps...
What are cookies
Cookies are little packages of information stored in the browser of a website visitor, they can contain "small" amounts of data such as an identifiable token or a user preference.
What purpose do cookies serve
Cookies are very generic and can be used for many things, good and bad. The most popular probably being tracking your activity and advertisement. But they are also used to keep a state between requests and to store a preference. Such as "remember me" at a login form, or perhaps "no I do not want to participate in your survey".
Another thing that has been happening, is visitor awareness and thus browser features. More and more people block cookies to stop advertisement tracking, but unfortunately this also prevents a user to use the features he or she wants to use (such as login sessions, etc.). There is an answer for this and quite a few browser vendor's plan on implementing the "Do Not Track" (http://donottrack.us/) feature, or have already done so. But I'm not too happy with it. The downside of "Do Not Track" is that it's voluntary for website owners and advertisement companies to respect this feature. Other tools include projects such as "Ad Blocker", that only block cookies (and more) for advertisement purposes. It works pretty good, but that is hardly user-friendly.
But, back to "no more cookies"... How do you solve the problem of keeping a state between requests over a stateless protocol?
Well in short, I have some ideas but definitely no real answers. I don't think there is a real answer just yet.
Let's take the example of a login session. Where you want to offer a secure section to your visitors, where they can (e.g.) read their e-mail, privately. A few things come to mind:
Many, if not all, of the things I mentioned above would require secure connections (SSL/TLS) to avoid other security problems. Which might not be a bad move anyway.
Personally I think that there is a future, in an improved implementation of digest authentication over SSL. One that uses HMAC and stronger algorithms, SSL would then supply the missing server validation feature. It should also be more strict and not fall back to insecure legacy features.
All in all I firmly believe that the browser should play a big role in this new cookie recipe and should (partially) solve these problems. Also there should be a more clear separation between "generic storage" and authentication versus a simulated persistency. In more perfect world I would vote for a solution that works on other (underlying) layers and make it application agnostic.
I suppose the point I'm trying to make with this article is the following: Take away a feature the entire world uses (since 1996), and wait for the brilliant and creative minds, perhaps such as yourself, to come up with a more innovative feature. It's time for something better!
Another interesting read:
I made some updates to this article, based on some comments.
Display comments as (Linear | Threaded)
I like the digest idea, or simply SSL-certificate-based authentication. Underused if you'd ask me =)
I recently wrote a tutorial how to implement SSL client certificates with PHP: http://cweiske.de/tagebuch/ssl-client-certificates.htm
The commit/rollback approach would still require you to keep state in what would still be called a session...
P.S. How about numbering your proposals? Would be easier to comment on them then
I wasn't detailed enough, I updated the initial article to make it more clear what I wanted to say. Thanks for your feedback.
The idea behind it is that you submit your data constantly, like in e.g. a wizard. Each step results in an increment of data being posted. So this would only work for specific systems.
Storm in a teacup. A handful of bureaucrats with no technical knowledge will not have a significant influence here. The law is unworkable.
The only parties that will be even slightly troubled by this will be the Adsenses and the Google Analytics of this world, and they're smart enough to figure something out. The vast majority of websites will not change a single thing.
Thanks for taking the time to comment.
I think it's a storm in a teacup also, but it made me wonder about alternatives. We rely for so long on cookies, there must be a better way of going about it. I'm quite curious what people come up with.
I always thought that these "cookie" laws concern protecting of user privacy in a way that servers will not store data about them. If I am correct than all methods you described would be against law, am I right?
The law I'm referring too dictates that an application must ask permission before it's allowed to store (personal) data on the device of the user. Being it a website or an "app". You are referring to a different law that involves storing "personal data" (like e.g. an IP address) on a server.
But this article is more about "What if" and I'm merely using the new law as jump-board for alternative solutions.