Subject: Geolocation header

From: Luis Barguñó Jané <[email-masked]>
Date: Wed, 2 Aug 2017 16:05:52 +0200

Hi,

I would like to discuss with you a proposal to solve the following use case:

Currently, the only mechanism to share your location with a website is
through the JS Geolocation API. This has some limitations: First, in order
to have the server know the client’s location there are two full roundtrips
required (one roundtrip to load the page with Javascript code, and a second
roundtrip to actually send the location to the server and get back a
location-aware response). While not as significant as the first limitation,
the second limitation is that the client must execute Javascript in order
to acquire location.

For example, for services like Search, it means that the very first
response from a server will contain non-localized results, and a second
roundtrip would be required to refresh those results (assuming Geolocation
permission is already granted for the origin).

There's many ways to solve this problem through headers, so no JS would be
required and clients could proactively include geolocation data in the very
first request (after the server asked for it in previous sessions, and
permissions are granted).

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.

It would be great to get your opinion on this, if this is something that
might be interesting for people in this working group, or whether I should
start this as an individual draft. Any recommendation?

Thanks!
Luis

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Aug 2017 19:19:38 +0200

> I would like to discuss with you a proposal to solve the following use 
the solution:  have a database with IP addresses and its locations ...

in order not to be tracked any good admin would block such geolocation 
headers;

---

From: Luis Barguñó Jané <[email-masked]>
Date: Wed, 2 Aug 2017 20:17:58 +0200

IP-based location can be off by up to hundreds of Km (specially on carrier
IPs). This is not a solution for the use case I'm presenting. For some
location-aware services (e.g. I want restaurants near me), you need a
precise location.

Also I'm not sure I understand why a good admin would block these headers.
Why would we have a JS geolocation API
<https://www.w3.org/TR/geolocation-API/> to provide precise location then?

This is not changing anything regarding permissions, and having geolocation
headers would require the same user consent we currently have for the JS
geolocation API. All this proposal is just about a technical improvement on
how location is shared with an origin (after permissions have already been
granted), so a single roundtrip can provide local results (instead of two
roundtrips).

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Aug 2017 21:52:27 +0200

On 02.08.2017 20:17, Luis Barguñó Jané wrote:
> IP-based location can be off by up to hundreds of Km (specially on 
> carrier IPs).
the reason for this is just simple; today it is my IP, tomorrow the IP 
of someone having the same ISP but living 100 miles away ...
> This is not a solution for the use case I'm presenting. For some 
bevor thinking about neccessarity of such a header, think of how the 
system itself knows its location?
and then if it is conformable to privacy ...
> Also I'm not sure I understand why a good admin would block these 
because of privacy?
> <https://www.w3.org/TR/geolocation-API/> to provide precise location then?
I don't know this API, but can you specify how this works on a normal PC 
(Windows/Linux/Unix/MacOSX)?
from where does it get the location?
> This is not changing anything regarding permissions, and having 
> geolocation headers would require the same user consent we currently 
> have for the JS geolocation API.
when blocking JS at all ...?
> All this proposal is just about a technical improvement on how 
> location is shared with an origin (after permissions have already been 
> granted), so a single roundtrip can provide local results (instead of 
> two roundtrips).
before thinking of this "optimization", it would be nice to think of 
less waste - especially tracking, advertising, malware, ... - in 
websites ...

---

From: Guilherme Hermeto <[email-masked]>
Date: Wed, 2 Aug 2017 13:45:47 -0700

Location aware services exist either way and for mobile devices, on which
bandwidth might be limited, I do see value in this "optimization" as not
all are fortunate of having access to high speed connections.

However, I believe the a couple areas could be better explained:

How should the service proceed if a zealous admin block the headers? Is
there a requirement to fallback to the JS geolocation API?

How would the user give his consent? Are there any other headers which may
raise similar privacy issues and how was it handle there?

On Wed, Aug 2, 2017 at 12:52 PM, Walter H. <[email-masked]>
wrote:

> IPs).
> the reason for this is just simple; today it is my IP, tomorrow the IP of
> someone having the same ISP but living 100 miles away ...
>
> geolocation headers would require the same user consent we currently have
> for the JS geolocation API.
>
> All this proposal is just about a technical improvement on how location is
> shared with an origin (after permissions have already been granted), so a
> single roundtrip can provide local results (instead of two roundtrips).
>
> before thinking of this "optimization", it would be nice to think of less
> waste - especially tracking, advertising, malware, ... - in websites ...
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 2 Aug 2017 20:45:38 +0000

Interesting.

How symmetrical is this proposal? I.e. Is there a use case where a user agent requests a geolocation from a server?

Regards
Lucas
________________________________
From: Luis Barguñó Jané [[email-masked]]
Sent: 02 August 2017 15:05
To: [email-masked]
Subject: Geolocation header

Hi,

Currently, the only mechanism to share your location with a website is through the JS Geolocation API. This has some limitations: First, in order to have the server know the client’s location there are two full roundtrips required (one roundtrip to load the page with Javascript code, and a second roundtrip to actually send the location to the server and get back a location-aware response). While not as significant as the first limitation, the second limitation is that the client must execute Javascript in order to acquire location.

