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

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 16:38:13 UTC