- From: Steve Kann <stevek@stevek.com>
- Date: Wed, 27 Nov 2013 15:45:08 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: cowwoc <cowwoc@bbs.darktech.org>, Justin Uberti <juberti@google.com>, Lorenzo Miniero <lorenzo@meetecho.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CEBBBC1F.4B1DF%stevek@stevek.com>
On 11/27/13, 2:41 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote: > On 27 November 2013 10:38, Steve Kann <stevek@stevek.com> wrote: >> After reading through some more of this thread, allowing remote keyboard >> mouse events doesnıt actually seem that much more dangerous than allowing an >> app which can view the screen to also be able to operate the browser (the >> case of navigating to the bank, and capturing the display). > > If you believe that, I don't really know what I can say to convince > you otherwise. I don't know how I can prevent an app with remote > control privileges from - for example - deleting all my files. Or > looking at them, or modifying them. (That includes my SSH private > key, my tax files, my password safe, you name it). I think that I can > prevent an app from accessing sudo-protected administration functions. > Maybe. But that's not much consolation. In a world where so many of peopleıs valuable information is available and controllable through the web, doesnıt the fact that I can see and control your browser already provide a pathway to deleting all of my google docs, viewing my bank records, or accessing my corporate intranet? > > I won't say categorically that I won't be supportive of remote control > functions, but until someone presents a MUCH stronger set of > safeguards, I do not believe that user consent is sufficient > protection. You are going to need to do a lot better than entreaties > to "think of the poor application designer". In order for this to be ³safe², the user needs to trust: 1. The application they are using: Consider they are using a web conferencing application provided by their school or place of business. 2. The user to whom they are granting control: Consider that they are granting control to their instructor, or to a trusted colleague. I agree there are not many effective safeguards which would make this a good idea unless you trusted those two entities. Some things that seem necessary and prudent (though perhaps not sufficient are): 1. Good mechanisms for consent: Youıd want to make sure you are clear about the level of access being provided, and to whom (probably could only best describe the application here, the application could present the actor, though youıd need to trust it). 2. Some mechanisms to prevent ³fighting² ‹ typically youıd suppress remote event input when local event input is detected. In other words, you would suppress remote mouse-move events when you detect a local mouse movement, and same for keyboard events. 3. Good UX to indicate this mechanism is active and remains active, so you donıt leave it on past the time you expect it to be used. Non-web applications have been providing this functionality for eons, and have demonstrated the demand for it. What unaddressable security risk are we adding here that Lync does not suffer from because of the same feature? -SteveK
Received on Wednesday, 27 November 2013 20:45:45 UTC