For example, for services like Search, it means that the very first response from a server will contain non-localized results, and a second roundtrip would be required to refresh those results (assuming Geolocation permission is already granted for the origin).

There's many ways to solve this problem through headers, so no JS would be required and clients could proactively include geolocation data in the very first request (after the server asked for it in previous sessions, and permissions are granted).

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.

It would be great to get your opinion on this, if this is something that might be interesting for people in this working group, or whether I should start this as an individual draft. Any recommendation?

Thanks!
Luis

---

From: "Walter H." <[email-masked]>
Date: Thu, 3 Aug 2017 06:55:37 +0200

On Wed, August 2, 2017 22:45, Guilherme Hermeto wrote:
> Location aware services exist either way and for mobile devices, on
which bandwidth might be limited, I do see value in this "optimization"
as not all are fortunate of having access to high speed connections.

this admin also blocks JS, so any fallback doesn't make a sense

> How would the user give his consent?

Has any user ever given his consent to be tracked?

> Are there any other headers which may

these aren't handled,
I don't know of an web admin that does a correct job: or do you know a
popular website, that doesn't interpret the user agent?

it is absolutely invalid to think that a server must do a clients work ...
(the server MUST NOT decide what to sent, the client desides what to
render and what not and how to render)

---

From: Guilherme Hermeto <[email-masked]>
Date: Wed, 2 Aug 2017 23:34:07 -0700

> this admin also blocks JS, so any fallback doesn't make a sense

Maybe I'm not understanding correctly. Are you are referring to people
without any access to Javascript?
Because Gelolocation API is not something new:
https://dev.w3.org/geo/api/spec-source.html

> Has any user ever given his consent to be tracked?

Browsers ask for the user permission to use the Gelolocation API and even
though the user gives the consent once, some clients keep tracking the user
for long after. So the potential for abuse already exists in the client. It
isn't being introduced on this proposal.

> render and what not and how to render)
I do agree with you that the client MUST decide what it will render.

Maybe the Geolocation-Request header name is too imperative? The client
should decide if it will send the user location (after acquiring the proper
consent).

For instance, RFC 2109 <https://www.ietf.org/rfc/rfc2109.txt> describe the
Set-Cookie header which instructs the client to store a cookie and send
this cookie back in subsequent requests with the Cookie header. The client
may disable cookies and completely ignore the Set-Cookie header. I see a
correlation here, where the client is free to ignore the instruction from
the server, but the SetCookie process is initiated by the server (which, I
guess, also requires user consent).

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Aug 2017 08:02:58 +0100

> isn't being introduced on this proposal.

I don't see that as a good argument for increasing the
potential for abuse. That seems like making an attack
surface bigger, which'd normally be regarded as a bad
plan.

Separately, as a happy NoScript user, I'd also prefer
to not have yet another attack vector to have to worry
about.

S.

---

From: Guilherme Hermeto <[email-masked]>
Date: Thu, 3 Aug 2017 00:11:54 -0700

> to not have yet another attack vector to have to worry
First, I really admire that you can live these days NoScript...

But going back to the issue in hand, as your client gives you the option to
block script, and to block cookies, it must also give you the option block
Geolocation. As I mentioned in my previous message, like a SetCookie that
is initiated by the server, the client must make the final decision if the
data is sent to server or not.

Btw, when I mentioned abuse, I meant it as privacy issue. And there are
clearly privacy issues, just like it does with cookies. But can you really
call it an attack?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Aug 2017 08:29:11 +0100

> First, I really admire that you can live these days NoScript...

Well, I find it faster and more privacy friendly so I'm
fine with missing out on all those lovely active menus
and dancing images:-) I'm even more fine with it vastly
reducing the number of times I send packets to advertising
networks. And it can also whitelist when I need it to,
so I'd encourage people to try it.

> data is sent to server or not.

I find that the level of control offered by browsers to me
as a user seems to decrease over time. I can understand why
that's the case, esp. on mobiles, but am not keen on that.

And while I don't agree that clients "must also give" a chance
to turn this off, I would hope they'd treat it the same as
the JS API so it'd hopefully not be too awful. That said,
ISTM a lot of these things are such that if sites keep asking,
then the user will eventually fold and give up their privacy.
So having a browser ask when before it wouldn't also seems
like a disimprovement.

> clearly privacy issues, just like it does with cookies. But can you really

Personally, I do consider web sites wanting to know my location
as an attack on my privacy in almost all cases. I realise that's
uncommon and that some people say they like being tracked. I don't
know what the general population think about this, as I suspect
they just take whatever defaults browsers choose and click ok,
if not the first time, then eventually.

S.

---

From: "Walter H." <[email-masked]>
Date: Thu, 03 Aug 2017 16:36:49 +0200

On 03.08.2017 09:29, Stephen Farrell wrote:
> I find that the level of control offered by browsers to me as a user 
> seems to decrease over time. I can understand why that's the case, 
> esp. on mobiles, but am not keen on that. 
mobiles are the only which have a legal use case; and these is specific 
to a small part of apps from the whole "app universe"

just think of an app showing you the times of the next public offer of 
transport near to your position/location ...

but for these special use cases there is no need of an extra header ...

