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

Re: Why does screen sharing require a browser extension?

From: Steve Kann <stevek@stevek.com>
Date: Tue, 26 Nov 2013 21:58:42 -0500
To: Martin Thomson <martin.thomson@gmail.com>
CC: Justin Uberti <juberti@google.com>, cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <CEBAC733.4AEB8%steve.kann@blackboard.com>

From:  Martin Thomson <martin.thomson@gmail.com>
> On 26 November 2013 16:48, Steve Kann <stevek@stevek.com> wrote:
>>  This approach would require developers to build, register, and maintain apps
>>  for Chrome, Safari, IE, Firefox, as well as separate developer credentials,
>>  etc.
> I don't believe that to be the case.  If I understand Justin's
> proposal correctly, Google would provide the code for the Chrome app,
> already built and maintained.  Application developers would simply
> need to register and redistribute this under their own livery.  This
> works for Chrome, and others could deploy the same model (Firefox has
> a similar system), others might need a completely different approach
> (IE, mobile Safari, etc...).
> I agree that this sucks for application developers, but it's early
> days yet.  We've only just started talking about screen capture
> seriously.  At this early stage, I respect Justin's desire to be
> conservative in favour of his users.

I seem to be missing the distinction here, because first you wrote that you
ŗdonšt believe that to be the case˛, and then described the situation
largely as I had described. The point I was trying to make is that we are
saying here that, before we allow a webrtc application to capture the
screen, that we want a few preconditions to be met:
1. We want the user to give informed consent.
2. We want some entities (perhaps browser vendors), to have some curatorial
discretion to blacklist applications
3. (in other threads):  We want to provide certain websites the ability to
declare their content un-capturable.
My point here is that we should figure out how to make these things happen
without needing to provide a different magic incantation and registration
process for each platform we want to do this on.   Išm not even sure if
therešs a standards issue here, but couldnšt this be met by simply having
well designed consent mechanisms (Justin had described something that seemed
fairly robust), along with a browser policy to only permit sites coming from
https servers, as well as a browser-vendor-maintained blacklist?

Doing it in this app way, seems to negate a key benefit of standardization ‹
effectively taking this key capability out of the standard because you
cannot use it without submitting to a separate proprietary process per
Received on Wednesday, 27 November 2013 07:09:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:52 UTC