Re-activate top-100 from #10538

[cschanaj]

#10536 #10538 I cannot do this all myself. Please mark this as a Good Volunteer Work. Thanks!

top-100

• ./https-everywhere/rules/Adobe.xml Re-activate and Update Adobe.xml, Delete Acrocomcontent.com.xml #10597
• ./https-everywhere/rules/Alipay.com.xml Re-activate and Update Alipay.com.xml #10547
• ./https-everywhere/rules/Apple.com.xml Re-activate and Update Apple.com.xml #10600
• ./https-everywhere/rules/BBC.xml Reactivate BBC.xml #10623
• ./https-everywhere/rules/Facebook.xml Re-activate and Update Facebook.xml #10567
• ./https-everywhere/rules/Instagram.xml Re-activate and Update Instagram.xml #10569
• ./https-everywhere/rules/LinkedIn.xml Reactivate LinkedIn.xml #10624
• ./https-everywhere/rules/Live.xml 10625
• ./https-everywhere/rules/Mail.ru.xml Reactivate Mail.ru.xml #10626
• ./https-everywhere/rules/PayPal.xml Re-activate and Update PayPal.xml #10566
• ./https-everywhere/rules/Pinterest.xml Update Pinterest.xml #10548
• ./https-everywhere/rules/PopAds.xml Re-activate and Update PopAds.xml #10570
• ./https-everywhere/rules/ThePirateBay.xml Re-activate and Update ThePirateBay related rulesets #10549
• ./https-everywhere/rules/Tumblr.xml Update Tumblr.xml #10550
• ./https-everywhere/rules/Twitch.tv.xml Re-activate and Update Twitch.tv.xml, Fix #4916 #10568
• ./https-everywhere/rules/Yahoo.xml Reactivate Yahoo.xml #10627
• ./https-everywhere/rules/Yahoo_Japan.xml Re-activate and Update Yahoo_Japan.xml  #9955
• ./https-everywhere/rules/YouTube.xml [Youtube] Reactivate ruleset #10564
• ./https-everywhere/rules/amazon.co.jp.xml Update amazon.co.jp.xml #10546
• ./https-everywhere/rules/hao123.com-mixedcontent.xml Reactivate hao123.com-mixedcontent.xml #10629

[Bisaloo]

facebook.com is preloaded. Proofs:

• https://hstspreload.org/?domain=facebook.com
• https://securityheaders.io/?q=facebook.com&followRedirects=on

[Bisaloo]

paypal.com is preloaded as well but is missing the preload header.

[Hainish]

Note: the relevant HSTS files to be checked for inclusion are those in the browsers we support:

Firefox Dev: https://hg.mozilla.org/releases/mozilla-release/raw-file/FIREFOX_54_0_RELEASE/security/manager/ssl/nsSTSPreloadList.inc

Firefox Stable: https://hg.mozilla.org/releases/mozilla-aurora/raw-file/tip/security/manager/ssl/nsSTSPreloadList.inc

Firefox ESR: https://hg.mozilla.org/releases/mozilla-esr52/raw-file/FIREFOX_52_2_0esr_RELEASE/security/manager/ssl/nsSTSPreloadList.inc

Chromium Stable: https://chromium.googlesource.com/chromium/src.git/+/59.0.3071.109/net/http/transport_security_state_static.json?format=TEXT

[Bisaloo]

@Hainish, but ultimately, those lists are pulled from hstspreload.org, right ? There is simply a delay before domains are included in the lists you mention.

This form is used to submit domains for inclusion in Chrome's HTTP Strict Transport Security (HSTS) preload list. This is a list of sites that are hardcoded into Chrome as being HTTPS only.

Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.)

That's how I understand this at least. Please tell me if I am mistaken.

[Hainish]

The browsers are based on the Chrome list, yes. But it may take a while before they are included in the browsers, so we don't want to remove the rules that are preloaded from the canonical source prematurely and leave them actually unprotected in the browsers.

[Hainish]

Also Mozilla has its own logic for removing preloaded domains, and it's often changing and not documented very well. So we can't count on the Mozilla implementation mirroring the Chrome list very closely.

[cschanaj]

I've just found out that Yahoo.xml was whitelisted in the ruleset-coverage-whitelist.txt. The file contain 2.4k+ lines and involves dozens of complicated rules, I don't think that anyone can re-activate it before the next release without paying significant effort ...

[Bisaloo]

I've just found out that Yahoo.xml was whitelisted in the ruleset-coverage-whitelist.txt. The file contain 2k+ lines and involves dozens of complicated rules, I don't think that anyone can re-activate it before the next release without significant effort ...

Agreed. This is why we should keep different domains in separate rulesets. Updating behemoths such as Yahoo.xml is no fun and this leaves all domains unprotected.

[cschanaj]

If nobody can re-activate Yahoo.xml before the next release, I suggest to revert the changes from 9bf49cb on Yahoo.xml and whitelist it again. This gives us the time to rewrite the ruleset while keeping the domain protected.

Remark: original file prior to the comprehensive-fetch Yahoo.xml

[Hainish]

It seems like at the very least we should remove the problematic domains flagged by the fetch test, even if we don't have time to go through the entire rule and simplify it.

[Hainish]

Closing, since this seems to be done now.

[J0WI]

Thanks!