WebRTC connections do not trigger content policies. Should they?

[Paul Ellenbogen]

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

[Jan-Ivar Bruaroey]

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 :.

[Paul Ellenbogen]

On Fri, Jun 17, 2016 at 6:43 PM, Jan-Ivar Bruaroey <j...@mozilla.com> wrote:

> 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.
>

While WebRTC is typically used to connect between clients, this is by no
means necessary. My understanding is that anyone can set up a server that
accepts WebRTC data channel connections.

>
> What would the ContentLocation URI be in this case? The (dynamic) IP used
> to reach the other client?
>

I think it would IP addresses be in most cases, unless ice candidates can
be urls too.

>
> This seems easily circumvented by routing data through another client that
> doesn't use content policy.

In the advertising example, this means an advertiser would have to push
this new IP to ALL publishers on their platform. In the example I proposed,
the advantage to publishers is that they only need to paste in a snippet of
javascript with hard coded ICE candidates. This means they don't require
anything sophisticated on the backend to serve ads.

Using dynamic IPs means that publishers would need to A) regularly paste in
a new version of the advertising code or B) set up a backend to fetch those
IPs regularly and update the hard coded values. Either of those are much
more complicated for the publisher when compared to just pasting in
javascript.

[Eric Rescorla]

The priority of this proposed feature seems to depend rather a lot on
whether enough
advertisers are using WebRTC to deliver ads to make it worth some ad
blocker being
interest in adding such a blocker. Do we have any evidence on this front?

It's worth noting that from a security and tracking perspective, ads
delivered via this
mechanism look a lot more like first party ads (they are in the origin of
the main
page and do not get cookies from the advertiser's origin). So, in that
respect all
you're really doing is making it possible for the advertiser to send the
data directly
to the user rather than tunnelling it through the publisher. That's
potentially of some
value, but perhaps not an enormous amount.

As a thought experiment, consider an ad serving design in which publishers
include
ad content as they do now but instead of having it sourced from the
advertiser's
origin, they instead stand up "<random-value>.publisher.example.com" and
point
it at the advertiser's IP addresses (via an A record to the advertiser's
name never
appears). This would have a similar cost/effort structure to using data
channels and
would similarly not be blocked by current domain-based ad blockers. What
would our
expectations be here?

-Ekr


On Sat, Jun 18, 2016 at 10:50 AM, Paul Ellenbogen <pelle...@mozilla.com>
wrote:

> On Fri, Jun 17, 2016 at 6:43 PM, Jan-Ivar Bruaroey <j...@mozilla.com>
> wrote:
>

> > 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.
> >
>

> While WebRTC is typically used to connect between clients, this is by no
> means necessary. My understanding is that anyone can set up a server that
> accepts WebRTC data channel connections.
>
>
> >

> > What would the ContentLocation URI be in this case? The (dynamic) IP used
> > to reach the other client?
> >
>

> I think it would IP addresses be in most cases, unless ice candidates can
> be urls too.
>
> >

> > This seems easily circumvented by routing data through another client
> that
> > doesn't use content policy.
>
>

> In the advertising example, this means an advertiser would have to push
> this new IP to ALL publishers on their platform. In the example I proposed,
> the advantage to publishers is that they only need to paste in a snippet of
> javascript with hard coded ICE candidates. This means they don't require
> anything sophisticated on the backend to serve ads.
>
> Using dynamic IPs means that publishers would need to A) regularly paste in
> a new version of the advertising code or B) set up a backend to fetch those
> IPs regularly and update the hard coded values. Either of those are much
> more complicated for the publisher when compared to just pasting in
> javascript.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Anne van Kesteren]

On Sat, Jun 18, 2016 at 2:37 PM, Eric Rescorla <e...@rtfm.com> wrote:
> The priority of this proposed feature seems to depend rather a lot on
> whether enough
> advertisers are using WebRTC to deliver ads to make it worth some ad
> blocker being
> interest in adding such a blocker. Do we have any evidence on this front?

Isn't the problem more that if you use CSP to block outgoing
connections, WebRTC can be used for exfiltration during XSS?


--
https://annevankesteren.nl/

[Anne van Kesteren]

On Sat, Jun 18, 2016 at 4:55 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> Isn't the problem more that if you use CSP to block outgoing
> connections, WebRTC can be used for exfiltration during XSS?

I filed

https://github.com/w3c/webappsec-csp/issues/92

to start the standards discussion.


--
https://annevankesteren.nl/

[Eric Rescorla]

