W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2016

Re: [Proposal]: Set origin-wide policies via a manifest.

From: Mike West <mkwst@google.com>
Date: Thu, 28 Jul 2016 17:46:28 +0200
Message-ID: <CAKXHy=eoU+khDZN5T9jBji8srePVHrjuv0mCBWOcTH0CrFk+fg@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Brad Hill <hillbrad@gmail.com>, Patrick Toomey <patrick.toomey@github.com>, Joel Weinberger <jww@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
Off the top, I think we're basically arguing about spelling right now, and
that doesn't seem like a productive way to spend our time. :) You're
accepting the core claim that we need to send the version name up to the
server. Whether we spell it as `Origin-Policy: "name"` or `Cookie:
origin-policy=name` does not seem like a meaningful distinction from a
privacy perspective.

On Thu, Jul 28, 2016 at 5:30 PM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yes, but how common would that be


Since server push is the only way I think this feature can be deployed
without substantial performance regressions, I'd suggest that the problem
will be very common.

and why couldn’t the server get the info it needs by encoding it (with the
> port etc.) in a cookie?


Let's stipulate for the moment that we'd be able to design a cookie-based
mechanism that would be acceptable. Let's say we decided that origin cookies
<https://tools.ietf.org/html/draft-west-origin-cookies> were actually a
great idea, reserved a new prefix
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes>, and sent
the result up to the server. This has the advantages that it takes care of
the cookie-like aspects of Origin Policy, in that it treats the concept
exactly like a cookie. (It has the disadvantages that we'd need to actually
agree upon and build all these things, but, assume magic.)

I think this misses the forest for the trees, however: yes, we _could_
deliver this information as a cookie. But it _isn't_ a cookie. Treating it
like a cookie is simply confusing to the developer, and doesn't add
anything from the user's perspective, because browsers have already
addressed the general issue of "stuff that we send to the server that
implies state".

If you have Chrome installed locally, take a look
at chrome://settings/cookies, which you'll note groups together things like
cookies, local storage, channel ID, etc. These are all separate things. We
don't need to pretend that they're the same thing in order to give users
meaningful control.

-mike
Received on Thursday, 28 July 2016 15:47:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC