Subject: Re: [httpwg/http-extensions] Geolocation Header (#364)

From: HTTP issue updates <[email-masked]>
Date: Sun, 02 Jul 2017 22:41:56 +0000 (UTC)

@mnot I suggested to @luisbargu that we should start a thread here first to hash out a few high-level questions about the existing proposal and possible CH integration, before we take it to the wider list. I'll re-open this, but if you feel that this belongs on the list, we can take it there.

---

First off, I think CH is a great conceptual fit to what @luisbargu is proposing, and I'd _really_ love to see us reusing established CH mechanism to ease implementation, both on the UA/client side and for developers — this makes everyone's life easier. I'll leave the "what" discussion, like granularity and type of data delivered via this hint, for a separate discussion, and focus on the how here...

>Header sent from the server to the user agent when a host is compatible with the Geolocation
> Header and is requesting geolocation to be attached in subsequent requests.
>
>>Geolocation-Request: Path="/localService"; Type=IfAlreadyGranted; Expires=Thu, 18 Dec 2017 12:00:00 UTC

The CH mechanism for the above is:

> Accept-CH: Geolocation
> Accept-CH-Lifetime: 86400 (seconds)

There are two bits missing: Path and Type. 

### Path
This is something we considered for CH in the past — "I want to scope my hints to a subpath" — but punted on due to limited (or so we deemed at the time, at least) utility vs implementation complexity tradeoff (equivalent to cookie paths, which is a burden we didn't want to take on). In the last few years of CH experiments, I've not heard any complaints or requests for this. I think that was the right call, and I'd suggest we stick with it.

### Type
fwiw, I'd like to make an argument that we should omit this. The idea here is to enable sites to trigger a permission prompt via a header, which seems convenient on the surface, but experience shows that this is a bad UX pattern: you [should be using JS API to trigger permission prompt after explaining the intent](https://docs.google.com/document/d/1WNPIS_2F0eyDm5SS2E6LZ_75tk6XtBSnR1xNjWJ_DPE/edit) and motivation. The incremental value we're adding with the header trigger is low, and seems more like a footgun. 

If you buy both of the above, then CH has all the necessary building blocks to enable Geolocation. 

---

@luisbargu WDYT? How critical, or not, are Path and Type for the use case you had in mind?

@yoavweiss curious to hear your thoughts on the above, and Geolocation use case for CDNs.

@mnot tactical question: what's the right process for followup RFC's to "register" hints to be compatible with Accept-CH? Do we need any extra steps in CH for a registry, or some extension hooks?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/364#issuecomment-312521490

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 04 Jul 2017 12:32:26 -0700

I still feel path can be useful, mainly to not "over-send" data that in this case might be sensitive from a privacy point of view. But I also understand the complexity tradeoffs, and Path is not core to this proposal. So if you went through this for CH and considered path was not worth, it probably applies well to this case.

Regarding Type to trigger prompts... Right, it's doable through JS but was nice to offer a purely http based solution. Also understand the tradeoff in this case for value vs complexity, and agree it's also not core to the geolocation header.

So on my side, if others think CH is the right approach for this, then for consistency and simplicity I'd be happy to follow that path and start a draft, on top of CH. Happy to hear other opinions :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/364#issuecomment-312938749

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 13 Jul 2017 15:00:23 +0000 (UTC)

One major difference between this and the other CH headers is that this header should only be sent to the first party (or only to hosts which have permission to view geolocation data, so to third parties that got such permissions before).
The use case of using geo info for content adaptation at the edge or origin seems an interesting one.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/364#issuecomment-315104444

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 21 Jul 2017 14:54:09 +0000 (UTC)

> One major difference between this and the other CH headers is that this header should only be sent to the first party (or only to hosts which have permission to view geolocation data, so to third p…

See https://github.com/httpwg/http-extensions/issues/372 for discussions related to that. I think this example is highlighting the need for origin-scoped hints, which I think we can do with ACH.

> So on my side, if others think CH is the right approach for this, then for consistency and simplicity I'd be happy to follow that path and start a draft, on top of CH. Happy to hear other opinions…

I think CH is the right fit. For a hot-off-the-press example, take a look at the [Device Memory i2s on blink-dev](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/8qlTjzRY9Mc/BYCuqWJXBwAJ).. Assuming we can drop the prompt trigger and path requirements, you can just follow that template.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/364#issuecomment-317023050