Data channels are modeled on web sockets, and I see we do this for web
sockets. https://bugzil.la/692067
However, data channels are typically opened to other *clients*, not servers.
What would the ContentLocation URI be in this case? The (dynamic) IP
used to reach the other client?
This seems easily circumvented by routing data through another client
that doesn't use content policy.
.: Jan-Ivar :.
On 6/17/16 10:28 AM, Paul Ellenbogen wrote:
At the moment, WebRTC does not check if connections are okay by content
policies
<https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy>
.
WebRTC data channels as a side channel around content policy has potential
for abuse. For example, ad blockers use content policy to block ads, so
advertisers may be able to load their ads on a page using data channels
where the traditional methods would be blocked.
Two possible solutions other than checking WebRTC connections against
content policies exist:
- Require a doorhanger prompt for all data channel connections.
- Require ad blockers and other extension developers to create a wrapper
around PeerConnection or RTCDataChannel. This is what uBlock Origin does
on chrome <https://github.com/gorhill/uBO-WebSocket> for WebSockets.
Are there opinions or thoughts on the pros/cons of including WebRTC
connections in content policies?
Paul Ellenbogen
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
