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