可以看到比較明顯的是 HTTPS 以及 HTTP → HTTPS Redirection 這兩塊：
不過用 Alexa 的資料有種怪怪的感覺啊... 在討論 HTTPS (有點在推廣的感覺)，但 Alexa 的網站現在是做反過來的 HTTPS → HTTP Redirection XDDD
一個多禮拜前引起蠻多討論的一篇文章，利用 Unicode Domain 釣魚的方法：「Phishing with Unicode Domains」。
由於這是幾乎完美的攻擊，所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論：
This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.
在 comment 8 提到：
We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.
在新版的 Chrome 58 已經「修正」了這個問題：
而 Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊，一開始就直接把票給關了 XDDD：
Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.
We can't go blacklisting standard Cyrillic letters.
If you think there is a problem here, complain to the .com registry who let you register https://www.xn--80ak6aa92e.com/ .
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WONTFIX
然後一個月前被提出來看看 Chrome 怎麼做：
Gerv/Valentin, is this something we can/should align with Chromium on?
目前唯一的解法是改 flag，把所有的 Unicode Domain 直接當作一般的 domain 來處理，列出像是
基本上是按照「Installing Selenium and ChromeDriver on Ubuntu」這篇文章的方法安裝，有幾點可以注意一下：
原文 Python 程式裡本來的
driver = webdriver.Chrome() 改成
driver = webdriver.Firefox() 就 ok 了。
As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow, this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.
Facebook 花了不少時間對付 reload 這件事情：「This browser tweak saved 60% of requests to Facebook」。
Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應：
In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.
而 Google Chrome 很明顯偏高：
於是他們找出原因後，發現 Google Chrome 只要 POST 後的頁面都會 revalidate：
A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.
We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.
但還是很明顯比起其他瀏覽器偏高不少，在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter)，Google Chrome 會當作 reload：
The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.
不過這次推出修正後發現沒有大改變：(拿 production 測試 XDDD)
Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.
後來是針對 reload button 的行為修改，
max-age 很長的就不 reload，比較短的就 reload。算是一種 workaround：
There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.
當 Facebook 的人找 Firefox 的人時，Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate，而不像 Google Chrome 的 workaround：
Firefox chose to implement this directive in the form of a
Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。
Those users have been enjoying the 400% increase in responsiveness and a 700% improvement when web pages are loading.
現在的 Firefox 是 50 版，目前的情況是當 extension 標成 multi-process compatible 就會啟用：
With Firefox 49 we deployed multi-process Firefox to users with a select set of well tested extensions. Our measurements and user feedback were all positive and so with Firefox 50 we deployed multi-process Firefox to users with a broader set of extensions, those whose authors have marked them as multi-process compatible.
下一個版本 (51) 則是會全面開啟，除非有 extension 標成 multi-process incompatible：
Beyond Firefox 50, we have more work to do to enable multi-process Firefox for users with as yet unsupported extensions. In Firefox 51, if all testing goes according to plan, we’ll be enabling multi-process Firefox for users with extensions that are not explicitly marked as incompatible with multi-process Firefox.
CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.
Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本)：「取消對 WoSign 與 StartCom 新簽發憑證的信任」。
這次比較麻煩的地方在於要信任已經發出的 certificate，而且量太大無法窮舉。所以必須改增加程式碼處理，而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案，沒辦法放特殊的邏輯進去...)
另外現在 Firefox 是 49 版，要到 51 版才會生效，看起來還會花一陣子...
這次的處分草案由 Kathleen Wilson 發出來，會包括這些 root certificate，可以看到包括了所有 WoSign 與 StartCom 的 CA：
1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL
Based on the information that I have seen regarding WoSign, I believe that WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL certs, when they knew full well that was no longer allowed. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies.
所以打算採取與 CNNIC 類似的處分方法，但很不幸的由於規模不一樣，所以被迫採用另外的方式來處理：
Therefore, I think we should respond similarly to WoSign as we did to CNNIC . Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described.
這次處分的過程會包括四個項目，第一個是在 Firefox 51 會用黑名單的方式將這些 root certificate 擋下，但會信任 2016/10/21 前所發出的憑證以降低對目前網站的衝擊：
1) Distrust certificates chaining up to Affected Roots with a notBefore date after October 21, 2016. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train .
-- The code will use the subject key id (hash of public key) to identify the Affected Roots, so that the control will also apply to cross-certs of the Affected Roots.
然後將之前簽出來的 SHA-1 憑證列入 OneCRL：
2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.
3) No longer accept audits carried out by Ernst & Young Hong Kong.
Gervase Markham 做了補充「永久」的部份：
To be clear, this is a permanent ban, applicable worldwide, but only to the Hong Kong branch of E&Y. (If further issues are found with E&Y audits elsewhere, then we might consider something with wider scope.)
最後一個是移除 NSS 裡包的憑證：
4) Remove the Affected Roots from NSS after the SSL certificates issued before October 1, 2016, have expired or have been replaced.
在討論裡有提到 Firefox 與 NSS 的處置日期不太一樣的問題 (一個是 10/21，一個是 10/01)，應該會在正式的定案時修正。
Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that we'd issued to WoSign: