- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Mon, 25 Nov 2013 14:44:42 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi Martin, On 25/11/2013 1:14 PM, Martin Thomson wrote: > On 25 November 2013 08:56, cowwoc <cowwoc@bbs.darktech.org> wrote: >> One thing I didn't understand (and was not explained) is why screen sharing >> is substantially more security-sensitive than webcam sharing? I get the fact >> that someone could use screen sharing to snoop on my banking activity, but >> how is this any more security sensitive than knowing what I look like and >> where I live? If the security dialog is good enough for webcam sharing, why >> is it not good enough for screen sharing? > The difference between screen sharing and media is largely in the way > that users comprehend the security issues. It's relatively easy to > understand what sharing your image or voice is going to do. Most > people just get it straight away: "share the camera? yes/no" is a > pretty easy thing to understand. > > Screen sharing seems obvious, but it is far from it. Sharing what you > can see might seem safe, but when a site has the ability to frame in > content, capture it, then hide the frame, all without you noticing, > the secrets that they can steal are many. Take the cross-site request > forgery tokens that many sites with strong security requirements put > in HTML (the target of BREACH attacks), adding an iframe with > view-source:https://... that briefly shows this would allow sites to > hijack sessions. Add eye tracking from your camera, and your chance > of noticing the attack approaches zero. The only way I can see this happening is for secure websites that do not require user interaction (meaning, you checked "automatically log me in from this computer"). So yes, in such a case I definitely see a security risk but that brings up the question: why not just target the intersection of screen capturing, iframes and cross-site requests? Screen capturing should not be allowed to capture hidden elements, or the contents of cross-site requests. Moving this into an extension doesn't really solve the problem. > You are not the only person to have asked this question, which makes > it obvious to me that asking users would be hugely irresponsible. The > choice that Justin is making is a step in the right direction, but I > still believe it to be insufficient. > >> And finally, couldn't you simply require the use of SSL for this feature and >> then ban malicious applications based on their certificate? > How exactly were you going to identify an application as malicious? > After they steal someone's life savings? Keep in mind that it's only > the matter of milliseconds to stand up a new site with a new > certificate. This contradicts Justin's argument as I understood it. He stated that by moving the code from JS into a browser extension Google could ban malicious apps as they are found. I don't see the difference between enforcing bans by way of extensions or by way of having developer asking the app store to approve their application (point to an external address + SSL certificate) and then if the application is found to be malicious simply ban all apps associated with the SSL certificate. This way Google still gets to review apps, ban the ones that are malicious, and users don't need to go through the hassle of installing a plugin. Gili
Received on Monday, 25 November 2013 19:45:42 UTC