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 <pellenbo...@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-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
