permissions and security

[guy paskar]

Hi all ,
i realized that it is not yet decided what will be the permission
behavior.
when will it be known? where can i find the latest info about it?
i'm looking to know specifically if there will be needed a permission
to use the data channel and not for usage of camera or audio channels.

Thanks

[Hadar Weiss]

In the IETF RTCWEB working group draft about security (http://
tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01) it is written:

   Clients MAY permit the formation of data channels without any
direct
   user approval.  Because sites can always tunnel data through the
   server, further restrictions on the data channel do not provide any
   additional security.

Do the upcoming browser implementations conform with this decision? I
don't know...
Maybe people from Chromium and Mozilla (and Microsoft too?) can
elaborate about their Data Channel API developments?
And moreover, when it is expected to be released...

Regards,
Hadar

[guy paskar]

Can anyone confirm that? will application not need to get specific user approval for data channel?

Thanks

[Harald Alvestrand]

So far, no browser has implemented the data channel.
So far, I have not heard anyone in the WGs wanting to do browser
chrome UI for permitting data connections.

Note: You need no user permission to set up a PeerConnection either.
Just for the mic and camera.

[Ivan Vučica]

Harald,

No permission will be required for PeerConnection nor data connections? Is that a good idea?

I can't think of a good reason why user would want to block it (since browser can already grab camera image via canvas and send it via XMLHttpRequest, for example), but just because I can't think of an abusive way to use it that isn't possible via XMLHttpRequest doesn't mean someone else can't find an abusive way to use PeerConnection.

I'm just wondering.

--
Ivan Vučica - iv...@vucica.net

[Justin Uberti]

Being able to set up a data connection without an infobar seems very useful, and so far we also haven't been able to discover a specific problem with this approach, so this is the current plan. Things may of course change once we actually have an implementation of data channels!

[Ivan Vučica]

Hi Justin,

One problem has only just now crossed my mind. Traffic constraints.

I like being able to block as many connections as possible when I'm connected via cell phone, via which the traffic is expensive. This includes turning off images, styles, et al. If pages started establishing additional data connections behind my back, I wouldn't be happy.

Perhaps info bar isn't required for WebRTC-aware users. But as it'll be a new feature to many users, some of them may grow angry that a subset of pages is permitted to generate unnecessary data traffic even if they blocked images, stylesheets, video, audio and plugins.

And it'll grow harder to inspect what traffic web pages are generating.

Whether or not this subset of users is significant enough to warrant worrying about them, that's another thing. But I don't think bringing this to your attention can be a bad idea.

[Timothy B. Terriberry]

Ivan Vučica wrote:
> Perhaps info bar isn't required for WebRTC-aware users. But as it'll be
> a new feature to many users, some of them may grow angry that a subset
> of pages is permitted to generate unnecessary data traffic even if they
> blocked images, stylesheets, video, audio and plugins.

How does this differ from XmlHttpRequest, hanging GETs, etc.?

[Bob Wolff]

I have to agree with Tim here. The real issue here is NOT that there may be more traffic generated. That's an issue that grows every day in every way regardless of a Peer-based data connection feature. 

The real issue here, if there is an issue at all, is that this new connection type is not client/server based but peer-based and as such there may be issues of security involved. By this, I mean that from my vantage-point servers are (generally) considered places which will not attack me. I realize this is not 100% true but our anti-virus products aid in this regard... while a peer-connection would have a zero trust factor in my eyes. If there's a peer-data issue, I believe it is here. I don't think the additional data argument is one that we need to deal with - that issue would be more likely dealt with by other products that allow users to configure their browsers to minimize data transfer in manners that you outlined and this would be a new one of those mechanisms to control/configure.

Bob Wolff

[Justin Uberti]

Web applications are the only things that can create p2p channels. If you trust the server to serve you a benign web application, why would this change if the web app can talk to another instance of itself via p2p instead of XHR? 

Antivirus products may be able to do some inspection of XHRs sent over HTTP, but if the content is HTTPS, I think the situation is no different than for p2p.

[Bob Wolff]

On this particular item, it's a matter of who's supposed to trust whom. (Did I do that English gig right there? :-)  When I'm connecting to the server, I may trust the server to send me a benign app. However, given that the browser / Javascript environment is a non-secure arena, how can I trust that another person who has downloaded the same web app hasn't modified it on his end to do malicious things once we get a p2p connection rolling?

bob

[Timothy B. Terriberry]

Bob Wolff <bob.w...@gmail.com> wrote:
> server, I may trust the server to send me a benign app. However, given that
> the browser / Javascript environment is a non-secure arena, how can I trust
> that another person who has downloaded the same web app hasn't modified it
> on his end to do malicious things once we get a p2p connection rolling?

You can't. But if your webserver is set up to relay messages between
two different users, you have the same issue as if they were going
directly p2p.