[HTTPS-E Rulesets] Some ruleset comments/maintenance requests

Christopher Liu cmliu00151 at gmail.com
Fri Sep 9 13:54:16 PDT 2011


To whom it may concern:

You may be aware that I sent you a few emails before. I am still a
little too busy with academic/research work to finish setting up Git,
but I assure you I haven't forgotten. Also, I apologize for any
inconvenience caused by sending some emails directly to Seth rather
than the entire list.

The attachments are as described below. (Please disregard any earlier
submissions from me with the same file names, if you have not read
them yet.)
*Disqus+: Rewrite mediacdn. disqus. com to its https equivalent
securecdn. disqus. com (to be merged with Disqus)
*EFF+: Handle those pages on action. eff. org that should redirect to
secure. eff. org; also the redirect at www. freeyourphone. org (to be
merged with EFF)
*GPFComics: New ruleset
*JSAtech: New ruleset
*Khronos: Maintenance additions to attempt protection against sslstripping
*Microsoft: Maintenance related to the notes below
*Mozilla: A couple more Mozilla-affiliated domains (webifyme. org and
webfwd. org) which have links on the Mozilla Foundation homepage
(based on my previous submission)
*MyWOT+: Fix mixed-content warnings on the homepage and scorecard
pages (to be merged with MyWOT)
*Scroogle: Attempt to protect ssl. scroogle. org against sslstripping
(based on my previous submission)
*UCSD: Maintenance, mostly for changes to TritonLink/Current Students pages
*Wikipedia+: bits. wikimedia.org, geoiplookup. wikimedia. org, and
upload. wikimedia. org support HTTPS now; perform requisite rewriting
on these. This is important because it makes nearly all Wikimedia
Foundation wikis usable without mixed content. (to be merged with
Wikipedia)
*YouTube-partial: Maintenance for some more site features and handling
query parameters on youtu. be; also testing merge of ytimg; I am aware
that this submission probably won't be considered now that you're
asking Google to modify their crossdomain.xml files, but I just want
to keep you updated.

Some rulesets have comments of dubious accuracy:
*KrebsOnSecurity says "only enterprice. krebsonsecurity. com seems to
have ssl" - obviously wrong, and no such domain seems to exist, even
under the correct spelling "enterprise." This may have been mistakenly
copied from the PodOmatic ruleset.
*Examiner says "Uses b. scorecardresearch. com, that only provides ssl
via akamai", but sb. scorecardresearch. com exists with https - this
would need a separate ruleset, and the comment should explain the
status more clearly.
*Enom - comment suggests that the ruleset should be disabled by
default. Is that still true?
*Amazon. com - The comment above the aws. amazon. com rule appears to
predate the creation of the S3 / Amazon Web Services rulesets and is
now out of date. The rule itself is also redundant

The following rulesets may need to be disabled:
*Bloglines (times out trying to establish connection)
*EPEAT (protocol fails with ssl_error_rx_record_too_long - site seems
to have been redesigned recently, probably accompanied by some backend
changes)
*NL Overheid (due to loss of DigiNotar trust?)
*Ytimg (breaks user page background images, as I probably said before.
Is an exclusion needed for crossdomain.xml files?)
To correct something I said earlier, MapQuest is now working fine for me.
I am reasonably sure that my computer and network are free of firewall
restrictions, malware, or other potential causes of MITM.

Regarding the Microsoft ruleset:
*The target element for "*.windowsupdate. microsoft. com" appears to
be redundant to "*.microsoft. com" (am I understanding correctly?)
*msdn. microsoft. com is redirecting back to http for me; should it be removed?
*social. technet. microsoft. com should probably be removed; it tries
to load stuff from https: // widgets. membership. s-msft. com:80 which
slows page loading and breaks user avatars. (?! Not entirely sure what
is going on; Adblock Plus reports inaccurate/conflicting information
vs. Live HTTP Headers.) This means that the target element for
"*.technet. microsoft. com" can also be removed.

