On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla <e...@rtfm.com> wrote: > Let's consider a different example than the one you propose: access > to the camera and microphone via getUserMedia(). Say that a site > adds a feature which lets you take a picture of yourself for your > avatar (come to think of it, I wish github did this). If the permissions > are persistent, then the site (or if HTTPS isn't used, any network > attacker) can access my camera and see what's going on in my > room at any time [0] and largely without my knowledge. > By contrast, if I need to click OK in order to give a remote site access > to my camera (even if I generally do consent without much thought) > this makes the attack much more difficult to mount.
So the mitigation applies when: 1) Some users have already persisted the permission for the site. 2) The site asks for the permission either predictably or infrequently enough that the user is not conditioned to just click "yes" every time anyway. A limitation on the mitigation is that if the site asks for the permission during regular use, the attacker could just make sure that their permissions request appears at that time, and the user would click "yes" because they expect the request at that time anyway. However, this would require the attacker to do some more work, and would only work some of the time (if the site is expected to ask for the permission during the MITM'd session). The disadvantage is that non-secured sites that depend heavily on any of these permissions would get more annoying to use. "Switch to HTTPS" is not a reasonable solution. This could be helped by allowing the user to give permission for the session, but that would also reduce the effectiveness of the mitigation. Another point to make is that whenever the site actually requests the info legitimately (takes a picture, gets geolocation info, etc.), even a passive MITM could steal the info anyway. Also, if the major real-world MITM we're talking about is someone intercepting a non-secured wireless network, the attacker already has physical proximity, so he a) knows approximate geolocation info and b) could possibly take a picture by more conventional means. If I understand correctly, I am not at all sure that the increased user annoyance is worth the increased protection of user privacy. These permissions can always get abused anyway by someone hacking the site the user has given permission to, and in my experience that's considerably more common than a MITM attack, so users can't really depend on the permissions not being abused anyway. The incremental reduction of attack surface doesn't seem to gain us a lot. I definitely think that there is no basis at all for disabling pop-up permissions or other things that only affect user convenience. Just because there's an MITM doesn't mean it warrants being treated as a security issue -- it's a tradeoff of user convenience vs. user convenience, and it's obvious that user convenience is better served by allowing the pop-up permission to be remembered. Privacy vs. convenience is a less obvious tradeoff to make. (By the way, I'm very alarmed by your implication that a site with persisted camera permissions can take pictures whenever it wants. All it would take is one reasonably large site getting hacked, and tens of thousands of people could receive "Give me $100 or I'll post pictures of you in your underwear all over the Internet" threats. I'm much more worried about server-side hacking or abuse than MITM. I've had sites I subscribe to hacked multiple times, and one time a site I ran. I don't think I've even been subject to a real MITM attack.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
