Re: Why does screen sharing require a browser extension?

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