On Sat, Jun 18, 2016 at 4:55 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Sat, Jun 18, 2016 at 2:37 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > The priority of this proposed feature seems to depend rather a lot on
> > whether enough
> > advertisers are using WebRTC to deliver ads to make it worth some ad
> > blocker being
> > interest in adding such a blocker. Do we have any evidence on this front?
>

> Isn't the problem more that if you use CSP to block outgoing
> connections, WebRTC can be used for exfiltration during XSS?

That wasn't the concern I understood Paul to be raising:
"for example, ad blockers use content policy to block ads".

With that said, this does seem like a potential problem, though perhaps a
more
tractable one, in that the CSP restrictions are whitelists rather than
blacklists.

-Ekr

[Daniel Veditz]

On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla <e...@rtfm.com> wrote:

> instead of having it sourced from the
> ​ ​
> advertiser's
> ​ ​
> origin, they instead stand
> up "<random-value>.publisher.example.com"
> ​ ​
> and
> ​ ​
> point
> ​ ​
> it at the advertiser's
> IP addresses (via an A record to the advertiser's
> ​ ​
> name never
> ​ ​
> appears).
> ​
> ​
> This would have a similar cost/effort structure to using data
> ​ ​
> channels and
> would similarly not be blocked by current domain-based ad blockers.
>

​Most ad-blockers (ABP, certainly) could easily block *.
publisher.example.com and whitelist the handful of foo.publisher.example.com
and bar.publisher.example.com, etc. needed to make the site "work".

wrt nsIContentPolicy, though, I'm not sure where a PeerConnection fits in.

-Dan Veditz

[Eric Rescorla]

On Tue, Jun 21, 2016 at 12:30 PM, Daniel Veditz <dve...@mozilla.com> wrote:

> On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> > instead of having it sourced from the
> > ​ ​
> > advertiser's
> > ​ ​
> > origin, they instead stand
> > up "<random-value>.publisher.example.com"
> > ​ ​
> > and
> > ​ ​
> > point
> > ​ ​
> > it at the advertiser's
> > IP addresses (via an A record to the advertiser's
> > ​ ​
> > name never
> > ​ ​
> > appears).
> > ​
> > ​
> > This would have a similar cost/effort structure to using data
> > ​ ​
> > channels and
> > would similarly not be blocked by current domain-based ad blockers.
> >
>
> ​Most ad-blockers (ABP, certainly) could easily block *.
> publisher.example.com and whitelist the handful of
> foo.publisher.example.com
> and bar.publisher.example.com, etc. needed to make the site "work".
>

That seems like a very expensive manual process.

-Ekr

> wrt nsIContentPolicy, though, I'm not sure where a PeerConnection fits in.
>
> -Dan Veditz

[Paul Ellenbogen]

I think you are right. I asked
<https://forums.lanik.us/viewtopic.php?f=6&t=31102> on the Easy List forum
and didn't get any compelling reason WebRTC could be blocked from
advertisers. Advertisers would be able to do what you describe to allow for
harder to block dynamic IPs. As you said elsewhere, advertisers probably
want to be in a 3rd party context in order to set cookies across domains.

On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla <e...@rtfm.com> wrote:

> The priority of this proposed feature seems to depend rather a lot on
> whether enough
> advertisers are using WebRTC to deliver ads to make it worth some ad
> blocker being
> interest in adding such a blocker. Do we have any evidence on this front?
>

> It's worth noting that from a security and tracking perspective, ads
> delivered via this
> mechanism look a lot more like first party ads (they are in the origin of
> the main
> page and do not get cookies from the advertiser's origin). So, in that
> respect all
> you're really doing is making it possible for the advertiser to send the
> data directly
> to the user rather than tunnelling it through the publisher. That's
> potentially of some
> value, but perhaps not an enormous amount.
>
> As a thought experiment, consider an ad serving design in which publishers
> include

> ad content as they do now but instead of having it sourced from the

> advertiser's
> origin, they instead stand up "<random-value>.publisher.example.com" and
> point
> it at the advertiser's IP addresses (via an A record to the advertiser's
> name never
> appears). This would have a similar cost/effort structure to using data
> channels and

[rh...@raymondhill.net]

On Friday, June 17, 2016 at 10:28:55 AM UTC-4, 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.

A real case of RTCPeerConnection used in the wild to deliver ads: merriam-webster.com.

On my side, I do block all 3rd parties by default, but the site was able to circumvent my wish to not connect to 3rd parties. The only solution I found for now given that network requests from RTCPeerConnection are not going through the browser's HTTP observer is to inject a script in the page to prevent the use of RTCPeerConnection.