Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Richard Barnes

On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:

 On 2014-09-30, 4:29 AM, Henri Sivonen wrote:
 More immediately we should make it impossible to make persistent
 grants for these features on unauthenticated origins.
 
 This I agree with when it comes to privacy-sensitive API: Granting a
 persistent permission to an http: origin amounts to granting a
 persistent permission to everyone who in the future has a chance of
 performing an active MITM attack on you.
 
 I also think that we should definitely stop persisting the geolocation 
 permission grant for non-authenticated origins.  I'm not really sure if web 
 compat allows us to remove support for the API completely (although 
 admittedly I don't have data on this.)

Either way, we should collect some data before we take action.


 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Ehsan Akhgari

On 2014-10-02, 2:34 PM, Richard Barnes wrote:


On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:


On 2014-09-30, 4:29 AM, Henri Sivonen wrote:

More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.


This I agree with when it comes to privacy-sensitive API: Granting a
persistent permission to an http: origin amounts to granting a
persistent permission to everyone who in the future has a chance of
performing an active MITM attack on you.


I also think that we should definitely stop persisting the geolocation 
permission grant for non-authenticated origins.  I'm not really sure if web 
compat allows us to remove support for the API completely (although admittedly 
I don't have data on this.)


Either way, we should collect some data before we take action.


What data specifically?  I'm fairly confident that we can make this 
change no matter how many websites use geolocation from 
non-authenticated origins.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Martin Thomson

On 02/10/14 11:58, Ehsan Akhgari wrote:

What data specifically?  I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.


I believe that usual practice before we remove something we don't like 
is to provide some warning.  There are some big sites that use 
geolocation from http:// origins.


That said, those sites will continue to work.  It is most likely treated 
in the same way as the user rejecting the request for location.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Justin Dolske

On 10/2/14 1:07 PM, Martin Thomson wrote:

On 02/10/14 11:58, Ehsan Akhgari wrote:

What data specifically?  I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.


I believe that usual practice before we remove something we don't like
is to provide some warning.  There are some big sites that use
geolocation from http:// origins.

That said, those sites will continue to work.  It is most likely treated
in the same way as the user rejecting the request for location.


I think Ehsan is only talking about removing the persistent always 
allow permission. The effect of doing so would be that the user would 
simply be prompted each for each request, instead of it being 
automatically allowed. It's not treated as a permission denial, and is 
what happens by default in Firefox.


I'd have no objection to this. We can monitor Input feedback on the 
prerelease channels, before/after the change, to see if it's a problem 
prior to shipping it on release.


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Ehsan Akhgari

On 2014-10-02, 4:07 PM, Martin Thomson wrote:

On 02/10/14 11:58, Ehsan Akhgari wrote:

What data specifically?  I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.


I believe that usual practice before we remove something we don't like
is to provide some warning.  There are some big sites that use
geolocation from http:// origins.


Oh, for sure.  I don't have anything against warning people.  :-)  And 
in fact if we decide to do this we should publicize the idea on the 
hacks blog etc.



That said, those sites will continue to work.  It is most likely treated
in the same way as the user rejecting the request for location.


No, the way it would be handled is the user will get prompted again, and 
we wont show them the option of remembering their decision.  The 
geolocation functionality itself would keep working fine.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-10-02 Thread Ehsan Akhgari

On 2014-10-02, 4:38 PM, Justin Dolske wrote:

On 10/2/14 1:07 PM, Martin Thomson wrote:

On 02/10/14 11:58, Ehsan Akhgari wrote:

What data specifically?  I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.


I believe that usual practice before we remove something we don't like
is to provide some warning.  There are some big sites that use
geolocation from http:// origins.

That said, those sites will continue to work.  It is most likely treated
in the same way as the user rejecting the request for location.


I think Ehsan is only talking about removing the persistent always
allow permission. The effect of doing so would be that the user would
simply be prompted each for each request, instead of it being
automatically allowed. It's not treated as a permission denial, and is
what happens by default in Firefox.


Indeed (I phrased it very poorly!)


I'd have no objection to this. We can monitor Input feedback on the
prerelease channels, before/after the change, to see if it's a problem
prior to shipping it on release.


Great idea.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-30 Thread Henri Sivonen
On Fri, Sep 26, 2014 at 10:58 PM, Anne van Kesteren ann...@annevk.nl wrote:
 Exposing geolocation on unauthenticated origins was a mistake. Copying
 that for getUserMedia() is too. I suggest that to protect our users we
 make some noise about deprecating this practice. And that in that
 message we convey we plan to disable both on unauthenticated origins
 once 2015 is over.

I should have followed up on the other thread by now, but following up
here, since this is kind of a continuation of the other thread:

I think EKR's point about a one-time (non-persistent) grant when you
know what's in front of the camera isn't really much different from
using a form to upload a file over http is persuasive. And like
Richard said in his reply, a one-time, non-persistent geolocation
grant isn't that different from typing in an address into a form and
submitting it over http.

For immediate user security, do we really need to block the use of
there APIs on http if every API call prompts? By immediate I mean
ignoring the long term effects on the rate of https usage. I want
the rate of https usage to increase, but it's not clear that breaking
existing http: sites' use of geolocation that aren't actually more
dangerous that typing an address into an unauthenticated form is a
good way to get there.  (I think making HTTP/2 https:-only would be a
much better way.)

 More immediately we should make it impossible to make persistent
 grants for these features on unauthenticated origins.

This I agree with when it comes to privacy-sensitive API: Granting a
persistent permission to an http: origin amounts to granting a
persistent permission to everyone who in the future has a chance of
performing an active MITM attack on you.

Moreover, as long as the storage for the permissions doesn't store the
full origin, we should make sure that when the APIs are used on http:
origins, the code first realizes the call is on an unauthenticated
origin before the code tries to look at the permission storage.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-30 Thread Ehsan Akhgari

On 2014-09-30, 4:29 AM, Henri Sivonen wrote:

More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.


This I agree with when it comes to privacy-sensitive API: Granting a
persistent permission to an http: origin amounts to granting a
persistent permission to everyone who in the future has a chance of
performing an active MITM attack on you.


I also think that we should definitely stop persisting the geolocation 
permission grant for non-authenticated origins.  I'm not really sure if 
web compat allows us to remove support for the API completely (although 
admittedly I don't have data on this.)


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Dale Harvey
On 28 September 2014 17:38, Anne van Kesteren ann...@annevk.nl wrote:

 On Sun, Sep 28, 2014 at 3:08 PM, Karl Dubost kdub...@mozilla.com wrote:
  Imagine if I home developing my own little Web app on my computer, I
 need to get through the hops of deploying TLS.

 For testing purposes you can get by without TLS just fine. As far as I
 know the definition of authenticated origin includes localhost.


What is the definition of 'authenticated origins', particularly when
dealing with localhost, I am worried that mine and a lot of devs setup
includes setting up a local /etc/hosts file and working in convenient
environment in which it will be no longer be possible. Similiarly when
setting up ad hoc local networks or creating a standalone intranet,
something I do fairly regularly for demos at a conference, hackdays etc

This has already been a major painpoint as the author of an IndexedDB
library I am fairly constantly asked questions of my library doesnt work
when server from file://index.html since the security model deals around
the host, it makes things harder for all developers, new ones especially.

There is a solution for transmitting private information over the network,
and I believe the responsibility is on content authors to decide when that
is appropriate and when it is not and not the standards bodies. I agree
that any site in production on the live internet transferring users
information should be using https, but every website doesnt follow that use
case.



  Asking everyone to adopt TLS is a bit like asking everyone to switch to
 XML.

 Not really. XML requires redesigning your entire application from the
 ground up. Adding TLS is a little bit of configuration. Completely
 different ballpark.


  It doesn't visibly and directly improve the life of people. In the big
 scheme of things, it gives an additional layer of security on their
 communications, but not privacy.

 It gives privacy from passive and active network attackers, no?


  Even more so, telling to people that they have more privacy because the
 communication is secure end-to-end is deeply misleading. Secured
 geolocations end-to-end to an aggregator such as FourSquare, Google,
 Facebook, etc. doesn't change anything about your privacy.

 That's a question of trust, not one of privacy.


 --
 https://annevankesteren.nl/
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Anne van Kesteren
On Mon, Sep 29, 2014 at 2:02 AM, Adam Roach a...@mozilla.com wrote:
 Yes, I saw that. Your proposal didn't see a lot of support in that venue.

So far for geolocation there is nobody that is opposed.

For getUserMedia() there are claims of extensive discussion that is
not actually recorded in text. There was also a lot of pointing to
geolocation which does not seem like a valid argument. I don't think
they've made their case.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Anne van Kesteren
On Mon, Sep 29, 2014 at 8:01 AM, Dale Harvey d...@arandomurl.com wrote:
 What is the definition of 'authenticated origins', particularly when dealing
 with localhost,

https://w3c.github.io/webappsec/specs/mixedcontent/#authenticated-origin


 This has already been a major painpoint as the author of an IndexedDB
 library I am fairly constantly asked questions of my library doesnt work
 when server from file://index.html since the security model deals around the
 host, it makes things harder for all developers, new ones especially.

Maybe browsers should have some kind of developer extension that
allows you to temporarily read the file system through localhost.
There's a host of problems when you're using file URLs.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Dale Harvey
 There's a host of problems when you're using file URLs.

pun intended? :)

But I agree, for a long time developing off file:/// is pretty much
impossible and developers are now required to start a server in order to
build or use their entirely offline completely unconnected application, is
it really a surprise that noone is building offline capable web apps? 'have
an option / extention' is a weak workaround that puts the onus on often the
user(!) and the developer to be able to work around restrictions in the
base platform that shouldnt exist in the first place.

Similiarly with gUM, bluetooth, serial ports and tcp socket apis all
enabling more peer to peer (and offline capable) it seems entirely the
wrong approach to have the functionality of the base platform restricted to
a single end transport mode.


On 29 September 2014 10:06, Anne van Kesteren ann...@annevk.nl wrote:

 On Mon, Sep 29, 2014 at 8:01 AM, Dale Harvey d...@arandomurl.com wrote:
  What is the definition of 'authenticated origins', particularly when
 dealing
  with localhost,

 https://w3c.github.io/webappsec/specs/mixedcontent/#authenticated-origin


  This has already been a major painpoint as the author of an IndexedDB
  library I am fairly constantly asked questions of my library doesnt work
  when server from file://index.html since the security model deals around
 the
  host, it makes things harder for all developers, new ones especially.

 Maybe browsers should have some kind of developer extension that
 allows you to temporarily read the file system through localhost.
 There's a host of problems when you're using file URLs.


 --
 https://annevankesteren.nl/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Anne van Kesteren
On Mon, Sep 29, 2014 at 12:19 PM, Dale Harvey d...@arandomurl.com wrote:
 There's a host of problems when you're using file URLs.

 pun intended? :)

Heh. (Note that file URLs apparently count as authenticated origins.
Which makes sense.)


 But I agree, for a long time developing off file:/// is pretty much
 impossible and developers are now required to start a server in order to
 build or use their entirely offline completely unconnected application, is
 it really a surprise that noone is building offline capable web apps?

I hope the reason for that is that our solution for offline has been
bad thus far.


 'have
 an option / extention' is a weak workaround that puts the onus on often the
 user(!) and the developer to be able to work around restrictions in the base
 platform that shouldnt exist in the first place.

I'd like to think we have restrictions for a reason, although the
reason is not always great (e.g. compatibility with deployed content
is a rather annoying one).


 Similiarly with gUM, bluetooth, serial ports and tcp socket apis all
 enabling more peer to peer (and offline capable) it seems entirely the wrong
 approach to have the functionality of the base platform restricted to a
 single end transport mode.

I'm not sure what you mean by this. The more personal applications
are, the more reason there is to deliver them over TLS. Unless you
talk about some alternate way of distributing them?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Eric Rescorla
On Mon, Sep 29, 2014 at 3:44 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Mon, Sep 29, 2014 at 12:19 PM, Dale Harvey d...@arandomurl.com wrote:
  There's a host of problems when you're using file URLs.
 
  pun intended? :)

 Heh. (Note that file URLs apparently count as authenticated origins.
 Which makes sense.)


