4 ms·

From their white paper: The technology used by Secret Media makes sure that each ad gets a specific URL that cannot be nor found not added to EasyList

From their white paper: The technology used by Secret Media makes sure that each ad gets a specific URL that cannot be nor found not added to EasyList by the community. I don't quite understand why they think this would work. Surely ad-blockers can filter by domain? Are they using well camouflaged URLs from legit domains? Or do they have a never-ending supply of throwaway domain names, in order to stay one step ahead of EasyList? Either way, I'm genuinely curious to see what they have in mind...

kawera 11y ago
Would subdomains do the trick, say, very-very-long-cryptokey.publisher.tld ?
- sarciszewski 11y ago
  No, because then we can build whitelist-based ad blockers (e.g. RequestPolicy, NoScript).
  - kawera 11y ago
    Thanks! Pardon my ignorance but what if the content url itself came encoded in the same manner?
    - sarciszewski 11y ago
      They would have to hack into the websites we already trust to serve as a proxy for their ads to bypass a strict whitelist.
    - Sanddancer 11y ago
      They'll lose some of their SEO juice because their URLs are no longer human-friendly. Hashing everything would be more costly than letting some people block ads.
      - nailer 11y ago
        You could have human friendly URLs for articles and use hashed URLs for image and video content.
- pdkl95 11y ago
  (note: I'm hesitant to post this; any site that actually did this is a site I'm never visiting again) The way to get around adblocking is very long crypto tokens, but not in the subdomain. All that is needed is a front-end proxy that takes each session[1] and rewrites all href/src addresses to point to the proxy. This means all URLs in the page are of the form https;//example.com/proxy/<crypto-token> # or in the no-cookie case https://example.com/proxy/<crypto-token>/<session-id> Rewriting client-side generated URLs is an exercise left for the relevant Javascript framework, but only requires the addition of a simple API in the proxy to convert URLs, or some sort of bypass/whitelist mechanism. The tokens used by the proxy can either be the cyphertext of the actual URL or a synthetic token that references the real URL stored in a DB in the proxy. Such details can are left to the implementation of the proxy. The point is that you have to send the crypto token back to the proxy to get either 1) a redirect of the real URL, 2) the actual content served by the site in question (either from the proxy directly or as a tunnel, or 3) the advertisement/whatever, with the prox6y acting as a live proxy to real ad server, with all the stupid tracking information passed along as extra HTTP headers (in the style of "X-Forwarded-For"). The client only ever sees URLs from the single domain, each obfuscated into a crypto token. No URL would give up any distinguishing characteristic an adblocker can use as a filter. The only costs are the cost of running the proxy, and a bit of latency on each GET request because of the extra hop through the proxy. It might be possible to find heuristics to block in the client's DOM, which is why I have expressed concern in the past[2] about the people who will use WebAssembly and a <canvas> tag to bypass the DOM. These two techniques in combination will make adblocking nearly impossible without first either breaking crypto or solving the halting problem. [1] As defined in the usual manner, either as a cookie or embedded in the URLs the proxy generates. [2] https://news.ycombinator.com/item?id=10211050 https://news.ycombinator.com/item?id=10211050
  - EyeballKid 11y ago
    But can't an adblocker just add: example.com/proxy/* to its list of requests to block? (of course, the URLs could be camouflaged to look like real ones... eg: http://example.com/a-very-legit-looking-article ugh.)
    - 11y ago
femto 11y ago
Bittorrent style per-to-peer botnet, where each ad includes code that downloads ads from their server and redistributes them, so ads are coming from readers' IP addresses?

kawera 11y ago

Would subdomains do the trick, say, very-very-long-cryptokey.publisher.tld ?

sarciszewski 11y ago
No, because then we can build whitelist-based ad blockers (e.g. RequestPolicy, NoScript).
- kawera 11y ago
  Thanks! Pardon my ignorance but what if the content url itself came encoded in the same manner?
  - sarciszewski 11y ago
    They would have to hack into the websites we already trust to serve as a proxy for their ads to bypass a strict whitelist.
  - Sanddancer 11y ago
    They'll lose some of their SEO juice because their URLs are no longer human-friendly. Hashing everything would be more costly than letting some people block ads.
    - nailer 11y ago
      You could have human friendly URLs for articles and use hashed URLs for image and video content.
pdkl95 11y ago
(note: I'm hesitant to post this; any site that actually did this is a site I'm never visiting again) The way to get around adblocking is very long crypto tokens, but not in the subdomain. All that is needed is a front-end proxy that takes each session[1] and rewrites all href/src addresses to point to the proxy. This means all URLs in the page are of the form https;//example.com/proxy/<crypto-token> # or in the no-cookie case https://example.com/proxy/<crypto-token>/<session-id> Rewriting client-side generated URLs is an exercise left for the relevant Javascript framework, but only requires the addition of a simple API in the proxy to convert URLs, or some sort of bypass/whitelist mechanism. The tokens used by the proxy can either be the cyphertext of the actual URL or a synthetic token that references the real URL stored in a DB in the proxy. Such details can are left to the implementation of the proxy. The point is that you have to send the crypto token back to the proxy to get either 1) a redirect of the real URL, 2) the actual content served by the site in question (either from the proxy directly or as a tunnel, or 3) the advertisement/whatever, with the prox6y acting as a live proxy to real ad server, with all the stupid tracking information passed along as extra HTTP headers (in the style of "X-Forwarded-For"). The client only ever sees URLs from the single domain, each obfuscated into a crypto token. No URL would give up any distinguishing characteristic an adblocker can use as a filter. The only costs are the cost of running the proxy, and a bit of latency on each GET request because of the extra hop through the proxy. It might be possible to find heuristics to block in the client's DOM, which is why I have expressed concern in the past[2] about the people who will use WebAssembly and a <canvas> tag to bypass the DOM. These two techniques in combination will make adblocking nearly impossible without first either breaking crypto or solving the halting problem. [1] As defined in the usual manner, either as a cookie or embedded in the URLs the proxy generates. [2] https://news.ycombinator.com/item?id=10211050 https://news.ycombinator.com/item?id=10211050
- EyeballKid 11y ago
  But can't an adblocker just add: example.com/proxy/* to its list of requests to block? (of course, the URLs could be camouflaged to look like real ones... eg: http://example.com/a-very-legit-looking-article ugh.)
  - 11y ago

femto 11y ago

Bittorrent style per-to-peer botnet, where each ad includes code that downloads ads from their server and redistributes them, so ads are coming from readers' IP addresses?