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

One more suggestion.  If the client tells the server it has "v10.0.1" and
the server is OK with that but has "v10.0.2" available, it would be nice if
the server could reply with:  "Origin-Policy: v10.0.2; async", (or
something) which tells the client, don't block on loading the new policy
for this request, but queue a task to update your policy to the new one
asynchronously.    For something like a "Like" button (or an ad) where TTI
is really important, we would love the transfer savings this could provide,
but also probably very rarely if ever want to block for a synchronous
update unless the client doesn't have a policy at all.

On Thu, Jul 28, 2016 at 8:46 AM Mike West <mkwst@google.com> wrote:

> 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
>