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
