- From: Justin Uberti <juberti@google.com>
- Date: Tue, 26 Nov 2013 08:50:26 -0800
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-3FaAKdgQTseye=y-27W_7=N0c1vi6Qi4b=HgXQQ1wY=A@mail.gmail.com>
On Tue, Nov 26, 2013 at 12:09 AM, cowwoc <cowwoc@bbs.darktech.org> wrote: > Hi Justin, > > > On 25/11/2013 6:58 PM, Justin Uberti wrote: > > Others have already made the points I was going to, but I'll summarize: > - Screensharing is more dangerous than webcam access, because the attacker > can record the screen, AND control what is displayed on it. > > > Agreed but only if you interpret screen-sharing as co-browsing. It is > possible to limit screen-sharing to read-only screen recording, without the > ability to control what is being displayed on it, in which case none of > these security concerns exist. > There is no such thing as read-only screen recording in a JS app (as mentioned by myself and others). > > > - It only takes one frame to capture sensitive information - far less > than would be noticeable by a user. > > > Agreed. > > > - Requiring unambiguous opt-in for sharing, and being able to remotely > disable bad actors, are therefore the best hope of security. > > > I think that is a bit of a cop-out. It reminds me of Windows XP asking you > "Are you sure you want to open this file?" implying that the user knows > more than the browser whether the file can be trusted. In 99% of cases, > they do not. The sounds like a "cover your ass" question so we can later > tell the user "Well... I warned you. You have no one to blame but > yourself." No wonder no one pays attention to these warnings. I think we > can do better (more on this below). > > > - To opt in, the user will need to install an app or extension, and when > actually sharing, select the window/desktop to be shared from a consent box. > > > We should present a consent box and ask which window/desktop to be shared > every time the app is opened, not just the first time the app is installed > (unless the user asks us to remember his preferences). > Yes, this is what I was proposing. The app install requires an additional explicit step, but each sharing operation will require the user to select which window or desktop they want to share. > > > - Installing through an app store is an explicit grant of trust by the > user to the application (similar to installing a desktop app). Visiting a > web page is not. > > > I disagree. Allow me to explain why I believe this security model (which > is used by Android) is broken. > > I install an app and get asked whether it should be able to access my > contacts, use the camera and empty my bank account. 99% of the time, I have > no idea why the application needs these permissions but I proceed anyway > because I want to try the application. I believe you'd end up with a far > better permission situation if you presented the consent box immediately > before the permission was needed. Meaning, if the app asked to access my > contact list immediately after I asked it to share a picture with my > friends, I'd understand why. Asking me during installation time does not > provide me with the necessary context to make a decision and results in me > forgetting that I ever granted permission in the first place because I only > got asked once. > > You should be asking me every time the app required a permission, not just > once (unless I ask you to remember the choice) and you should do so right > before you need a permission, not all up-front. > > None of this is specific to an extension versus a web page, but I believe > the latter is a better fit (no need to install a plugin). > > By the way, I fail to see why you couldn't present a consent box the first > time I visit a web page. Java does this the first time you launch an applet > off a website. Why couldn't Chrome do the same for embedded WebRTC > applications? You could present the exact same permissions dialog you get > on app store. None of this depends on the use of browser extensions. > I think you are attacking a strawman. If you re-read my point above, I am suggesting the use of both an app install mechanism AND consent grant by the user for every sharing request. > > Gili > > > > > On Mon, Nov 25, 2013 at 12:23 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > >> On 25/11/2013 3:20 PM, Martin Thomson wrote: >> >>> On 25 November 2013 12:13, cowwoc <cowwoc@bbs.darktech.org> wrote: >>> >>>> Pick colors which no one is color-blind to. >>>> Your friend *saw* the border, he just didn't know what it meant. I am >>>> willing to bet that if it pulsed, he'd definitely see it. >>>> If you add the alert icon with the tooltip as Java did, there would be >>>> no >>>> confusion as to the meaning of the border. I've used this feature live >>>> and I >>>> can tell you it was very easy to understand. >>>> >>> I'm fairly certain that doesn't work either. The problem, of which I >>> provided a specific example, is something that I will call "chrome >>> blindness". Users don't notice this stuff. Despite 15+ years of >>> training, the lock icon still doesn't work as advertised. >>> >> >> But the border is flashing! :) Anyway, I'd argue an extension is even >> worse. You install it once and forget what it is actively recording. It >> might not be malicious but you could still mistakenly share some pretty >> embarrassing stuff. >> >> >> How does requiring each app to publish a separate extension on Chrome >>>> Store >>>> scale any better? >>>> >>> Justin's example might scale, depending on how app stores are managed. >>> >> >> I don't get it then. What did you mean by "it doesn't scale" with >> respect to having the AppStore approve/ban SSL certificates associated with >> apps? After all, the way apps are approved in the first place is by signing >> them and approving the certificate. So how is this any different? This is >> just an AppStore where the user does not need to explicitly install an app. >> All other steps remains identical. >> >> Gili >> >> > >
Received on Tuesday, 26 November 2013 16:51:13 UTC