> Personally, I do consider web sites wanting to know my location as an 
> attack on my privacy in almost all cases. I realise that's uncommon 
> and that some people say they like being tracked. I don't know what 
> the general population think about this, as I suspect they just take 
> whatever defaults browsers choose and click ok, if not the first time, 
> then eventually. 
Exact these are my thoughts ...

---

From: "Walter H." <[email-masked]>
Date: Thu, 03 Aug 2017 16:50:21 +0200

> https://dev.w3.org/geo/api/spec-source.html
I didn't say how they block JS, NoScript plugin is a way;
>
> Browsers ask for the user permission to use the Gelolocation API and 
> even though the user gives the consent once, some clients keep 
> tracking the user for long after. So the potential for abuse already 
> exists in the client. It isn't being introduced on this proposal.
>
yes and the difference between the Geolocation header is just this:

no Geolocation API no geolocation info for the server,
but the geolocation header doesn't have such a border ...

once allowed by the user, sent to any server without having too
and server owners are lucky => big data ...

> I do agree with you that the client MUST decide what it will render.
AND the server MUST NOT get any knowledge to let him decide what to send 
to the client ...,
as these is somewhat similar to censorship ...
>
> Maybe the Geolocation-Request header name is too imperative?
no there is only a few real use cases, and these are limited to mobiles ...
>
> For instance, RFC 2109 <https://www.ietf.org/rfc/rfc2109.txt> describe 
> the Set-Cookie header which instructs the client to store a cookie and 
> send this cookie back in subsequent requests with the Cookie header. 
> The client may disable cookies and completely ignore the Set-Cookie 
> header. I see a correlation here, where the client is free to ignore 
> the instruction from the server, but the SetCookie process is 
> initiated by the server (which, I guess, also requires user consent).
>
that is the point, Set-Cookie is initiated by the server,
and there is no need of any user consent, because an operating system 
also don't ask for permission to store data in the pagefile ...

and this Geolocation header is initiated by the client ...

---

From: Luis Barguñó Jané <[email-masked]>
Date: Thu, 3 Aug 2017 17:19:35 +0200

On Wed, Aug 2, 2017 at 10:45 PM, Lucas Pardue <[email-masked]>
wrote:

> Interesting.
>
> How symmetrical is this proposal? I.e. Is there a use case where a user
> agent requests a geolocation from a server?
>

I can't think of any, but if you have something in mind, please let me know.

>
> Regards
> Lucas
> ------------------------------
> *From:* Luis Barguñó Jané [[email-masked]]
> *Sent:* 02 August 2017 15:05
> *To:* [email-masked]
> *Subject:* Geolocation header
>
> Hi,
>
> <https://github.com/httpwg/http-extensions/issues/364>, I decided to
> start here the discussion so it goes through the proper channels.
>
> <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.
>

---

From: Luis Barguñó Jané <[email-masked]>
Date: Thu, 3 Aug 2017 17:25:42 +0200

I'm not proposing a new permission or setting. The idea is consolidating
with the existing JS geolocation permission for a certain origin. Otherwise
I agree this would create a new vector.

An alternative version of this proposal through client hints would not even
have the ability to ask for permission, and clients would only send the
location to a site that has already permissions granted (through the JS api
in the past). Geolocation-Request header would go away from the proposal.

This means that if you go NoScript then you would not even be able to get a
permission prompt ever from JS, so you'd never attach this Geolocation
header.

This way, it is not opening a new vector for attack. This new Geolocation
header would only be sent to a site if that site was already in a situation
where it could get location through JS at anytime (because permission was
already granted to that origin). And the permission for the new header is
in sync with the JS geolocation API, which any user agent should expose in
settings - and let the user change the decision for any site at anytime
<https://dev.w3.org/geo/api/spec-source.html#privacy_for_uas>.

Regarding use-cases, and why this is not limited to mobiles or irrelevant
use cases:
- On desktop browsers can also expose precise location through JS API,
using wifi-based location (not ip-based). All main browsers already do that.
- Search-like services, news, media-content, social networks (a huge chunk
of internet traffic), and the internet as a whole would certainly benefit
from a solution that reduces 2 roundtrips to 1 roundtrip when the user is
Ok to send location to a site in order to get a local experience.

Getting a local experience seems quite far from censorship in my opinion.

On Thu, Aug 3, 2017 at 4:36 PM, Walter H. <[email-masked]>
wrote:

>> seems to decrease over time. I can understand why that's the case, esp. on
>> mobiles, but am not keen on that.
>>
> mobiles are the only which have a legal use case; and these is specific to
> a small part of apps from the whole "app universe"
>
>> attack on my privacy in almost all cases. I realise that's uncommon and
>> that some people say they like being tracked. I don't know what the general
>> population think about this, as I suspect they just take whatever defaults
>> browsers choose and click ok, if not the first time, then eventually.
>>

---

From: Guilherme Hermeto <[email-masked]>
Date: Thu, 3 Aug 2017 23:53:59 -0700

On Thu, Aug 3, 2017 at 7:50 AM, Walter H. <[email-masked]>
wrote:

> Because Gelolocation API is not something new: https://dev.w3.org/geo/api/
> spec-source.html
>
I get it, but as far as I can see, the same applies to Geolocation API too.
The user agent asks permission and it is stored for that particular domain
(like a cookie), so other servers wouldn't get it.