Chrome doesn't actually allow gUM from file:/// URLs, but Firefox does.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-29 Thread Adam Roach

On 9/29/14 03:02, Anne van Kesteren wrote:

On Mon, Sep 29, 2014 at 2:02 AM, Adam Roach a...@mozilla.com wrote:

Yes, I saw that. Your proposal didn't see a lot of support in that venue.

So far for geolocation there is nobody that is opposed.


I'm responding on the topic of gUM, but I'll point out that a response 
of this is nonsense as stated (Richard Barnes) does sound like an 
objection to me. I also read Karl Dubost's response as being less than 
favorable, and Chris Peterson 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1072859#c2) seems to be 
worried about how your proposal breaks existing websites.


Based on your statement, I do wonder what constitutes opposition in your 
mind. For clarity, I am opposed to your proposal for gUM.



For getUserMedia() there are claims of extensive discussion that is
not actually recorded in text. There was also a lot of pointing to
geolocation which does not seem like a valid argument. I don't think
they've made their case.


Sure, but determination of consensus is the job of the chairs. What goes 
into a spec is based on direction of the working group, not on the 
criteria of Anne van Kesteren thinks the working group has made its case.


Fundamentally, the problem is that you're coming to the conversation 
late, and you're not willing to do the work to catch up on the 
conversations that have already occurred. There's no WG historian whose 
job it is to research decision rationale for newcomers.


