Re: Geolocation header

Thanks Ilya,

I think it would make perfect sense re-using CH machinery for this, keeping
things simple to implement and still guaranteeing sites only get
geolocation information when permissions are granted and for requests that
need it. So to summarize:

- CH provides a mechanism to only send geolocation to origins that
explicitly accept it (Accept-CH), and its lifetime (Accept-CH-Lifetime).
- UA would only send Geolocation header if the origin had permission
already granted.
- Permission can only be obtained through JS Geolocation API. Geolocation
headers are only used as a transport mechanism.
- Suborigins <https://w3c.github.io/webappsec-suborigins/> would provide
path-based origins if/when adopted. In the meantime, sites can use
subdomains (e.g. newyork.restaurants.com would not send Accept-CH for
Geolocation, but local.restaurants.com would send Accept-CH for
Geolocation, so only the latest would ever get Geolocation header, when
permissions are already granted).
- Geolocation header would be restricted to only navigation requests.

I'll update the draft with these considerations.

On Fri, Aug 18, 2017 at 8:56 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:

> Hey all.
>
> On Wed, Aug 2, 2017 at 7:05 AM, Luis Barguñó Jané <luisbargu@gmail.com>
>  wrote:
>>
>> After an initial thread on GitHub
>> <https://github.com/httpwg/http-extensions/issues/364>, I decided to
>> start here the discussion so it goes through the proper channels.
>> Here you can find a document detailing the problem and a possible proposal
>> <https://docs.google.com/document/d/1zL4qyOpp6W36H4_eMpmth3Yj_ZTMZ3wCupc01q5qatA/edit>
>>
> After a bit of discussion, it looks like Client Hints (CH)
>> <https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04> would
>> be a great way to solve this use case, so I'm preparing a draft for a
>> CH-based approach.
>>
>
> As discussed on the GH thread — and I think others echoed same suggestion
> on this thread — I think we should drop the header-based ("type") prompt
> trigger: it's not essential and, based on experience, a bad UX pattern.
> That aside, there's path..
>
> We've looked at path scoping for CH in the past, but the tradeoff between
> functionality that it enables vs. associated implementation complexity and
> (lack of) enforcement is — IMO — not worth it -- e.g. nothing stops a site
> from scoping to "/", which I would expect most sites to do anyway, just as
> they do today with cookies. My recommendation here would be..
>
> 1. Use default origin scoped opt-in that CH provides
> 2. If/when suborigins proposal [1] becomes a thing, it'll allow #1 to be
> path-scoped in a "generic" way.
> 3. Optionally, in addition to #1 + #2, this particular hint could be
> restricted to navigation requests only; which would provide a much stricter
> (and UA enforceable) policy.
>
> ig
>
> [1] https://w3c.github.io/webappsec-suborigins/
>