The problem I see is that, if the Geolocation-Request indeed work like a
Set-Cookie, it would expect all following requests to contain the
Geolocation header. In that case, the user agent would be sending the geo
information even when that is unnecessary... and I don't like that either.

> Can you elaborate on "server MUST NOT get any knowledge to let him decide
what to send to the client"? Because servers acquire such knowledge all the
time, doing authentication, authorization... but I'm assuming that isn't
what you meant.

> the Set-Cookie header which instructs the client to store a cookie and send
> and there is no need of any user consent, because an operating system also
> don't ask for permission to store data in the pagefile ...
>
Ok, I see what you mean here... on the cookie case the data is generated at
the server and in this case the data is generated at the client. I guess in
this case, since the client owns the data, makes sense for the process to
be initiated by the client (instead of the Geolocation-Request coming from
the server).

All said, what really concerns me is that even though there is the
Geolocation API to recommend how user agents should acquire and treat such
information there is no recommendation AFIAK about how the information
should be transmitted to the server and how the privacy measures the server
should observe while such information.

Should we work towards that?

---

From: "Walter H." <[email-masked]>
Date: Fri, 4 Aug 2017 09:54:33 +0200

> I get it, but as far as I can see, the same applies to Geolocation API
No, because it requires something you can disable - e.g. with NoScript ...

> (like a cookie), so other servers wouldn't get it.
this may be a mistake ..., as the control a user has over his system, this
"ask for permission" might be globally ...

when its using the Geolocation API, you have the chance e.g. with NoScript
to prevent a server from getting this ...

> Can you elaborate on "server MUST NOT get any knowledge to let him
> decide what to send to the client"?
> Because servers acquire such knowledge all the

No, I mean e.g. that a server MUST NOT interpret the User-Agent Header
field ...;
e.g. when it is the Google Crawler it sends the content, und when I search
in google and get this page, and click there will get a 404 or 403,
because it is not the Google Crawler ...

or other example:  there is an application you want to download, and the
webpage gives you only the download for the Linux port, not the Windows
port, because your User-Agent says Linux ...

> information

I don't know any API that does make thoughts about what sense and if there
is a legit use case ...

> Should we work towards that?

No,
first think of legit use and then think if you really want to put all
clients into the same group even when you know, that it is wrong ...

I bet by the answer of the following question ...

"From WHERE/HOW does a NON MOBILE know its location?"

it doesn't make any sense to have any geo location - neither API nor
header field - for user agents on non mobile devices ...

---

From: Luis Barguñó Jané <[email-masked]>
Date: Fri, 4 Aug 2017 10:31:17 +0200

> "ask for permission" might be globally ...

What do you mean the control might be global? The Geolocation API spec says
permission should be acquired through a user interface and "The user
interface must include the host component of the document's URI".

This is how browsers implement this today, following the spec. There's no
global permission, actually most implementations handle permissions
per-origin (protocol + host + port).
The same would apply to this header, any origin needs explicit permission
before getting geolocation data.

> header field - for user agents on non mobile devices ...

Desktop browsers use WiFi scans to geolocate the device, providing
locations up to ~10 meters accurate (as opposed to IP-based location that
can be up to ~100Km).

There's clearly a legit use case on both mobile and desktop. Otherwise why
would we have a standard for a JS geolocation API?

Let's be clear about how the Geolocation JS API works today. There's ways
to implement this header-based optimization that would not introduce any
new privacy risk.

---

From: "Walter H." <[email-masked]>
Date: Fri, 4 Aug 2017 10:58:45 +0200

On Fri, August 4, 2017 10:31, Luis Barguñó Jané wrote:

> The Geolocation API spec says

SHOULD doesn't mean MUST, so if dropping this
"ask interface", it is still conforming to the specs ...

> This is how browsers implement this today, following the spec.

today is nothing said about tomorrow ...

> Desktop browsers use WiFi

WiFi is a kind of mobile, I asked for non mobile ...

in other words, the server already knows the answer: IP address.

> There's clearly a legit use case on both mobile and desktop.

> Otherwise why

invalid question; this has to be interpreted this:

when you need geolocation, than use this API; nowhere is said, that you
have to use this at all ...

or is it forbidden to walk, even we have cars?

> There's ways

WOULD NOT doesn't mean WILL NOT, so it DOES introduce a new privacy risk.

---

From: Luis Barguñó Jané <[email-masked]>
Date: Fri, 4 Aug 2017 11:27:29 +0200

On Fri, Aug 4, 2017 at 10:58 AM, Walter H. <[email-masked]>
wrote:

> "ask interface", it is still conforming to the specs ..

Sorry, my bad, the spec claims "User agents MUST acquire permission through
a user interface"
So it's a MUST.

> today is nothing said about tomorrow ...

It is, since MUST is what the spec says.

> in other words, the server already knows the answer: IP address.

In any case, this is not specific to smartphones, but to any device with
wireless capabilities that can be used for geolocation purposes. This
applies by far to the big majority of devices connected to the internet
today. Clearly enough for a legit use case.

And you can always use IP location if that's enough for you. You are not
forced to ask for and get this new header on your server if you don't need
it.

> or is it forbidden to walk, even we have cars?

