Re: Opting in to cookies - proposal

* Jonas Sicking wrote:
>First off, as before, when I talk about "cookies" in this mail I really
>mean cookies + digest auth headers + any other headers that carry the
>users credentials to a site.

I don't quite see why you would mix these. Is there anywhere where I can
read up on the use cases for an extra feature to enable the transmission
of cookies if not included by default? Especially for users credentials
in cookies it is difficult to imagine real world applications that would
depend on or at least greatly benefit from such a feature.

By "use case" I mean elaborate descriptions of how a user would use the
system as a whole to accomplish some well-defined and meaningful goal. I
am particularily interested in the user interface research relative to
this, for example, how the user is involved in the decision whether the
cookies are sent, and when they should be sent but are not (because the
user is not logged in at all with the other application, or the session
has expired).

It would seem that one way or the other, the embedding site would have
to ask the user to login into the embedded site and stay logged in while
it attempts to do whatever it is supposed to do. Training users to do
that would of course lead to social engineering attacks ("Please make
sure you are logged into your account <iframe/>", then exploit some vul-
nerability on the site, say a session riding one unrelated to "AC"). So
I am wondering what I am missing here.

Similarily, if this is just for some value-added services, it would be
very interesting to see the usability research on how users react when,
say, their customizations on some site suddenly no longer leak into the
embedding application (which of course depends on whether, say, they had
to consent before the browser would send the cookies to the embedded
site, in that case they would have at least a clue where the error may
come from).

So in general I am rather doubtful that an option to send cookies along,
be that with the Cookie or some alternate cookie header, is the best way
to address whatever problem is supposed to be solved by this (not that I
have seen a list, sufficiently detailed to propose alternate solutions,
of those so far; if they are available I'd appreciate a pointer). By the
time implementations of this are widely available, developers will have
alternate technologies at their disposal to implement whatever cookie-
dependant services they want.

So since the idea here is to keep the attack surface managable, it seems
the best course of action would be to not add this feature in the first
place, unless and until we have detailed information on why applications
cannot do without it sent here to the list and subjected it to public
scrutiny.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 21 June 2008 21:43:37 UTC