On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: >> 2) If the only common real-world MITM threat is via a compromise >> adjacent to the client (e.g., wireless), there's no reason to restrict >> geolocation, because the attacker already knows the user's location >> fairly precisely. > > > I don't think that is the only common real-world attack. Other types > include your traffic being intercepted by your ISP, and/or your government.
I guess it's hard to say how common those are in practice, or how much of a concern they are. I agree that for an API that allows taking pictures without the user's case-by-case permission, it would pay to err far on the safe side. I'm actually rather disturbed that such an API even exists. Even if the site is HTTPS, it could be hacked, or it could be spoofed, or the operators could just be abusive. Every site must be assumed possibly malicious, no matter how many permissions dialogs the user clicks through, and HTTPS can be assumed to be only modestly safer than HTTP. Why isn't the user prompted before every picture is taken? Is there really a use-case for allowing a site to take pictures without the user's case-by-case permission that outweighs the privacy issues? As for geolocation, I'm still not convinced that it's worth worrying about here. The ISP and government probably have better ways of tracking down the user's location. The ISP generally knows where the Internet connection goes regardless, and the government can probably get the info from the ISP (after all, it was able to install a MITM). > There have been documented cases of webcam spying victims committing > suicide. And I wouldn't be surprised if there are or will be businesses > based on selling people's webcam feeds. Protecting people's physical > privacy is just as important as protecting their digital privacy. Then why only focus on attacks that are foiled by HTTPS? We should be equally concerned with attacks that HTTPS doesn't prevent, which I think are probably much more common. On Thu, Mar 12, 2015 at 5:24 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > The attack scenario I'm thinking is: > > 1) User loads http://a.com > 2) Attacker immediately sets location to http://b.com > 3) Attacker's hacked-up b.com goes fullscreen, pretending to still be a.com > to the user by spoofing browser chrome, while also turning on the camera > because the user granted permission to b.com to do that at some point. How about: 1) User loads http://a.com 2) Attacker opens a background tab and navigates it to http://b.com (I can't think of a JavaScript way to do this, but if there isn't one, making a big <a href="b.com" target=_blank> that covers the whole page would work well enough) 3) http://b.com loads in 10 ms because it's really being served by the MITM, uses the permission, and closes itself _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