The same applies to the header proposal, the fact that servers have a way
to tell clients "send me a geolocation header", it does not mean the server
is forced to ask for that information.
Exactly the same as the server deciding whether to include JS to use
geolocation API.
Any server can still decide to not get any location data. Nobody is forced
to.

All I'm proposing is instead of "when you need geolocation, use JS
geolocation API", you can also ask for this geolocation header, so you save
one round-trip. This is a purely technical improvement.

> WOULD NOT doesn't mean WILL NOT, so it DOES introduce a new privacy risk.

My bad again, I was writing this e-mail as plain language.
I agree with you. We MUST not introduce any new privacy risk, and a proper
standard should guarantee that.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 4 Aug 2017 11:06:00 +0000

I was thinking off the top of my head, the removal of JavaScript presents some opportunity for User Agents to make use of a feature that they’ve not had yet.

I guess it boils down to whether the geolocation header field is restricted to being request only, or if it could appear on responses. This could support cases such as a long-polling client talking to a moving endpoint (IoT), or just sensors that work in more of a push mode of operation (aka unidirectional flows).

Lucas

From: Luis Barguñó Jané [mailto:[email-masked]]
Sent: 03 August 2017 16:20
To: Lucas Pardue <[email-masked]>
Cc: [email-masked]
Subject: Re: Geolocation header

On Wed, Aug 2, 2017 at 10:45 PM, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Interesting.

Regards
Lucas
________________________________
From: Luis Barguñó Jané [[email-masked]<mailto:[email-masked]>]
Sent: 02 August 2017 15:05
To: [email-masked]<mailto:[email-masked]>
Subject: Geolocation header
Hi,

Thanks!
Luis

---

From: "Walter H." <[email-masked]>
Date: Fri, 04 Aug 2017 13:29:36 +0200

On 04.08.2017 13:06, Lucas Pardue wrote:
>
> I was thinking off the top of my head, the removal of JavaScript 
> presents some opportunity for User Agents to make use of a feature 
> that they’ve not had yet.
>
not really, because, there is nearly not any site which has NO JS ...

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 4 Aug 2017 14:04:23 +0000

Walter H. wrote:

I’m not thinking in terms of web sites, web browsing etc. There are many applications of HTTP that do not depend on websites. Such services or APIs may be able to benefit from a standardised header-based mechanism, one that gives due consideration to privacy and security concerns.

There are user agents that do not include JavaScript interpreters. They may be on constrained environments where inclusion is not possible. In such cases, the opportunity to transmit geolocation without the burden of JavaScript may be attractive.

Lucas

---

From: "Walter H." <[email-masked]>
Date: Fri, 04 Aug 2017 16:28:26 +0200

On 04.08.2017 16:04, Lucas Pardue wrote:
> I’m not thinking in terms of web sites, web browsing etc.
>
this depends, in times where you find JS very often, there is no 
benefit, in not having to use the geolocation API, especially not, when
there is no indication not to use any geolocation at all ...

if we had nearly no sites using any JS, there would be a benefit, 
because the use of JS wouldn't increase ..., but this isn't ...
>
> There are many applications of HTTP that do not depend on websites.
>
these are waste and nobody really wants them: advertising, tracking, ...
>
> Such services or APIs may be able to benefit from a standardised 
> header-based mechanism, one that gives due consideration to privacy 
> and security concerns.
>
to have big data bigger then ever is not the goal ..., think of the end user
>
> There are user agents that do not include JavaScript interpreters.
>
of course my ancient Internet Explorer 1.0 from the 1990s :-)
use the right tool for the right work.
>
> They may be on constrained environments where inclusion is not 
> possible. In such cases, the opportunity to transmit geolocation 
> without the burden of JavaScript may be attractive.
>
it would be very attractive for ALL to have a internet without fake 
news, without advertising, without tracking, without malware, without 
phishing, ...

---

From: Luis Barguñó Jané <[email-masked]>
Date: Fri, 4 Aug 2017 16:47:52 +0200

>
> I was thinking off the top of my head, the removal of JavaScript presents
> some opportunity for User Agents to make use of a feature that they’ve not
> had yet.
>
> That is not true. Even sites that support JS, provide experiences with no
JS to optimize bandwidth.
The cost of sending down JS to use the geolocation API is much higher than
a header-based solution.

> to have big data bigger then ever is not the goal ..., think of the end

More data is not the goal. Any site can already get the same data through
JS API if they have permissions.
Exactly because of the end user, a header-based solution reduces data usage
and latency.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 4 Aug 2017 14:57:45 +0000

> these are waste and nobody really wants them: advertising, tracking, ...

That’s a rather simplified view and a pretty sweeping statement. I’d proffer there are several members of this working group that are responsible for, or have direct experience with such applications of HTTP. Caching in various forms springs to mind but there are many more. Pursuing a line that ignores the existence or usefulness of such use cases doesn’t add much value to this thread of discussion.

Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Guilherme Hermeto <[email-masked]>
Date: Fri, 4 Aug 2017 07:58:44 -0700

> No, because it requires something you can disable - e.g. with NoScript ...
Wait, the first thing you said was that an admin could block the headers...
is it off the table now? Same as NoScript there is a plugin called
ModifyHeaders for both chrome and FF.

> to prevent a server from getting this ...

Same with headers... you can block headers...

