|permissions and security||guy paskar||3/28/12 6:13 AM|
Hi all ,
i realized that it is not yet decided what will be the permission
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.
|Re: permissions and security||Hadar Weiss||3/28/12 4:06 PM|
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
user approval. Because sites can always tunnel data through the
server, further restrictions on the data channel do not provide any
Do the upcoming browser implementations conform with this decision? I
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...
|Re: permissions and security||guy paskar||5/6/12 6:59 AM|
Can anyone confirm that? will application not need to get specific user approval for data channel?
|Re: [discuss-webrtc] Re: permissions and security||Harald Alvestrand||5/6/12 12:21 PM|
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.
|Re: [discuss-webrtc] Re: permissions and security||Ivan Vučica||5/8/12 4:06 AM|
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
|Re: [discuss-webrtc] Re: permissions and security||Justin Uberti||5/8/12 8:58 AM|
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!
|Re: [discuss-webrtc] Re: permissions and security||Ivan Vučica||5/9/12 11:01 AM|
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.
|Re: [discuss-webrtc] Re: permissions and security||Timothy B. Terriberry||5/9/12 11:06 AM|
Ivan Vučica wrote:How does this differ from XmlHttpRequest, hanging GETs, etc.?
|Re: [discuss-webrtc] Re: permissions and security||Bob Wolff||5/9/12 11:39 AM|
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.
|Re: [discuss-webrtc] Re: permissions and security||Justin Uberti||5/9/12 1:20 PM|
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.
|Re: [discuss-webrtc] Re: permissions and security||Bob Wolff||5/9/12 1:28 PM|
|Re: [discuss-webrtc] Re: permissions and security||Timothy B. Terriberry||5/9/12 1:57 PM|
Bob Wolff <bob.w...@gmail.com> wrote: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