W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: What is missing for building "real" services?

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 13 Jan 2014 11:40:38 +1100
Message-ID: <CAHp8n2kO4A6y389FyF4o68dWNTMjWMbb=bWWv3zyDSCB1B4AeQ@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: public-webrtc <public-webrtc@w3.org>, Alexandre Gouaillard <agouaillard@gmail.com>, Randell Jesup <randell-ietf@jesup.org>
On Mon, Jan 13, 2014 at 9:19 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> On 1/10/14 7:22 PM, Silvia Pfeiffer wrote:
>
> On 11 Jan 2014 06:55, "Jan-Ivar Bruaroey" <jib@mozilla.com> wrote:
>>
>> On 1/9/14 8:22 PM, Alexandre GOUAILLARD wrote:
>>>
>>> 3. See this entire e-mail as an expression of my frustration:
>>> - yes, everybody agrees it s important
>>> - yes, chrome as *an* implementation
>>> - yes, we all agree it's sensitive, and there are a lot of identified
>>> scenarii where things would go wrong.
>>> but can we for the love of all the good things out there, not stay stuck
>>> at the above three lines and come up with something, anything, that enable
>>> it without a plugin or an extension (but with care and with some fences
>>> around it to prevent).[...]
>>>
>>>
>>> I certainly don't know enough about the subject even though I read all
>>> the cited draft, specs and related discussion online, and I don;t have the
>>> experience that some (most) of you guys here have. But It does not mean I
>>> don't have a point. I also do not pretend to know enough, and I would have
>>> no problem joining any kind of informal task force including chrome and
>>> mozilla people, at anytime of the day or night (I'm 15 hours away from
>>> pacific time) and try super hard to understand all aspects, if such a task
>>> force was set up with the will to find a way to make it happen. I can even
>>> code parts and/or dedicate staff to this. I just would like to see something
>>> coming else than making a plugin.
>>
>>
>> This is the task force. The place to solve this is here.
>>
>> It's not that hard to understand:
>>
>> A webpage today is allowed to manipulate content it cannot see. It can
>> make your bank-account page dance across your screen, but it cannot see it.
>> Screengrabbing is like giving it a mirror. With that mirror, it can target
>> and grab all your online information in a flickeringly short second. Explain
>> that to people.
>
> What happened to the idea of blacking out all tabs that don't have an
> explicit permission set, e.g. something like a meets tag of
> "screensharing=allow"? I thought that would mediate this issue.
>
>
> If it defaulted to "screensharing=disallow" then I would agree.

Yes, indeed. I thought that "disallow" would be the default if the
meta tag is not available.

> But I like
> the idea. Is there no existing "possibly sensitive information" tag or
> formula we could key off of for a better default?

Screensharing is a new feature of Websites, so I don't think you will
find something like it.

> A whitelist of bank sites?

Wouldn't bank sites always need to be "blacklisted" (i.e.: don't show
their content)?

It's possible we could add  to the default disallow a separate
mechanism of providing whitelists. Though I think that would be very
much user specific. For example, if I am a client of a bank and am
actually talking to the bank's IT support and trying to debug an error
that I'm seeing on their website. Maybe there is a means that we could
come up with that the bank could allow to set a temporary token for
the user to be allowed to see it. Hmm... come to think of it: if they
knew who was logging in, they could temporarliy add the <meta> tag to
the logged in user's page and thus allow him/her to do screensharing.
So, that would already be possible.

So, the concrete proposal as I heard it before and liked it was for
the browser to only display web page content to screensharing web apps
when the web page has a <meta name="screensharing" content="allow"/>
in it. What would be the issue with such an approach?

Cheers,
Silvia.
Received on Monday, 13 January 2014 00:41:26 UTC

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