> port, because your User-Agent says Linux ...
Understood it now, but that is not the case here. Localized services is not
something new... If I am using a riding-hailing app in San Francisco why
should I care about which driver is currently available in London?

> I don't know any API that does make thoughts about what sense and if there

You misunderstood me. Geolocation API IS the recommendation on how user
user agents should acquire geolocation information:
https://www.w3.org/TR/geolocation-API/

> header field - for user agents on non mobile devices ...
Just because the server asks for the information doesn't mean the client
must comply. Have you read Luis proposal? It says the client "may" include.
Not even "should".

Geolocation API exists and will continue to exist. One way or another that
information will be sent to the servers and there is no standard on how
that information should be sent to the server through HTTP. You might not
be happy with the fact that the server initiate the process though
Geolocation-Request header, but it does not invalidate the need for a
standard when the data is acquired by the client (as it is today) and
should be sent to the server.

---

From: "Walter H." <[email-masked]>
Date: Fri, 04 Aug 2017 22:28:58 +0200

> Exactly the same as the server deciding whether to include JS to use 
but without JS on client side, this doesn't work and the server doesn't 
get anything;
and with the header proposal there is no 2nd safety layer

> I agree with you. We MUST not introduce any new privacy risk, and a 
> proper standard should guarantee that.
>
should guarantee means no guarantee;   the standard MUST guarantee that, 
and when we talk about a standard that is similar to a law,
it MUST prevent anybody who doesn't conform to the standard ...

and a fallback MUST be provided, in other words a server MUST do either 
both the JS-API and the header proposal or only the JS-API,
because it can't be, that for a legit use case you have to buy a new 
"smartphone", because the server only does header proposal ...

so I ask you: does it really make a sense to have this header proposal?

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 5 Aug 2017 15:34:18 +1200

> it MUST prevent anybody who doesn't conform to the standard ...

The IETF does not produce laws. RFCs are guides on how to communicate 
with the rest of the HTTP world.

The WG chair may correct me here, but AFAIK this WG focus is on 
producing documents that minimize interoperability problems between HTTP 
agents and increase their security and privacy as much as possible along 
the way.

NO RFC document can meet the requirement you are making this proposal 
match. However bad the proposal may be, this line of argument against it 
seems invalid to me.

> "smartphone", because the server only does header proposal ...

There are other fallbacks; not using any geolocation info, using other 
interfaces that JS-API, asking the user where they are, using 
pre-recorded database entries (both the geobase mentioned earlier, and a 
locally created alternative to that).

> so I ask you: does it really make a sense to have this header proposal?

Your arguments followed logically with different factual statements 
leads one to the conclusion that there is a use-case for it.

Amos

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 4 Aug 2017 16:25:17 +0900

> I agree this would create a new vector.

But it's still somewhat different. Let's say there is a restaurant 
search site. Let's say I give this site permission to get my location 
data. Let's say this site has two seach modes: Search locally, and 
search in a specific location (e.g. New York).

Now if the Geolocation API is used, the site might (not saying it would, 
but essentially it should) not activate location sending when searching 
restaurants in New York, because it doesn't matter whether I'm on First 
Street or on Main Street for that. However, the Geolocation-Request 
header would be sent with every request for this site, even when 
checking their privacy policy or whatever. It would possibly also be 
sent for every image request, every stylesheet request, every JS 
request, and so on, although browsers may be able to restrict that if 
the spec proposes that.

On the other hand, let's assume I'm searching for the nearest bakery in 
Paris. There's virtually a bakery at every corner in Paris, so the use 
of the Geolocation API could be tailored to this and send a new location 
whenever I moved 50 meters or so, whereas it would use a completely 
different granularity e.g. for gasoline stands somewhere in the 
countryside in the Mid-West. Such on-demand granularity changes could be 
simulated for the Geolocation-Request header by somehow triggering page 
re-requests, but this would be clumsy.

I think these are some of the differences that we have to think through 
carefully before moving on (or not).

BTW, I also think that the name of the header, "Geolocation-Request", is 
somewhat misleading, because it's not a request for geolocation.

Regards,   Martin.

---

From: "Walter H." <[email-masked]>
Date: Sat, 05 Aug 2017 11:13:09 +0200

On 05.08.2017 05:34, Amos Jeffries wrote:
>
>> and a fallback MUST be provided, in other words a server MUST do 
>> either both the JS-API and the header proposal or only the JS-API,
> There are other fallbacks;
No, a mobile using it now, can't it use any more when the server changes 
from JS-API to header proposal, because of this "optimization", that we 
needn't talk about, if we would take it serious ...
> Your arguments followed logically with different factual statements 
think of the difference between a mobiles and non mobiles ...
> leads one to the conclusion that there is a use-case for it. 
No, not any, because any use case already has been covered by JS-API 
..., and nobody told any new legit use case where the JS-API doesn't 
work ...
and by the way a serious use case is limited to mobiles; for NON MOBILEs 
there is not any use case ...

---

From: "Walter H." <[email-masked]>
Date: Mon, 07 Aug 2017 05:38:55 +0200

