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

> > 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?
> 
> Yes, yes it is.  I think that the monetary cost for the cert is now
> basically zero and the cost of a domain is approaching zero

So is it easy for any evil guy to get a valid certificate. How much can we then rely on certificate revocation systems? Do browser implementations generally, at tls/ssl session setup, check against the CA if the server's certificate is in the revocation list?

If it is so that the added security of requiring https for sites using the Geolocation API is just "imaginary" then we may defer this issue and rely on more general solutions for giving web apps permission to use APIs. There was a workshop in Paris in September on trust and permissions http://www.w3.org/2014/07/permissions/minutes.html, and it is proposed that a W3C Community Group should be formed. 

BR
  Claes


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com

sonymobile.com



> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: den 7 november 2014 01:24
> To: Mounir Lamouri
> Cc: public-geolocation@w3.org; Mike West
> Subject: Re: Requiring Authenticated Origins for Geolocation API's:
> Open Call for Comments (deadline - February 1, 2015)
> 
> I really don't like having my "I hate security hat" on for this, ....
> 
> On 6 November 2014 13:21, Mounir Lamouri <mounir@lamouri.fr> wrote:
> > I'm confused, what's the difference between a secure origin and an
> > authenticated origin?
> 
> Precisely my point.  I'm sure that your UX research will help you
> understand just how little difference whether an origin is
> authenticated or not makes to user behaviour.
> 
> > 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?
> 
> Yes, yes it is.  I think that the monetary cost for the cert is now
> basically zero and the cost of a domain is approaching zero.
> 
> > 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.
> 
> Obviously it's not a great idea to offer anything service in the clear,
> but people do and until they stop doing that entirely, changes like
> this aren't going to solve the problem.
> 
> But that is not the concern I raised.  The concern I raised is that
> this doesn't provide any material security advantage to users.
> 
> >> 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.
> 
> Let me know how that goes.  But I don't believe that there needs to be
> a one-size-fits-all policy for browsers.  We've tried that, and it
> would be nice for so many reasons, but we need to recognize that things
> like this policy are an important part of what makes one browser
> different from another.
> 
> I'm more interested in finding things that will make a real difference.
> Incentives to add more security, not punishment for being lax.  If you
> have ideas that help there, then I'm all ears.

Received on Friday, 7 November 2014 09:50:50 UTC