The reason you're not seeing anyone responding with compelling reasons 
on the working group mailing list is that the issue has been discussed 
and closed. No one has much energy to relitigate old issues, especially 
when objections are brought forth in the rather weak form of I'm not 
sure this was a good idea. If you wish to challenge the status quo, 
then the burden of proof is on you to come up with arguments that are 
both compelling and lucid enough to change the minds of the working 
group participants, not on the working group to justify its past work to 
you.


I note that one of the chairs has taken the exceptionally gracious step 
of inviting you to make your arguments in a more sensible, 
threat-analysis-based form. There's your opening -- take his suggestion, 
and make your case.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Anne van Kesteren
On Sat, Sep 27, 2014 at 10:10 PM, Richard Barnes rbar...@mozilla.com wrote:
 Are you making an argument more subtle than everything should be HTTPS, so 
 we should make HTTP less functional?

I'm not sure where you see me making that argument in this thread. I
simply recommended we move to require TLS for privacy-sensitive APIs.
And it still seems within the realm of possibility to do that for
geolocation and getUserMedia().


 I don't disagree that things should be HTTPS, but breaking the HTTP-schemed 
 web is not the way to get there.  That's like Verizon trying to get people to 
 use their favorite video streaming site by slowing down all the others.

No, it's not at all like that. It's about tightening the requirements
for getting access to privacy-sensitive user data. All this is saying
is that if you want this user data, you need to deploy TLS on your
site. And that can be done for free although it is unfortunately still
a bit of a hassle. But guides have been created, communities have
collected pointers, and gradually it will spread through conferences
how to get this done.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Anne van Kesteren
On Sun, Sep 28, 2014 at 3:08 PM, Karl Dubost kdub...@mozilla.com wrote:
 Imagine if I home developing my own little Web app on my computer, I need to 
 get through the hops of deploying TLS.

