RE: Requiring Authenticated Origins for Geolocation API's: Open Call for Comments (deadline - February 1, 2015)

> I'm confused, what's the difference between a secure origin and an authenticated origin? I would assume that a secure origin had a valid certificate that was certified by a trusted source. Is it that easy to get such certificate?

Reasonable question, and I won't attempt to provide an answer.  Please note that I specifically used the term "authenticated origin" because that was the term that was once defined in http://w3c.github.io/webappsec/specs/mixedcontent/:  " An origin can be called authenticated when it either refers to a source which is impossible not to trust (e.g. localhost), or to a source which can be adequately verified as authentic. " 

 However, this document seems to be a living, rapidly-changing document and the latest Editor's Draft (dated Nov. 4) seems to no longer have this definition, and is now opting for defining a "potentially secure origin."  

It is unfortunate that we are having trouble getting our terminology straight on this topic.

> Also, an issue with using the geolocation api over insecure origins (and especially http) is that you might end up passing in clear trough the wire some personal and identifiable information, which obviously, isn't a great idea.

Don't disagree, but what in your opinion is the solution for mitigating this problem?  Is it to require secure origins?  Is it to display appropriate warnings to the end user when the webpage corresponds to an insecure origin?

-Giri

-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Thursday, November 06, 2014 1:22 PM
To: public-geolocation@w3.org
Cc: mkwst@google.com
Subject: Re: Requiring Authenticated Origins for Geolocation API's: Open Call for Comments (deadline - February 1, 2015)

On Thu, 6 Nov 2014, at 05:10, Martin Thomson wrote:
> An authenticated origin is not sufficient to prevent situations where 
> users release information.  For an authenticated origin to provide 
> meaningful protection, users not only need to verify that the site is 
> authenticated (for which there is ample evidence that they do not), 
> they also need to ensure that it is the site that they intend to send 
> this information to.  That's much, much harder.
> 
> Requiring an authenticated origin is not a particularly high hurdle 
> for a motivated attacker to clear.  In fact, it's trivial to redirect 
> to an authenticated origin from an authenticated one.  Once there, the 
> entire toolbox of phishing tricks (confusable characters, long names,
> etc...) are available to help make the URL look credible.

I'm confused, what's the difference between a secure origin and an authenticated origin? I would assume that a secure origin had a valid certificate that was certified by a trusted source. Is it that easy to get such certificate?

Also, an issue with using the geolocation api over insecure origins (and especially http) is that you might end up passing in clear trough the wire some personal and identifiable information, which obviously, isn't a great idea.

> The cost of the proposed change is that this will actually break sites 
> that currently use the API.  From the large (maps.bing.com) to the 
> small (www.wtfsigte.com).

Chromium added some metrics recently to check whether there is a significant usage on non-secure origins. I think it's too early to share data but I'm pretty sure, we will be able to do so soon. The plan is to iterate from there. If we the usage is low enough, we will try to deprecate the API on non-secure origins.

-- Mounir

Received on Thursday, 6 November 2014 21:43:43 UTC