利用 pop 視窗藏起來的挖礦腳本

即使把主頁面關掉後,會因為藏起來的 popup window 而繼續挖礦:「Websites use your CPU to mine cryptocurrency even when you close your browser」,原文的 GIF 圖片就可以看出來怎麼做的了:

我是因為用了 One Window 可以避免有 pop window 產生 (都會被這個 extension 轉成 tab),另外用像是 hoshsadiq/adblock-nocoin-list 的 block ruleset 也不錯...

Amazon EC2 推出 T2 Unlimited,可以付費超量使用 CPU

Amazon EC2t2 系列的機器上推出 T2 Unlimited:「T2 Unlimited – Going Beyond the Burst with High Performance」。

這不是新的機種,而是現有的機器上可以超量使用 CPU credit,AWS 會另外收費。

新開的機器與已經開的機器都可以打開:

us-east-1 來算,其實相當便宜,看不出什麼 penalty fee:t2.micro 的 CPU credit 是 10% baseline,每小時單價是 $0.0116,所以先有個 100% 數字是 $0.116 的概念 (如果所有東西都是十倍)。

us-east-1 的 T2 Unlimited 是 $0.05 vCPU-hour,這樣看起來其實不賴?風險應該是在於不保證可以拿到多的 CPU resource...

可能要重新算一下 c4c5 的使用方式了...

另外雖然文章後面寫了一大串,但對照 region 表後,看起來是所有的區域都支援了:(美國政府的 region 除外)

You can launch T2 Unlimited instances today in the US East (Northern Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Canada (Central), South America (São Paulo), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Asia Pacific (Seoul), EU (Frankfurt), EU (Ireland), and EU (London) Regions today.

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

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.

Google 也發了一篇說明這個新功能:「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時,Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate,而不像 Google Chrome 的 workaround:

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

但這有必須有兩個假設成立才可以:

  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

新的 AWS 帳號將會自動啟用 Long EC2 Resource ID

新的 AWS 帳號將會自動啟用長版的 Resource ID:「New accounts default to long EC2 resource IDs on March 7」。

還是可以 opt-out 改回來,不過官方還是建議儘量用長的 ID 測試,因為今年年底將全面強迫使用:

We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.

Amazon API Gateway 支援 CORS 了

在「Enable CORS in Amazon API Gateway」這邊看到 Amazon API Gateway 支援 CORS (Cross-origin resource sharing) 了,這樣前端頁面就可以直接 call 進去使用了...

文件可以在「Enable CORS for a Method in API Gateway」這邊看到,主要就是這個頁面的設定:

看起來是個小功能,但卻影響很大... 這代表又有一大塊開發者會進去研究。

EC2 與 ELB 將會有更長的 Resource ID

EC2ELB 將會有更長的 Resource ID:「Heads-Up – Longer EC2 & EBS Resource IDs Coming in 2016」。

重點在這段:

The new IDs will be the same format as existing IDs, but longer. The current ID format is a resource identifier followed by an 8-character string, and the new format will be the same resource identifier followed by a 17-character string.

本來是 8 chars,之後會變成 17 chars。而用 SDK 的人只要更新到新版就可以了:

The SDKs are already compatible with longer IDs and don’t require any updates.

預定在 2016 年發生:

My colleague Angela Chapman wrote the guest post below to make you aware of longer instance, reservation, volume, and snapshot IDs that we will be rolling out in 2016.

EC2 Spot Instance 可以用 Capacity 競標了

前幾天 AWS 的「New – Resource-Oriented Bidding for EC2 Spot Instances」這篇文章提到 EC2 Spot Instance 可以用 capaciy 競標了,也就是以「資源的總量」來飆,而非指定某種型態的 instance。

以文章裡的例子來說,假設要標 488 個單位的 capacity,那麼有可能出現:

  • 2 x r3.8xlarge
  • 4 x r3.4xlarge
  • 8 x r3.2xlarge
  • 16 x r3.xlarge
  • 32 x r3.large

也有可能出現混搭的版本:

  • 1 x r3.8xlarge and 2 x r3.4xlarge
  • 2 x r3.4xlarge and 8 x r3.xlarge
  • 8 x r3.xlarge and 16 x r3.large

對於某種 spot instance 價錢突然提高時,可以改用其他 instance 繼續執行,變得更有彈性...

Amazon CloudFront 的新增功能

Amazon CloudFront 新增了 Whitelist Header 的功能:「Deliver Custom Content With CloudFront」。

如同在 post 裡說明的:

If you choose the Whitelist option, each header that you add to the list becomes part of the cache key for the URLs associated with the distribution.

有點像是 HTTP 協定裡 Vary 想要解決的問題,只是做在 CDN 這端。這個功能蠻多 CDN 都有,AWS 總算補上了...

這次除了可以針對 custom HTTP header 處理外,CloudFront 還做了不少事情:

  • Mobile Device Detection
  • Geo-Targeting
  • Multi-Site Hosting
  • Protocol Detection
  • CORS (Cross Origin Resource Sharing)

前兩項還蠻有意義的,這代表會有人幫你更新資料。而 CloudFront 總算是支援 CORS 了...