For testing purposes you can get by without TLS just fine. As far as I
know the definition of authenticated origin includes localhost.


 Asking everyone to adopt TLS is a bit like asking everyone to switch to XML.

Not really. XML requires redesigning your entire application from the
ground up. Adding TLS is a little bit of configuration. Completely
different ballpark.


 It doesn't visibly and directly improve the life of people. In the big scheme 
 of things, it gives an additional layer of security on their communications, 
 but not privacy.

It gives privacy from passive and active network attackers, no?


 Even more so, telling to people that they have more privacy because the 
 communication is secure end-to-end is deeply misleading. Secured geolocations 
 end-to-end to an aggregator such as FourSquare, Google, Facebook, etc. 
 doesn't change anything about your privacy.

That's a question of trust, not one of privacy.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Richard Barnes

On Sep 28, 2014, at 6:26 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Sat, Sep 27, 2014 at 10:10 PM, Richard Barnes rbar...@mozilla.com wrote:
 Are you making an argument more subtle than everything should be HTTPS, so 
 we should make HTTP less functional?
 
 I'm not sure where you see me making that argument in this thread. I
 simply recommended we move to require TLS for privacy-sensitive APIs.
 And it still seems within the realm of possibility to do that for
 geolocation and getUserMedia().

You say privacy-sensitive API as if it were a boolean variable.  But there's 
a whole continuum of risk here.

Arguably any API that can collect information from the user or transmit it on 
the wire is privacy-sensitive.  Should onmouseover and XHR be limited to secure 
origins?  After all, you can collect biometrics from keyboard and mouse events, 
and use them to identify users with fairly high fidelity [1].  If you continue 
down this line of thinking, you end up saying that HTTP-schemed sites can't 
have any meaningful user interaction.  This is what I mean by breaking the 
HTTP web.  

