第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼，而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案)，像是早期的 U2F 以及今年定案的 WebAuthn。
We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other.
後面有猜測換過去的原因，可以看出因為 open source 加上 Google Chrome 團隊有強大的技術能力下，用 open source 軟體可以對 compiler 大量客製化各種功能，另外也是因為一個 compiler 就可以吃多個平台，可以省下一些跨平台的力氣 (像是相容性語法)。
而 Visual C++ 在商業支援與文件兩方面比較好的優勢，在這個情況下就顯得不是那麼重要了...
This one was painful. Yes, I have a bit of a Microsoft aversion, but I tried to keep an open mind. Read the full description of my Azure adventure. Expensive, apparently no IPv6, slow disk IO, and I couldn't figure out block storage options. Definitely not for me.
然後在測試 Azure 時的評語就更酸了：
Oh Azure! This one is going to get a bit ranty. I Spent a good 20 minutes clicking around the provisioning Web UI. To be fair, it is more geared to people needing to provision a lot of servers. Doing a single one like this is not the target audience as far as I can tell. But still, instead of presenting a couple of standard options and a way to build your own custom config, Azure gives you 92 options (depending on which region you select):
I also got super lost trying to figure out what it would cost to bring the VPS up to 500 GB of persistent storage. And then to make things even more confusing, when I started the virtual machine creation process and came to the "Choose your virtual machine size" step, I got a bunch of different options not included in the above list with most of them listed as "Not Available" including both the A4 v2 and F4 options I had so carefully located.
然後還有奇怪的 agent 在跑：
The Azure VPS also had the heaviest provisioning agent of all the ones I tested. It looks like it is doing a heartbeat once per second and doing a (non-ssl) GET request to an IIS server upstream asking it for a "GoalState". I listened and checked what the IIS server responded with. The response from the management server is in the GoalState addendum below. It is mostly self-explanatory, I think.
The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).
TTD supports recording of multiple threads in parallel, while rr is limited to a single core.
On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.