Re: [http-state] Apps area review of draft-ietf-httpstate-cookie-19

[Adam Barth <[e-mail]>]

On Sun, Dec 5, 2010 at 10:05 AM, Lisa Dusseault
<[e-mail]> wrote:
> Hi Adam and others,
>
> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
>
> Document: draft-ietf-httpstate-cookie-19
> Title: HTTP State Management Mechanism
> Reviewer: Lisa Dusseault
> Review Date: Dec 5, 2010
> IETF Last Call Date: 2010-11-29
> IESG Telechat Date: 2010-12-16]
> Summary: I recommend this document for publication.  The document
> alone is quite valuable, and the actions to register headers and mark
> other documents as historic makes it even more useful to the Internet
> community. I also found this document had strong investigation,
> discussion and reviews in its history.
>
> Major Issues: None
> Minor Issues:
> Section 3. "Origin servers can send a Set-Cookie response header with
> any response.".  Do we happen to know if it's more common for user
> agents to handle, or ignore Set-Cookie response headers on error
> responses?  I'd be surprised if user-agents do handle them including
> on 500-level, 400-level and particularly on a 100 Continue response,
> but I haven't tested it.  Is it part of your tests?

I haven't tested those cases specifically.  I suspect user agents
process Set-Cookie headers for 500-level and 400-level responses.  I'm
less sure about 100-level responses.

> So while this
> statement is factual, it might not help servers much.  If my
> assumption about some clients ignoring the header on some classes of
> responses is correct, I would add that information to the document in
> a non-normative sentence.

I'll test this and update the document accordingly.

> Section 4.  As a matter of taste, my choice would be to make it even
> more clear that third-party cookie protections erected by user agents
> cannot provide the desired protection from cooperating servers.  E.g.
> "No limitations on cookie use can prevent cooperating servers from
> injecting identifying information in dynamic URLs."

Sure.  I wasn't exactly sure where you'd like this text to appear.  We
don't seem to mention third-party cookies in Section 4.  In Section 5,
we mention them three times.  We also discuss them in the privacy
considerations.

We now have the following text in the Privacy Considerations section:

          In particular, two collaborating
          servers can often track users without using cookies at all by
          injecting identifying information into dynamic URLs.

Thanks,
Adam