Yes, we have to draw lines.  The service workers and gUM examples show a good 
example of a line that can be drawn: Things that allow persistent, long-lived 
capabilities should only be granted for secure origins.  There, especially in 
the case of service workers, you end up with a bell cannot be un-rung 
scenario.  That could make sense for geolocation, in the sense that Henri 
raised.

I haven't heard a similar argument for restricting geolocation altogether.


 I don't disagree that things should be HTTPS, but breaking the HTTP-schemed 
 web is not the way to get there.  That's like Verizon trying to get people 
 to use their favorite video streaming site by slowing down all the others.
 
 No, it's not at all like that. It's about tightening the requirements
 for getting access to privacy-sensitive user data. All this is saying
 is that if you want this user data, you need to deploy TLS on your
 site. And that can be done for free although it is unfortunately still
 a bit of a hassle. But guides have been created, communities have
 collected pointers, and gradually it will spread through conferences
 how to get this done.

It's pretty glib to call something a bit of a hassle that can trip up even 
such well-resourced organizations as Apple [2].

--Richard

[1] http://www.darpa.mil/OpenCatalog/AA.html
[2] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Eric Rescorla
On Fri, Sep 26, 2014 at 12:58 PM, Anne van Kesteren ann...@annevk.nl
wrote:

 Exposing geolocation on unauthenticated origins was a mistake. Copying
 that for getUserMedia() is too. I suggest that to protect our users we
 make some noise about deprecating this practice. And that in that
 message we convey we plan to disable both on unauthenticated origins
 once 2015 is over.

 More immediately we should make it impossible to make persistent
 grants for these features on unauthenticated origins.


This is already the case for getUserMedia.



 I can reach out to Google (and Apple  Microsoft I suppose, though I
 haven't seen much from them on the pro-TLS front) to see if they would
 be on board with this and help us spread the message.


I already raised this issue with Google WRT gUM and they weren't interested
in making the proposed change.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Karl Dubost

Le 29 sept. 2014 à 00:38, Anne van Kesteren ann...@annevk.nl a écrit :
 It doesn't visibly and directly improve the life of people. In the big 
 scheme of things, it gives an additional layer of security on their 
 communications, but not privacy.
 
 It gives privacy from passive and active network attackers, no?

This is not what privacy is and that's one of the issues. You are talking about 
security not privacy. Privacy is not technical, it's a social agency of 
behaviors and laws. If you would like an example, there is a bridge in Ottawa 
(Ontario) which links to Gatineau (Québec) in Canada. On one side of the bridge 
(Ontario), you can take a portrait of the person and publishes it. On the other 
side (Québec), you are forbidden to take that pictures and publishes without 
authorization. This is not based on trust. This is privacy. :)

Secure communications are important and your proposal is important, but there 
are social costs and benefits in securing systems. It's not just a matter of 
saying let's do it. So I would love to see why you would like to do this and in 
which circumstances, what are the constraints around it, etc. Not only a Yeah 
bullet-proof vests are cheap these days, let's go out with them, instead of 
changing the guns law.


-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-28 Thread Adam Roach

On 9/27/14 02:24, Anne van Kesteren wrote:

On Fri, Sep 26, 2014 at 11:11 PM, Adam Roach a...@mozilla.com wrote:

This is a matter for the relevant specification, not some secret cabal.

I was not proposing doing anything in secret.

I also contacted the relevant standards lists.




Yes, I saw that. Your proposal didn't see a lot of support in that 
venue. And that's why taking it to a Mozilla mailing list rather than 
continuing the discourse that you already started feels like an 
attempted end-run around the standards process. Surely you understand 
why that appears unseemly, right?


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-27 Thread Anne van Kesteren
On Fri, Sep 26, 2014 at 11:06 PM, Richard Barnes rbar...@mozilla.com wrote:
 It is not our job to break the HTTP-schemed web to force everyone to HTTPS.

It is for features where it matters for end users.


 Users and web sites have been using geolocation on unauthenticated origins 
 for several years now without major implications.

Citation needed.


 It's no more dangerous than me typing my address into a form.

Those forms should also be behind TLS. But obviously forcing that is
far less practical than taking steps with geolocation.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-27 Thread Anne van Kesteren
On Fri, Sep 26, 2014 at 11:11 PM, Adam Roach a...@mozilla.com wrote:
 This is a matter for the relevant specification, not some secret cabal.

