[HTTPS-E Rulesets] Tweaks - 1&1 Internet, Adobe, Broadband Reports, Cloudflare, Flickr, Github, Google Services

[Christopher Liu]

To whom it may concern:

This message concerns functional changes to existing rulesets (as they
currently exist in the Git repository). The next message will contain
more of the same, as I've split things for length reasons.
(I previously mentioned "commenting and stylistic issues," but I'll
hold those for later. Sorry I've been busy...)

1&1 Internet:
https://www.1and1.com now works; 1and1.com and order.1and1.com now
redirect to the www domain, regardless of protocol. All of these have
(separate) valid certs, but this implies that we should be rewriting
to the www domain.

Adobe:
Why are you redirecting all of www.macromedia.com to www.adobe.com?
I'm guessing this has something to do with Colonel Graff's testing
scripts, which would have noticed the redirection on the homepage.
However, I originally requested that rule because of the Flash Player
Settings Manager, for which the server does not perform such
redirection.
https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html
is a documentation page, and the actual Settings Manager is on
https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager02.html
through https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager09.html
.
There is also a Flash object
https://www.macromedia.com/support/flashplayer/sys/settingsmanager.swf
and a subrequest
https://www.macromedia.com/support/flashplayer/sys/settingsmanager2.swf?defaultTab=g_privacy
(where the query parameter varies depending on which Settings Manager
page is being viewed).
--To avoid breaking the Settings Manager, it's probably better to do a
trivial rewrite and let the server redirect however it wants.--
Also, the target element for www.macromedia.com (with the www) is missing.

Broadband Reports:
Some pages use a tracking(?) pixel i.dslr.net/1ptrans.gif , which has
an equivalent at https://secure.dslreports.com/i/1ptrans.gif .
(Whether the insecure version appears is somewhat random; it's
probably a server-side caching issue, depending on whether the last
person viewed the page in http or https.)

CloudFlare:
blog.cloudflare.com now has valid https; it should be moved from
Posterous-clients to here.
Also add cfdnscheck.cloudflare.com (the latter is for the script
https://cfdnscheck.cloudflare.com/test.js at least on said blog;
possibly on other sites, as it seems to be for DNSChanger detection)

Flickr:
The domains farm9.staticflickr.com and farm9.static.flickr.com have
existed for at least a couple weeks. (Example:
https://secure.flickr.com/groups/65611869@N00/ currently contains
https://farm9.staticflickr.com/8003/6967681706_d883bbf55c_t.jpg - I'm
having trouble finding an example of the static.flickr one, but I know
I've seen it somewhere. I did use nslookup to verify that both exist
and resolve identically.)
At this rate we will probably see farm10 in a few months, so we might
want to use \d+ .
I am fairly sure the domain sets "staticflickr" and "static.flickr"
are supposed to contain the same numbers. (The numbers past 7 do exist
in static.flickr; I was overly cautious when explaining this
originally.)

Github:
Is "secure.guag.es" a misspelling, given that secure.gaug.es appears
elsewhere in that ruleset?

Google Services:
goo.gl currently appears to support https just fine. I couldn't find
it in any of the Google rulesets; I'm guessing it belongs w/ Services.

As usual, thank you for your time and help.

C. Liu