[HTTPS-E Rulesets] More defects - examiner.com, justin.tv, MapQuest, Sony, TechnologyReview, Yahoo

Christopher Liu cmliu00151 at gmail.com
Mon Sep 3 23:49:29 PDT 2012


To whom it may concern,
A "few" more things that didn't make it into my last email. Note that
I am not a registered/logged-in user of any site listed here.

Examiner.com: Most news articles (still) appear to redirect back to
http, for example
http://www.examiner.com/article/exactly-what-are-israeli-airport-security-measures-and-would-they-work-here
Also, I don't seem to get a (valid) response from beacon.examiner.com
. At least the rules for cdn2-b and stats still seem to be safe.
Some things that might be mistakes/typos:
-There is an exclusion for http://www.examiner.com/tag/ which contains
unescaped periods and also is redundant with the other exclusion.
-The comment says photos.examiner.com is nonfunctional, but it has a
rule; which is right? I can't seem to find where photos.examiner.com
is used on the site anyway.
-There is a rule covering parts of www.theexaminer.com but no target
that would allow it to work; did someone confuse this with another
news source named Examiner?

Justin.tv: This should be disabled again, as the cert is no longer
valid, at least for www.justin.tv. (As usual, I panicked and closed
the tab before reading what type of cert error it was...)
https://trac.torproject.org/projects/tor/ticket/6699 may be related;
the offending content in that case is coming from the jtvnw subdomains
rather than twitch.tv itself.

MapQuest: This might be broken (it seems to time out)

Sony: http://us.playstation.com/omniture/blogs/s_code.js redirects
back to http. It is used at least on
http://blog.us.playstation.com/2012/08/27/ps-vita-system-software-update-v1-80-take-the-tour-2/

Technology Review: Some pages still redirect to http. This includes
the (.com) homepage sometimes, and news stories such as
http://www.technologyreview.com/view/428923/verizon-wins-some-spectrum-wiggle-room/
always (note the "view" folder). It is possible that the site allows
one https pageview for new users who have no cookies stored but
redirects to http thereafter.
Attached is a suggestion for limiting the rule scope. I didn't include
the .in domain since I don't use that site often enough to do a good
job testing it.

Yahoo (experimental): Videos in news stories such as
http://news.yahoo.com/series-earthquakes-rattle-southern-california-215023392.html
fail to load, leaving a black area where the video should be.
-- The exclusion that solves this is for
http://yui.yahooapis.com/combo (more specifically,
^http://yui\.yahooapis\.com/combo\?\d to check that the query string
begins with a digit - see notes below). --
With the ruleset in its present state, there are several requests
similar to https://s.yimg.com/zz/d/lib/yui/combo?3.5.1/build/console/assets/skins/sam/console.css&3.5.1/build/widget-base/assets/skins/sam/widget-base.css
which return status 400. These appear to have been rewritten from
yui.yahooapis.com/combo.
(By comparison, there are "good" requests that begin with
https://s.yimg.com/zz/combo and usually contain "yui:3.5.1" rather
than just "3.5.1".
I first tried adding a rule to rewrite yui.yahooapis.com/combo to
https://s.yimg.com/zz/combo , but that didn't stop the 400s nor get
the video working.)


C. Liu
-------------- next part --------------
<ruleset name="TechnologyReview (partial)">
  <target host="technologyreview.com" />
  <target host="*.technologyreview.com" />

<!--
	favicon.ico normally has a query parameter. Other items are folders normally followed by a slash.
	contributor contains photos of the writers
	ontopic contains stylesheets
-->
  <rule from="^http://(?:www\.)?technologyreview.com/(api|contributor|css|favicon\.ico|files|images|login|ontopic|scripts)" to="https://www.technologyreview.com/$1" />
  <rule from="^http://s?metrics\.technologyreview\.com/" to="https://smetrics.technologyreview.com/"/>
  <rule from="^http://subscribe\.technologyreview\.com/" to="https://subscribe.technologyreview.com/"/>
</ruleset>


More information about the HTTPS-Everywhere-Rules mailing list