Re: Geolocation header

On 05/08/17 08:28, Walter H. wrote:
> On 04.08.2017 11:27, Luis Barguñó Jané wrote:
>> Exactly the same as the server deciding whether to include JS to use 
>> geolocation API.
> 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
> 
>> 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.
>>
> 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 ...
> 

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.


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

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

Received on Saturday, 5 August 2017 03:34:49 UTC