Regarding the RFC-Editor ruleset, the errata search feature is
redirecting back to http for me (the pattern
^http://(www\.)?rfc-editor\.org/errata should cover this). The rest of
the site still works fine in https. Does any action need to be taken
on this?

The following rulesets no longer work because of redirects back to http:
*Associated Content
*Examiner (on www. examiner. com, but the cdn2-b subdomain still works in https)
*EzineArticles (the document itself redirects back to http, but some
resources on the page still seem to be protected. Premium
subscriptions are available and might be required for full https
support)
*LKML (needs testing from an Indiana University student on the campus
network, to see if that makes any difference)

C. Liu

P.S. Your web server seems to be sending the max-age parameter of the
Strict-Transport-Security header twice (that is,
Strict-Transport-Security: max-age=2628000, max-age=2628000)
-------------- next part --------------
<!-- This is not intended for inclusion as a separate ruleset. It should be merged with Disqus if it checks out ok. -->
<ruleset name="Disqus+">
   <target host="mediacdn.disqus.com" />

   <rule from="^http://mediacdn\.disqus\.com/" to="https://securecdn.disqus.com/" />
</ruleset>
-------------- next part --------------
<!-- This is not intended for inclusion as a separate ruleset. It should be merged with EFF if it checks out ok. -->
<ruleset name="EFF+">
    <target host="action.eff.org" />
    <target host="www.freeyourphone.org" />

<!-- For example:
     http://action.eff.org/site/Advocacy?pagename=homepage&id=497 -> https://secure.eff.org/site/Advocacy?cmd=display&page=UserAction&id=497
     Normally there are some intermediate redirects, but they're not really important

     Would this work:
    <rule from="^http://action\.eff\.org/" to="https://secure.eff.org/" />
     or are there other things that this would break? If so, we still need an exclusion with the rules below:
    <exclusion pattern="^http://action\.eff\.org/(?!site/Advocacy)" />
-->
    <rule from="^http://action\.eff\.org/site/Advocacy\?pagename=homepage&#x26;id="
            to="https://secure.eff.org/site/Advocacy?cmd=display&#x26;page=UserAction&#x26;id=" />
    <rule from="^http://action\.eff\.org/site/Advocacy\?id=(\d+)&#x26;pagename=homepage$"
            to="https://secure.eff.org/site/Advocacy?cmd=display&#x26;page=UserAction&#x26;id=$1" />
<!-- did any other pages exist on www.freeyourphone.org? -->
    <rule from="^http://www\.freeyourphone\.org/$" to="https://www.eff.org/cases/2009-dmca-rulemaking" />
</ruleset>
-------------- next part --------------
<!-- comic pages have mixed content due to ohnorobot transcription script.
     wiki is ok on a quick glance but needs more testing from someone w/ editing privileges -->
<!-- Note on this ruleset's name: According to the site's FAQ, the name "GPF Comics"
     refers to the fictional company that writes the strips and is discouraged for describing the site itself.
     Perhaps this ruleset should be called "General Protection Fault" or "General Protection Fault Comics" if UI space permits.
     (Remove this comment before deploying this ruleset) -->     
<ruleset name="GPF Comics">
   <target host="gpf-comics.com" />
   <target host="www.gpf-comics.com" />

<!-- redirects back to http 
     (NB: I'm not sure whether that alone is valid grounds for an exclusion; remove if you wish)
-->
   <exclusion pattern="^http://(www\.)?gpf-comics\.com/forum/" />

   <rule from="^http://(www\.)?gpf-comics\.com/" to="https://www.gpf-comics.com/" />
</ruleset>
-------------- next part --------------
<!-- payment system used by several universities for dining money cards.
     by default, seems not to enforce https on the login page (!),
     though the form has an https action
     TODO: securecookie
-->
<ruleset name="JSAtech">
   <target host="services.jsatech.com" />

   <rule from="^http://services\.jsatech\.com/" to="https://services.jsatech.com/" />
</ruleset>
-------------- next part --------------
<!-- pages outside the specs folder still need testing and generally have plaintext from gallery.mailchimp.com + flickr -->
<!-- https support needs investigation on mailing lists and bugzilla -->
<ruleset name="Khronos Group (partial)">
   <target host="khronos.org" />
   <target host="www.khronos.org" />

   <rule from="^http://(www\.)?khronos\.org/registry/(.+)/(resources|specs)/" to="https://www.khronos.org/registry/$2/$3/" />
   <!-- Items below this line are already https-only but worth protecting against sslstripping -->
   <rule from="^http://(www\.)?khronos\.org/(.+)/login/" to="https://www.khronos.org/$2/login/" />
   <rule from="^http://(www\.)?khronos\.org/members/signup/" to="https://www.khronos.org/members/signup/" />
</ruleset>
-------------- next part --------------
<ruleset name="Microsoft">
  <target host="*.microsoft.com" />
  <target host="microsoft.com" />
  <target host="blogs.msdn.com" />
<!-- technet redirects back to http.

     social.technet appears to work (with mixed content), except for one issue:
     It tries to load stuff from https://widgets.membership.s-msft.com:80 (?!?) according to Adblock Plus (Live HTTP Headers shows these requests going through in plain http or not at all).
     This slows page loading and breaks user avatars.
     A similar problem exists with blogs.msdn.com hitting https://widgets.membership.microsoft.com:80 but that produces no overt breakage
  <target host="*.technet.microsoft.com" />
  
  Is the below target element for windowsupdate redundant?
-->
  <target host="*.windowsupdate.microsoft.com" />

  <!-- ironic -->
  <exclusion pattern="^http://www\.microsoft\.com/security/" />
  <!-- As of 8/1/2011, these give blank pages in https.
       When accessed in plain http, the folder "downloads" redirects to "download" (without an S), which works fine in https.
       We can't write a rule to handle the redirects ourselves because they are tricky (from GUIDs to shorter identifiers).
  -->
  <exclusion pattern="^http://www\.microsoft\.com/.*FamilyID" />

  <rule from="^http://(www\.)?microsoft\.com/"
	  to="https://www.microsoft.com/"/>
  <!-- msdn.microsoft.com is redirecting back to http as of 8/1/2011. Did it ever actually work? -->
  <rule from="^http://(adcenter|advertising|ajax|connect|go|ie|office|office365|office2010|onlinehelp|research|signature|snackbox|social|store|profile|windowsupdate)\.microsoft\.com/"
          to="https://$1.microsoft.com/"/>
  <rule from="^http://(v4|v5)\.windowsupdate\.microsoft\.com/"
          to="https://$1.windowsupdate.microsoft.com/" />
  <rule from="^http://blogs\.msdn\.com/"
	  to="https://blogs.msdn.com/"/>
</ruleset>
-------------- next part --------------
<!-- BOOOO: Firefox.com (which some download links pass through) is in
     HTTP only... -->

<ruleset name="Mozilla">
  <target host="mozilla.org" />
  <target host="*.mozilla.org" />
  <target host="mozilla.com" />
  <target host="*.mozilla.com" />
  <target host="mozillalabs.com" />
  <target host="*.mozillalabs.com" />
  <target host="mozillamessaging.com" />
  <target host="www.mozillamessaging.com" />
  <target host="planet.mozillamessaging.com" />
  <target host="getpersonas.com" />
  <target host="www.getpersonas.com" />
  <target host="mozdev.org"/>
  <target host="bugzilla.mozdev.org" />
  <target host="hg.mozdev.org"/>
  <target host="www.mozdev.org"/>
  <target host="drumbeat.org" />
  <target host="www.drumbeat.org" />
  <target host="webifyme.org" />
  <target host="www.webifyme.org" />
  <target host="webfwd.org" />
  <target host="www.webfwd.org" />

  <rule from="^http://mozilla\.org/" to="https://www.mozilla.org/"/>
  <rule from="^http://(addons|bzr|communitystore|creative|developer|directory|donate|education|firefoxlive|ftp|intlstore|krakenbenchmark|lists|l10n|localize|hacks|hg|labs|mail|mpl|mxr|nightly|planet|studentreps|quality|wiki|www|www-archive)\.mozilla\.org/" to="https://$1.mozilla.org/"/>

  <rule from="^http://mozilla\.com/" to="https://www.mozilla.com/"/>
  <rule from="^http://(blog|crash-stats|input|people|support|www)\.mozilla\.com/" to="https://$1.mozilla.com/"/>

  <rule from="^http://(www\.)?mozillalabs\.com/" to="https://mozillalabs.com/"/>
  <rule from="^http://(apps|bespin|bespinplugins|gaming|heatmap|jetpack|testpilot)\.mozillalabs\.com/" to="https://$1.mozillalabs.com/"/>

  <rule from="^http://mozillamessaging\.com/" to="https://mozillamessaging.com/"/>
  <rule from="^http://(planet|www)\.mozillamessaging\.com/" to="https://$1.mozillamessaging.com/"/>

  <rule from="^http://(www\.)?getpersonas\.com/" to="https://www.getpersonas.com/" />

  <rule from="^http://mozdev\.org/" to="https://mozdev.org/"/>
  <rule from="^http://bugzilla\.mozdev\.org/" to="https://www.mozdev.org/bugs/" />
  <rule from="^http://(hg|www)\.mozdev\.org/" to="https://$1.mozdev.org/"/>

  <rule from="^http://(www\.)?drumbeat\.org/" to="https://www.drumbeat.org/" />

  <rule from="^http://(www\.)?webifyme\.org/" to="https://webifyme.org/" />

  <rule from="^http://(www\.)?webfwd\.org/" to="https://webfwd.org/" />
</ruleset>
-------------- next part --------------
<!-- This fixes some mixed-content warnings. A more general filter for api.mywot.com would probably break the WOT extension.
     This is not intended for inclusion as a separate ruleset. It should be merged with MyWOT if it checks out ok. -->
<ruleset name="MyWOT+">
   <target host="api.mywot.com" />
   <target host="cdn-aws.mywot.net" />

   <rule from="^http://api\.mywot\.com/widgets/ratings\.js" to="https://api.mywot.com/widgets/ratings.js" />
   <rule from="^http://cdn-aws\.mywot\.net/" to="https://d1o4uu3cesqhlq.cloudfront.net/" />
</ruleset>
-------------- next part --------------
<ruleset name="Scroogle">
  <target host="www.scroogle.org" />
  <target host="scroogle.org" />
  <target host="ssl.scroogle.org" /><!-- only for protection against sslstripping -->

  <rule from="^http://ssl\.scroogle\.org/" to="https://ssl.scroogle.org/" />

  <rule from="^http://(www\.)?scroogle\.org/cgi-bin/nbbw\.cgi" to="https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi"/>
  <rule from="^http://(www\.)?scroogle\.org/cgi-bin/scraper\.htm$" to="https://ssl.scroogle.org/" />
  <rule from="^http://(www\.)?scroogle\.org/langsup8\.html$" to="https://ssl.scroogle.org/langsup8.html" />
</ruleset>
-------------- next part --------------
<ruleset name="UCSD">
<!-- quikpayasp.com (E-Check) and services.jsatech.com (TritonCash) need separate
     rulesets because these domains also provide services for other universities.
     Does uc.sumtotalsystems.com (ultimate destination of uclearning) belong here,
     or do other UCs use it too?
-->
<!-- TODOs:
   <target host="acs.ucsd.edu" /> (a few pages redirect to acms)
   <target host="m.ucsd.edu" /> (mobile redirection script supports https because it is used on TritonLink)
   <target host="students.ucsd.edu" /> (supports https for some embedded content on TritonLink)
   <target host="ted.ucsd.edu" /> (probably incomplete https support)
   <target host="ucsdbkst.ucsd.edu" /> (default https for class textbook listings; used for anything else?
                                        This is not the main bookstore website)
   <target host="webct.ucsd.edu" /> (redirector; check behavior when logged in vs. out)
   <target host="webctweb.ucsd.edu" /> (superseded by ted)
   <target host="www-no.ucsd.edu" /> (Network Operations, used by ResNet registration etc. not sure if https enforced.
                                      www-ono.ucsd.edu seems to exist too - Old Network Operations?)
   <target host="www.ucsd.edu" /> (supports https for some embedded content on TritonLink)
     My ability to test is limited in that I'm not currently enrolled in any classes that use WebCT/Ted.
-->
<!-- normally https only; protect against sslstripping -->
   <target host="a4.ucsd.edu" />
   <target host="acs-webmail.ucsd.edu" />
   <target host="altng.ucsd.edu" />
   <target host="cinfo.ucsd.edu" />
   <target host="facilities.ucsd.edu" />
   <target host="graduateapp.ucsd.edu" />
   <target host="myucsdchart.ucsd.edu" />
   <target host="sdacs.ucsd.edu" />
   <target host="shs.ucsd.edu" />
<!-- supports https but doesn't enforce it on all pages -->
   <target host="acms.ucsd.edu" />
   <target host="roger.ucsd.edu" />
   <target host="uxt.ucsd.edu" />
   <target host="www-cse.ucsd.edu" />
<!-- only some features support https; protect them against sslstripping -->
   <target host="act.ucsd.edu" />
   <target host="hds.ucsd.edu" />
   <target host="health.ucsd.edu" />
   <target host="libraries.ucsd.edu" />
   <target host="studenthealth.ucsd.edu" /><!-- Ask-A-Question enforces https, but unfortunately it is signed by ipsCA. See note below -->
   <target host="www-act.ucsd.edu" />
<!-- redirectors
     TODO: full Link Family list at http://blink.ucsd.edu/technology/help-desk/applications/link-family/list.html -->
   <target host="accesslink.ucsd.edu" />
   <target host="cri.ucsd.edu" />
   <target host="desktop.ucsd.edu" />
   <target host="financiallink.ucsd.edu" />
   <target host="iwdc.ucsd.edu" />
   <target host="marketplace.ucsd.edu" />
   <target host="mytritonlink.ucsd.edu" />
   <target host="www.mytritonlink.ucsd.edu" />
   <target host="resnet.ucsd.edu" />
   <target host="software.ucsd.edu" />
   <target host="sysstaff.ucsd.edu" />
   <target host="tritonlink.ucsd.edu" />
   <target host="www.tritonlink.ucsd.edu" />
   <target host="uclearning.ucsd.edu" />
   <target host="www-acs.ucsd.edu" />

   <securecookie host="^(.+\.)?a(4|cs-webmail)\.ucsd\.edu$" name=".*" />

   <rule from="^http://a4\.ucsd\.edu/" to="https://a4.ucsd.edu/" />
   <rule from="^http://acs-webmail\.ucsd\.edu/" to="https://acs-webmail.ucsd.edu/" />
   <rule from="^http://altng\.ucsd\.edu/" to="https://altng.ucsd.edu/" />
   <rule from="^http://cinfo\.ucsd\.edu/" to="https://cinfo.ucsd.edu/" />
   <rule from="^http://facilities\.ucsd\.edu/" to="https://facilities.ucsd.edu/" />
   <rule from="^http://graduateapp\.ucsd\.edu/" to="https://graduateapp.ucsd.edu/" />
   <rule from="^http://myucsdchart\.ucsd\.edu/" to="https://myucsdchart.ucsd.edu/" />
   <rule from="^http://sdacs\.ucsd\.edu/" to="https://sdacs.ucsd.edu/" />
   <rule from="^http://shs\.ucsd\.edu/" to="https://shs.ucsd.edu/" />

   <rule from="^http://acms\.ucsd\.edu/" to="https://acms.ucsd.edu/" />
   <rule from="^http://roger\.ucsd\.edu/" to="https://roger.ucsd.edu/" />
   <rule from="^http://uxt\.ucsd\.edu/" to="https://uxt.ucsd.edu/" />
   <rule from="^http://www-cse\.ucsd\.edu/" to="https://www-cse.ucsd.edu/" />

   <rule from="^http://hds\.ucsd\.edu/(ARCH_WaitList/ARCHMainMenu\.aspx|conference/RequestInfo/|HospitalityExpress)" 
           to="https://hds.ucsd.edu/$1" />
   <rule from="^http://health\.ucsd\.edu/request_appt/" 
           to="https://health.ucsd.edu/request_appt/" />
   <rule from="^http://libraries\.ucsd\.edu/digital/"
           to="https://libraries.ucsd.edu/digital/" />
<!-- NB: This area of the site uses https only, but the rest of studenthealth doesn't. Hence this rule attempts to protect against sslstripping.
         Cert error unavoidably occurs (would occur even without this rule) -->
   <rule from="^http://studenthealth\.ucsd\.edu/secure/" 
           to="https://studenthealth.ucsd.edu/secure/" />
   <rule from="^http://(www-)?act\.ucsd\.edu/(bsl/home|cgi-bin/[A-Za-z]+link\.pl|marketplace-sso|mytritonlink/view|myTritonlink20|student[A-Z][A-Za-z]+/[A-Za-z]+)" 
           to="https://$1act.ucsd.edu/$2" />

   <rule from="^http://accesslink\.ucsd\.edu/" 
           to="https://altng.ucsd.edu/" />
<!-- In the unlikely event these redirectors have subpages, make sure they don't break (at the cost of not protecting them) -->
   <rule from="^http://financiallink\.ucsd\.edu/$"
           to="https://www-act.ucsd.edu/cgi-bin/financiallink.pl" />
   <rule from="^http://marketplace\.ucsd\.edu/$"
           to="https://www-act.ucsd.edu/marketplace-sso/signon" />
   <rule from="^http://(www\.)?(my)?tritonlink\.ucsd\.edu/$" 
           to="https://www-act.ucsd.edu/myTritonlink20/display.htm" />
   <rule from="^http://uclearning\.ucsd\.edu/" 
           to="https://a4.ucsd.edu/lms/" />
<!-- all acms redirects below -->
<!-- cri ultimately redirects to the ACMS homepage because the CRI dept was closed, although this rule is correct for the initial bounce. That isn't our problem
     TODO: These have subpages - resnet has been tested fairly well, but software and possibly iwdc need more testing. -->
   <rule from="^http://(cri|desktop|iwdc|resnet|software|sysstaff)\.ucsd\.edu/" 
           to="https://acms.ucsd.edu/units/$1/" />
   <rule from="^http://www-acs\.ucsd\.edu/$" 
           to="https://acms.ucsd.edu/index.shtml" />
   <rule from="^http://www-acs\.ucsd\.edu/account-tools/oce-intro\.shtml$" 
           to="https://acms.ucsd.edu/students/oce-intro.shtml" />
   <rule from="^http://www-acs\.ucsd\.edu/instructional/?$" 
           to="https://acms.ucsd.edu/students/" />
</ruleset>
-------------- next part --------------
<!-- This is not intended for inclusion as a separate ruleset. It should be merged with Wikipedia if it checks out ok. -->
<ruleset name="Wikipedia+">
   <target host="bits.wikimedia.org" />
   <target host="geoiplookup.wikimedia.org" />
   <target host="upload.wikimedia.org" />

   <rule from="^http://(bits|geoiplookup|upload)\.wikimedia\.org/" to="https://$1.wikimedia.org/" />
</ruleset>
-------------- next part --------------
<ruleset name="YouTube (partial)">
<!-- Known sources of mixed content (some are blocked by ABP EasyList/EasyPrivacy):
    *Tracking requests made by Vevo/other monetized videos to www.youtube-nocookie.com
    *googletagservices script: mostly videos w/ ads and user pages
    *IPv6 testing (IFRAME from ipv6-exp.l.google.com subdomains): randomly
    *User page backgrounds ^http://i[1-4]\.ytimg\.com/bg/ default to insecure HTTP, and they break when forced to HTTPS.
     The video bitstream itself doesn't support https, but Firefox doesn't warn about insecure object subrequests.
-->
<!-- Needs more testing:
    -Some channel/rights-holder logos ^http://i[1-4]\.ytimg\.com/i/.+/1\.jpg seem not to use/support HTTPS, but some do. (Fixed?)
    -youtube-nocookie has bad cert: http://www.google.com/support/forum/p/youtube/thread?tid=0d4388331eea7870
     Would rewriting it to youtube.com trip any XSRF protection?
    -Subdomains which may not support https:
     accounts.youtube.com
     apiblog.youtube.com
     upload.youtube.com
     Regional domains are intentionally not handled here. Use the "complete" YouTube ruleset instead
-->
   <target host="youtube.com" />
   <target host="www.youtube.com" />
   <target host="ads.youtube.com" /><!-- Promoted Videos signup/control page. NOT an ad server -->
   <target host="img.youtube.com" />
   <target host="insight.youtube.com" />
   <target host="youtu.be" />
   <target host="s.ytimg.com" />
   <target host="i.ytimg.com" />
   <target host="i1.ytimg.com" />
   <target host="i2.ytimg.com" />
   <target host="i3.ytimg.com" />
   <target host="i4.ytimg.com" />

   <rule from="^http://(www\.)?youtube\.com/$" to="https://www.youtube.com/" />
<!-- http://www.youtube.com/?v=foo normally redirects to http://www.youtube.com/watch?v=foo -->
   <rule from="^http://(www\.)?youtube\.com/\?v=" 
           to="https://www.youtube.com/watch?v=" />
<!-- This whitelist approach won't break embeds, but it won't protect them either. 
     Some of the items were obtained by looking at robots.txt and may no longer be in use. -->
<!-- TODO: I'm not a registered YouTube user, so this list is incomplete. E.g. what URL is used for adding subscriptions? Finally, "live" needs more testing. -->
   <rule from="^http://(www\.)?youtube\.com/(all_comments|artist|bulletin|channels|comment|create|creators|dev|forgot|img|inbox|index|live|login|movies|music|my_speed|playlist|profile|redirect|results|select_3d_mode|show|signin|signup|social|t/|user|verify_age|video_response_view_all|videos|view_play_list|watch|ytmovies)" 
           to="https://www.youtube.com/$2" />
<!-- Now attempt to handle user pages accessed without the "user" folder -->
   <rule from="^http://(www\.)?youtube\.com/([A-Za-z0-9]+(#.*)?)$" 
           to="https://www.youtube.com/$2" />

   <rule from="^http://(ads|img|insight)\.youtube\.com/" to="https://$1.youtube.com/" />

<!-- I recall seeing query parameters ?a and ?hd=1; I'm not sure what the former does if anything. Where's documentation on these parameters?
     Also, the target normally contains a tracking parameter &feature=youtu.be which I'd prefer to avoid -->
   <rule from="^http://youtu\.be/((-|\w){11})$"
           to="https://www.youtube.com/watch?v=$1" />
   <rule from="^http://youtu\.be/((-|\w){11})\?"
           to="https://www.youtube.com/watch?v=$1&#x26;" />
<!-- with the tracking parameter, it should technically be:
   <rule from="^http://youtu\.be/((-|\w){11})$"
           to="https://www.youtube.com/watch?v=$1&#x26;feature=youtu.be" />
   <rule from="^http://youtu\.be/((-|\w){11})\?"
           to="https://www.youtube.com/watch?v=$1&#x26;feature=youtu.be&#x26;" />
This will not protect URLs with malformed video IDs (possible improvement: use .{11}), but the risk shouldn't be too great
-->

   <exclusion pattern="^http://i[1-4]\.ytimg\.com/bg/" />
   <exclusion pattern="^http://(s|i[1-4]?)\.ytimg\.com/crossdomain\.xml$" />
<!-- why did this have {0,1} here before? Doesn't the question mark do the same thing? -->
   <rule from="^http://(s|i[1-4]?)\.ytimg\.com/" to="https://$1.ytimg.com/" />
</ruleset>


More information about the HTTPS-Everywhere-Rules mailing list