- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 25 Nov 2013 15:39:28 -0500
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CABcZeBPJSThgU1f+R3UOkCdjy=RBgkLjQYyNs2oXWKE1Ak02pg@mail.gmail.com>
On Mon, Nov 25, 2013 at 3:05 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > On 25/11/2013 3:02 PM, Martin Thomson wrote: > >> On 25 November 2013 11:44, cowwoc <cowwoc@bbs.darktech.org> wrote: >> >>> 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. >>> >> Since showing a whole site, one of the components of which is cross-site objects is one of the major uses for screen sharing, that's going to make it significantly less useful. Moving this into an extension doesn't really solve the problem. >>> >> That is incorrect. Confidential information isn't just restricted to >> stuff that is shown when you are logged in. >> > > Please provide an example SiteKey. More importantly, I don't really understand what you mean by "do not require user interaction". I'm currently logged into GMail for instance and opening a new GMail link wouldn't require a new user interaction. -Ekr > > And, this presupposes >> that you don't have concurrent uses of sites where you can be screen >> sharing in one and in a private/sensitive session in another. >> > > As I mentioned in a separate thread, you can make this obvious by flashing > the border of the area being captured. This is similar to webcams lighting > up when they're on. There is no way a user would miss that visual queue. > Take a look at http://www.oracle.com/technetwork/articles/javase/ > appletwarning-135102.html > > > 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. >>> >> I might disagree with Justin (might) about the level of protection >> that is afforded the user by the "install" process. That is true. >> TLS doesn't help you here. >> > > TLS alone would not, but TLS with Chrome App Store would. I'm saying that > when a user hits a website that uses screen capturing, Chrome should check > whether its TLS certificate has been approved in Chrome App store. If not, > it should deny access. This gives you all the power of App Store (approval > process, banning, etc) without the user needing to download an explicit > plugin. > > Gili > >
Received on Monday, 25 November 2013 20:40:36 UTC