[webkit-help] Feedback about Content Blocking Extensions from Adblock Plus

[Arthur]

>
> I looped in Arthur (aka. MontzA, the EasyList author). I hope he can
> provide some more concrete examples. Also he might be aware of some use
> cases I didn't point out yet.
>

Sorry for my late response! Here are some examples currently in EasyList:

@@||www.networkadvertising.org/choices/|$document: this exception rule
fixes the opt out page for "interest-Based Advertising" (
http://www.networkadvertising.org/choices/). Without the $document option
tons of specific exception rules would be necessary to fix this page to
work properly. Also, there is no need to regularily check if new ad
networks have been added since due to the $document option the /choices
page will always be whitelisted completely (including iframes).

On http://www.jabong.com/ there is an iframe from ad.doubleclick.net which
doesn't serve ads but rather self-promotion for the site itself. Without a
$document option you would need to allow a banner from 2mdn.net
(DoubleClick) and a JS file from pagead2.googlesyndication.com (Google
AdSense & DoubleClick) in that very ad.doubleclick.net iframe. In that case
you cannot restrict it to the jabong.com domain anymore. So allowing that
banner and script is basically allowed for any website using iframes from
ad.doubleclick.net then which is pretty bad. The $document allows you to
specifically allow that iframe (including all requests in it) and only for
a specific domain (jabong.com) in this case.

2015-06-18 15:57 GMT+02:00 Sebastian Noack <sebastian at adblockplus.org>:

> On Wed, Jun 17, 2015 at 10:31 AM, Sebastian Noack <
> sebastian at adblockplus.org> wrote:
>
>> On Mon, Jun 15, 2015 at 5:42 AM, Benjamin Poulain <benjamin at webkit.org>
>> wrote:
>>
>>>  Targeting XHR specifically seems very easy to counter to me. Couldn't
>>> one just use the Fetch API or Sockets to work around the rule?
>>>
>>
>> I don't think so. Note that with the new content blocking API you cannot
>> run code on request anymore. And even then you probably don't want to
>> repeat requests just to retrieve additional metadata. And even then the
>> response won't tell you in which context the request originally occurred.
>>
>
> Sorry, I just realized what you meant here. (I mistakenly thought you
> suggested to repeat requests to obtain additional metadata). But yeah, if a
> page uses the Fetch API, rules checking for XMLHttpRequest wouldn't match,
> however filters checking for "other" request types should match then. The
> distinction between XMLHttpRequest and Fetch API doesn't seem to be
> important. We might merge them into a common type in the future. However,
> the distinction between these, JavaScript initiated, requests and object
> (Flash) initiated requests is kinda important for us, as explained in my
> previous email.
>
> Sebastian
>



-- 
Arthur Kawa

IT Officer Trainee

Eyeo GmbH

Im Klapperhof 7-23

50670 Cologne, Germany

VAT-ID: DE279292414

District Court Cologne: HRB 73508

Managing Directors: Wladimir Palant & Till Faida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-help/attachments/20150629/87d43706/attachment.html>