W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Re: Why does screen sharing require a browser extension?

From: Justin Uberti <juberti@google.com>
Date: Tue, 26 Nov 2013 08:50:26 -0800
Message-ID: <CAOJ7v-3FaAKdgQTseye=y-27W_7=N0c1vi6Qi4b=HgXQQ1wY=A@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC