Re: Why does screen sharing require a browser extension?

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
browser.