WebRTC has a data channel feature that allows data to be sent to clients. Typically this is done between browsers, but in principle there is nothing to stop a server from accepting WebRTC connections. There is discussion I started on the firefox dev-platform mailing list to include WebRTC connections in content policy in order to allow blockers to block WebRTC connections.

One response suggested that this sort of blocking could be circumvented by each publisher using a random valued subdomain. The text in question is here:

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 "<randomvalue>.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?

What strikes me about this set up is that it would work for non WebRTC based ads as well. Either the Ekr found a new way to beat adblockers, or we are missing something important in that discussion. I was hoping for feedback from individuals with more experience in this domain.

In my opinion the rationale for exposing WebRTC connections to extensions API should not emphasize that it's for "ad blocking" purpose. "ad blocking" is a subset of a larger issue: allowing users to be informed of where their browser connects, and optionally let them agree or disagree with the connection. This is already the case with the existing API, so it just makes sense to ensure the API does its job competently for *all* connection attempts.