On 04.08.2017 16:47, Luis Barguñó Jané wrote:
>
>>         I was thinking off the top of my head, the removal of
>>         JavaScript presents some opportunity for User Agents to make
>>         use of a feature that they’ve not had yet.
>>
> That is not true. Even sites that support JS, provide experiences with 
> no JS to optimize bandwidth.
Do not talk about supporting JS, they DO REQUIRE JS, as experimental 
with no JS, DOES NOT mean, they don't need JS ...
> The cost of sending down JS to use the geolocation API is much higher 
> than a header-based solution.
take it serious ...,
in times nearly no site integrates any sorts of tracking, we need not 
talk about such an optimization;
removing the tracking shit optimizes more, and can be done without any 
need of extending HTTP ...

---

From: Luis Barguñó Jané <[email-masked]>
Date: Tue, 8 Aug 2017 14:37:15 +0200

Thanks for the feedback Martin, responding in-line.

On Fri, Aug 4, 2017 at 9:25 AM, Martin J. Dürst <[email-masked]>
wrote:

> But it's still somewhat different. Let's say there is a restaurant search
> site. Let's say I give this site permission to get my location data. Let's
> say this site has two seach modes: Search locally, and search in a specific
> location (e.g. New York).
>
> Street or on Main Street for that. However, the Geolocation-Request header
> would be sent with every request for this site, even when checking their
> privacy policy or whatever. It would possibly also be sent for every image
> request, every stylesheet request, every JS request, and so on, although
> browsers may be able to restrict that if the spec proposes that.
>

I agree, sites should be able to ask for location only when it makes sense.
The path parameter is flexible enough so a site could ask for location on
"restaurants/local" only, but not for "restaurants/newyork" or for
"/images/XXX" or "css/YYY".

The same way sites should take care of using JS Geolocation API today only
when it makes sense, they should make sure the path parameter is used to
specify when location is actually needed, and move things out of that path
if they don't need location.

That said, this should be recommended but can't be technically enforced,
since permissions are per-origin already in the JS Geolocation API.

> Paris. There's virtually a bakery at every corner in Paris, so the use of
> the Geolocation API could be tailored to this and send a new location
> different granularity e.g. for gasoline stands somewhere in the countryside
> in the Mid-West. Such on-demand granularity changes could be simulated for
> the Geolocation-Request header by somehow triggering page re-requests, but
> this would be clumsy.
>

Right, this use case is out of scope for the headers-based proposal. The
goal of headers is optimizing latency and bandwidth (reduce from two to one
roundtrip the "static use case of device location"). The dynamic situation
you describe would require many round trips to re-update results as you
move, so there's not much to optimize regarding the existing JS approach.

> somewhat misleading, because it's not a request for geolocation.

Do you have any better name in mind? Happy to update the proposal with a
clearer name that reflects better what this means.

---

From: "Walter H." <[email-masked]>
Date: Tue, 08 Aug 2017 22:01:06 +0200

On 08.08.2017 14:37, Luis Barguñó Jané wrote:
> On Fri, Aug 4, 2017 at 9:25 AM, Martin J. Dürst 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     search site. Let's say I give this site permission to get my
>     location data. Let's say this site has two seach modes: Search
>     locally, and search in a specific location (e.g. New York).
>
>     Now if the Geolocation API is used, the site might (not saying it
>     would, but essentially it should) not activate location sending
>     when searching restaurants in New York, because it doesn't matter
>     whether I'm on First Street or on Main Street for that. However,
>     the Geolocation-Request header would be sent with every request
>     for this site, even when checking their privacy policy or
>     whatever. It would possibly also be sent for every image request,
>     every stylesheet request, every JS request, and so on, although
with this header proposal there isn't any limitation to this on every 
request ...
> The path parameter is flexible enough so a site could ask for location 
> on "restaurants/local" only, but not for "restaurants/newyork" or for 
after the 3rd question you will allow it for the whole site, believe me ...
otherways the non existence of a serious use case is just proven ...
>
> The same way sites should take care of using JS Geolocation API today 
> only when it makes sense, they should make sure the path parameter is 
> used to specify when location is actually needed,
in comparison to the header proposal, the JS Geolocation API is used 
only when needed, because, you have these JS at every page then ...
> and move things out of that path if they don't need location.
in times of big bigger biggest data, you won't believe this yourself 
..., that this will happen;

just think of this HTML

<IMG SRC="https://www.example.com/img75756.gif">

with the header proposal, there will be sent the location data, with the 
JS Geolocation API, it would be quite strange ...
of course, you would be asked to allow this, but in case you have 
allowed earlier for the
URL https://www.example.com/showbarsaroundmylocation/

and now think of bad boys who put this HTML Tag anywhere; then you 
wouldn't take a notice
that you have sent your location to www.example.com, even your browser shows
https://www.bigelephant.co.jp
because you have allowed this, earlier ...

>
> That said, this should be recommended but can't be technically 
> enforced, since permissions are per-origin already in the JS 
> Geolocation API.
now you see with my explanation, that there is raising the vector in a 
not acceptable way ...
and the optimization you are talking about doesn't really make any 
sense, when you are talking serious about the
problems you're raising ...

Greetings from Austria

---

From: Luis Barguñó Jané <[email-masked]>
Date: Tue, 8 Aug 2017 22:41:09 +0200

> otherways the non existence of a serious use case is just proven ...

The permission is per-origin, so no need for a 3rd question. The permission
is the same as the JS API.

