> > 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 <[email protected]>: > On Wed, Jun 17, 2015 at 10:31 AM, Sebastian Noack < > [email protected]> wrote: > >> On Mon, Jun 15, 2015 at 5:42 AM, Benjamin Poulain <[email protected]> >> 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
_______________________________________________ webkit-help mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-help
