Re: Geolocation header

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/