and the optimization you are talking about doesn't really make any sense,
> when you are talking serious about the
I'm still not sure I understand the tone of your replies, instead of a
constructive attitude. Regardless of the content we are discussing, I never
said what you mention "doesn't make any sense", even if I don't agree.
Because that goes beyond respect.

I still think two roundtrips to one roundtrip makes sense, and probably
others who care about the internet agree.

And back to the concern you have. See sentence in the document I sent:
"Consider: The Geolocation header MUST only be sent when the request is for
a page loaded in a top level frame."

If we decide to include this, the scenario you are describing is just gone?

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 9 Aug 2017 01:12:39 +0000

Could you simplify the path aspects of this to perhaps address some of the privacy concerns?

I'm thinking, coin a new .well-known address for geolocation and restrict UAs to only send request header there. This makes it harfer to proliferate the header unintentionally. This is still subject to origin level agreement and server asking for information.

Lucas
________________________________________
From: Luis Barguñó Jané [[email-masked]]
Sent: 08 August 2017 21:41
To: Walter H.
Cc: [email-masked]
Subject: Re: Geolocation header

The permission is per-origin, so no need for a 3rd question. The permission is the same as the JS API.

and the optimization you are talking about doesn't really make any sense, when you are talking serious about the
problems you're raising ...

I'm still not sure I understand the tone of your replies, instead of a constructive attitude. Regardless of the content we are discussing, I never said what you mention "doesn't make any sense", even if I don't agree. Because that goes beyond respect.

I still think two roundtrips to one roundtrip makes sense, and probably others who care about the internet agree.

And back to the concern you have. See sentence in the document I sent:
"Consider: The Geolocation header MUST only be sent when the request is for a page loaded in a top level frame."

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: "Walter H." <[email-masked]>
Date: Wed, 9 Aug 2017 07:30:38 +0200

> Could you simplify the path aspects of this to perhaps address some of the

YES: this header proposal is SHIT

---

From: "Walter H." <[email-masked]>
Date: Wed, 9 Aug 2017 07:28:57 +0200

On Tue, August 8, 2017 22:41, Luis Barguñó Jané wrote:
> The permission is per-origin,

exact this is a problem ...
you MUST give permission per-request and not per-origin ...

when you have given the permission for

www.getpizza.com

you also have given the permission for
<IMG SRC="https://www.getpizza.com/trackpixel.gif">
which could be found anywhere, where there is definitely no legit use case
and a not acceptable raise of the vector ...

have it?

> so no need for a 3rd question. The
> permission

see above ...

---

From: Luis Barguñó Jané <[email-masked]>
Date: Wed, 9 Aug 2017 08:49:08 +0200

On 9 Aug. 2017 7:30 am, "Walter H." <[email-masked]> wrote:

Amazing argument.

This is probably my last reply to your messages, since your lack of respect
goes beyond acceptable limits.

---

From: Luis Barguñó Jané <[email-masked]>
Date: Wed, 9 Aug 2017 09:00:26 +0200

Simplifying path seems like a good option, but not sure how non-top level
requests that use the well known path could be prevented from getting
location.

Restricting to top level frames and only send header when the origin is
visible to the user in the address bar seems even safer than the JS API
approach.

On 9 Aug. 2017 3:12 am, "Lucas Pardue" <[email-masked]> wrote:

> I'm thinking, coin a new .well-known address for geolocation and restrict
> UAs to only send request header there. This makes it harfer to proliferate
> the header unintentionally. This is still subject to origin level agreement
> and server asking for information.
>
> Lucas

---

From: "Walter H." <[email-masked]>
Date: Wed, 09 Aug 2017 21:29:02 +0200

On 09.08.2017 08:49, Luis Barguñó Jané wrote:
>
>
> On 9 Aug. 2017 7:30 am, "Walter H." <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Could you simplify the path aspects of this to perhaps address
>     some of the
>     > privacy concerns?
>
> This is probably my last reply to your messages, since your lack of 
> respect goes beyond acceptable limits.
as the question went beyond my acceptable limits ...

simplifying what?

---

From: "Walter H." <[email-masked]>
Date: Wed, 09 Aug 2017 21:58:08 +0200

On 09.08.2017 09:00, Luis Barguñó Jané wrote:
> Simplifying path seems like a good option, but not sure how non-top 
> level requests that use the well known path could be prevented from 
> getting location.
>
the same with Cookies, there isn't any restriction to send them, without 
the neccessarity of the site being actively viewed ...

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Aug 2017 10:31:29 -0700

Walter,

The message you posted (copied below) is in violation of the IETF Code of Conduct <https://tools.ietf.org/html/rfc7154> and creates a hostile environment.

This is a public warning, as per <https://tools.ietf.org/html/rfc3934>, to stop posting in this manner immediately. If it occurs again, you will be temporarily banned from posting to the list.

Thank you,

> On 8 Aug 2017, at 10:30 pm, Walter H. <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 18 Aug 2017 11:56:54 -0700

Hey all.

> a great way to solve this use case, so I'm preparing a draft for a CH-based

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/

---

From: Luis Barguñó Jané <[email-masked]>
Date: Tue, 22 Aug 2017 16:12:26 +0200

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 <[email-masked]> wrote:

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