time.com

[eighty5cacao]

On http://time.com/70888/megyn-kelly-2014-time-100/ the infinite scrolling is broken due to EasyList blocking of

Code: Select all

http://tiads.time.com/ads/tgx.js?ver=4.0-beta2-20140728

which could be whitelisted via something like

Code: Select all

@@||tiads.time.com/ads/tgx.js?ver=$script,~third-party

Note that HTTPS Everywhere rewrites the offending URL to

Code: Select all

https://a248.e.akamai.net/f/259/1/g/tiads.time.com/ads/tgx.js?ver=4.0-beta2-20140728

which thus also needs to be whitelisted, e.g.

Code: Select all

@@||akamai.net^*/tiads.time.com/ads/tgx.js?ver=$script,domain=time.com

(discussed by other users at http://what.thedailywtf.com/t/the-oppos ... lling/2036 )

[fanboy]

https://hg.adblockplus.org/easylist/rev/e1ed3c476c7d (also cleaned up)

Shouldn't the 2nd issue be fixed by https everywhere if its caused by it?

[eighty5cacao]

No - HTTPS Everywhere is doing its job correctly, in that the rewritten URL returns correct content.
However, it needs to be whitelisted separately in ABP, as it is seen by ABP as a separate request and will still cause the original issue to occur if it is blocked (as I have observed - whitelisting both does resolve the issue).

[fanboy]

https://gitweb.torproject.org/https-eve ... 7273a49223

Code: Select all

<rule from="^http://tiads\.time\.com/"

  to="https://a248.e.akamai.net/f/259/1/g/tiads.time.com/" />

Not sure how this job is correctly done, given they're re-writing the url (not Easylist or Adblock Plus). Personally I would get https everywhere not to re-write it the address.

If we allow this, then every other buggy re-written address by https everywhere would need to be fixed by us.

Report it there bugtracker? https://trac.torproject.org/projects/tor/report/19

[eighty5cacao]

Again, the problem is that ABP sees the original and rewritten URLs as separate requests, so if only the original URL is whitelisted, the rewritten URL (which is the one really requested on the network) will still be blocked and trigger the symptom in question.

I verified that "the rewritten URL returns correct content" by browsing directly to https://a248.e.akamai.net/f/259/1/g/tia ... =4.0-beta3 (does it return any error for you?)
Rules of this kind are quite common for content hosted on the Akamai CDN but not configured with custom SSL. As far as I know, they have not historically caused many bugs.

As I stated, whitelisting both URLs in ABP successfully resolves the issue for me, with no configuration changes needed to HTTPS Everywhere. That means that as long as the offending script is allowed to load from either URL, the page will work.

I have also verified that HTTPS Everywhere by itself, with no form of ad blocking active, causes no problems for the page in question. That is the sense in which the ruleset is working correctly.

(For clarity: I am using Firefox, and I do not know how the situation might differ in Chrome.)

[eighty5cacao]

Also, regarding EasyList policy: "Ads caused by malware or adware extensions or plugins on your computer will not be fixed."

Is this meant to apply to all addons regardless of malicious intent? If so, please reconsider - HTTPS Everywhere developers will not exclude URLs solely to make life easier for adblocker maintainers, as doing so would reduce security (the whole point of HTTPS Everywhere).

[eighty5cacao]

Let's consider this closed for now.

This was probably a site bug, in that the site has been modified to handle a failure of the ad script more gracefully. I can disable the whitelist filter(s) from this discussion and still have the page scroll properly. Should we remove the whitelist that we added?