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

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