I was not proposing doing anything in secret.

I also contacted the relevant standards lists.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-27 Thread Richard Barnes

On Sep 27, 2014, at 3:02 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Sep 26, 2014 at 11:06 PM, Richard Barnes rbar...@mozilla.com wrote:
 It is not our job to break the HTTP-schemed web to force everyone to HTTPS.
 
 It is for features where it matters for end users.
 
 
 Users and web sites have been using geolocation on unauthenticated origins 
 for several years now without major implications.
 
 Citation needed.
 
 
 It's no more dangerous than me typing my address into a form.
 
 Those forms should also be behind TLS. But obviously forcing that is
 far less practical than taking steps with geolocation.

Are you making an argument more subtle than everything should be HTTPS, so we 
should make HTTP less functional?  

I don't disagree that things should be HTTPS, but breaking the HTTP-schemed web 
is not the way to get there.  That's like Verizon trying to get people to use 
their favorite video streaming site by slowing down all the others.

Since the major barrier to HTTPS deployment is the difficulty of deploying and 
maintaining it, the better strategy is to make HTTPS simpler to deploy.  Some 
of the hosting providers have been making good progress on this front.

--Richard


 
 
 -- 
 https://annevankesteren.nl/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-26 Thread Anne van Kesteren
Exposing geolocation on unauthenticated origins was a mistake. Copying
that for getUserMedia() is too. I suggest that to protect our users we
make some noise about deprecating this practice. And that in that
message we convey we plan to disable both on unauthenticated origins
once 2015 is over.

More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.

I can reach out to Google (and Apple  Microsoft I suppose, though I
haven't seen much from them on the pro-TLS front) to see if they would
be on board with this and help us spread the message.

I filed

  https://bugzilla.mozilla.org/show_bug.cgi?id=1072859

for geolocation.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-26 Thread Richard Barnes
Speaking as someone who (1) chaired the IETF working group on geolocation and 
privacy for several years, and (2) now manages PKI and crypto for Mozilla -- 
this is nonsense as stated.  It is not our job to break the HTTP-schemed web to 
force everyone to HTTPS.

Users and web sites have been using geolocation on unauthenticated origins for 
several years now without major implications.  The most common uses involve 
one-shot access to location for things like content customization.  It's no 
more dangerous than me typing my address into a form.

I could agree with Henri's suggestion in the bug that we should limit 
persistent permissions to authentication origins, as we do with gUM.  But in 
neither case have I heard any coherent rationale for disabling the features 
entirely, beyond Nobody should use HTTP anymore, which is clearly a 
non-starter.

--Richard 


On Sep 26, 2014, at 3:58 PM, Anne van Kesteren ann...@annevk.nl wrote:

 Exposing geolocation on unauthenticated origins was a mistake. Copying
 that for getUserMedia() is too. I suggest that to protect our users we
 make some noise about deprecating this practice. And that in that
 message we convey we plan to disable both on unauthenticated origins
 once 2015 is over.
 
 More immediately we should make it impossible to make persistent
 grants for these features on unauthenticated origins.
 
 I can reach out to Google (and Apple  Microsoft I suppose, though I
 haven't seen much from them on the pro-TLS front) to see if they would
 be on board with this and help us spread the message.
 
 I filed
 
  https://bugzilla.mozilla.org/show_bug.cgi?id=1072859
 
 for geolocation.
 
 
 -- 
 https://annevankesteren.nl/
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

2014-09-26 Thread Adam Roach

On 9/26/14 14:58, Anne van Kesteren wrote:

Exposing geolocation on unauthenticated origins was a mistake. Copying
that for getUserMedia() is too. I suggest that to protect our users we
make some noise about deprecating this practice.


There have already been extensive discussions on this specific topic 
within the W3C, and the conclusion that has been reached does not match 
what you are proposing. I would be extremely loathe to propose that we 
implement outside the spec on a security issue that's already received 
adequate discussion in the relevant venue.



More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.


Our implementation of getUserMedia already does this, and the 
getUserMedia spec has RFC 2119 MUST strength language requiring such 
behavior.



I can reach out to Google (and Apple  Microsoft I suppose, though I
haven't seen much from them on the pro-TLS front) to see if they would
be on board with this and help us spread the message.



The email address you're looking for is public-media-capt...@w3.org. 
This is a matter for the relevant specification, not some secret cabal.



--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform