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 > would similarly not be blocked by current domain-based ad blockers. What > would our > expectations be here? > > -Ekr > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
