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

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

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 10 Jan 2014 11:59:46 -0500
Message-ID: <52D02702.4030908@bbs.darktech.org>
To: public-webrtc@w3.org
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 <mailto: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 <mailto: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 17:00:21 UTC

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