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

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

From: Roman Shpount <roman@telurix.com>
Date: Fri, 10 Jan 2014 13:56:37 -0500
Message-ID: <CAD5OKxsTO3wwVSOUVnQ67KN1otS8gcGbyq8v-0uS5fFqQcBWVA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Agree completely!

Roman Shpount

On Fri, Jan 10, 2014 at 11:59 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Same.
> Gili
> On 10/01/2014 2:51 AM, Simon Pietro Romano wrote:
> A HUGE +1 to this e-mail, in its entirety.
>  Cheers,
>  Simon
>  Il giorno 10/gen/2014, alle ore 02:22, Alexandre GOUAILLARD ha scritto:
>  in total (and brutal) honesty,
>  1. Users are doing it today. They would not understand not to be able to
> use it. If webrtc does not provide it, application vendors will, one way or
> another. They are doing it already!
>  2. Discussion about user knowing or not are to protect us, not them.
> It's a little bit like democracy and voting (especially for MTI codecs :D
> ): do you prevent people that you perceived as stupid, or misinformed, or
> just plain wrong to vote? No, you assume they are adults and they know what
> they are doing. The best you can do is to make sure, as much as possible
> that they know. If they don't know and don't believe they won't care
> anyway, if they know and care, they might appreciate your effort to protect
> them, but most likely they will feel patronized. It feels a little bit like
> DRM protection for games: a solution that does not prevent bad things from
> happening, but prevent some rightful users to use the software (i.e. a
> lose-lose situation). Wait for the first plugin that propose that, and see
> how popular it will be.
>  4. Our point of view (and it might not be shared by other, but I think
> it's important to state it so it appears that feedback from dev and real
> world are expressed and read) is that if you need a plugin for anything
> else than a temporary situation where a feature is not yet implemented,
> then the standardization process as failed, and/or the pledge of webrtc is
> dead. After all, almost everything that webrtc propose in term of feature
> (gross exaggeration, but stay with me here), was from most of the user
> perspective, already available with flash/java, so it's plugin for plugin.
>  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 get the feeling that we have been stuck at  the above three points for
> one year now, and I m reaching the point where I will have to put it in a
> plug in, and I hate it with passion. I also hate the idea of realizing that
> the other companies that took flash back end and disguise them as webrtc,
> and/or made plugins, not following the webrtc promise, are not cynical but
> simply practical.
>  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.
>  alex, in grumpy mode.
> On Fri, Jan 10, 2014 at 7:28 AM, Randell Jesup <randell-ietf@jesup.org>wrote:
>> On 1/9/2014 12:39 AM, cowwoc wrote:
>>> Okay, so here is my second attempt at this:
>>> We should be able to share any part of the display that the application
>>> does not control. Meaning, the webapp might allow users to share the
>>> contents of Excel so long as it has no control over what gets displayed by
>>> Excel. Similarly, it should be allowed to share any browser tab so long as
>>> it plays within its own host/origin.
>>> Assuming that co-browsing is a non-goal for now, is the above (read-only
>>> screen sharing) safe from a security point of view?
>>  There are security issues even for read-only sharing.
>> If the application can control an iframe in the shared tab/window, it
>> could flick up images of private data it normally couldn't access (even via
>> writing to a canvas) due to cross-origin restrictions. Data such as bank
>> accounts, private user pages, etc.
>> If it also has access to the camera, it could even wait until you (and
>> the other person) weren't looking.
>> Effectively, the level of risk involved is somewhere between granting
>> camera access (which risks privacy, but not online/monetary data) and a
>> full native desktop install (often used for screen sharing) or a plugin
>> (both of which in theory can have access to the entire PC).  A security
>> level roughly equivalent to a desktop install (or plugin install) is
>> relatively safe, though users may not be as knowledgeable of the risks of
>> plugin installs as they are of desktop installs.  It is unusual and thus
>> will tend to trigger some level of concern.
>> Manually whitelisting sites/apps you trust to ask for screensharing is
>> possible also; the downside might be that users would not understand the
>> risks; the upside would be that you could tailor warnings (which we all
>> know users read religiously and understand totally!)
>> --
>> Randell Jesup -- rjesup a t mozilla d o t com
>                                 _\\|//_
>                                   ( O-O )
>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                      Simon Pietro Romano
>                Universita' di Napoli Federico II
>                       Computer Engineering Department
>               Phone: +39 081 7683823 -- Fax: +39 081 7683816
>                                            e-mail: spromano@unina.it
>      <<Molti mi dicono che lo scoraggiamento  l'alibi degli
>      idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                                      oooO
>   ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                   \ (            (   )
>                                    \_)          ) /
>                                                                        (_/
Received on Friday, 10 January 2014 18:57:11 UTC

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