- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Tue, 26 Nov 2013 03:09:33 -0500
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <5294573D.4000603@bbs.darktech.org>
Eric, You bring up some very good points, but I'm going to respond to Justin's post because it contains similar elements with more detail. Gili On 25/11/2013 3:39 PM, Eric Rescorla wrote: > > > > On Mon, Nov 25, 2013 at 3:05 PM, cowwoc <cowwoc@bbs.darktech.org > <mailto: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 > <mailto: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 Tuesday, 26 November 2013 08:10:34 UTC