如何評價Chrome瀏覽器加固修復幽靈漏洞：內存佔用將多出13%？

原文：Chrome瀏覽器加固修復幽靈漏洞：內存佔用將多出13%

這次修復也帶來了一個副作用，谷歌工程師CharlieReis表示，在高負載下，Chrome對內存的佔用將增加10-13%左右...Chrome在運行時會使用預載入的機制，佔用大量的內存，小內存電腦用Chrome時會比較吃力...從小雷個人的體驗來看，更新後的Chrome對內存的佔用的確比較大，4GB的內存很快所剩無幾，不過沒有出現明顯的卡頓情況。

原文鏈接 https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html

Charlie Reis這篇文章多多少少有一些標題黨吧。這篇文章的重點就是說Chromium的Site Isolation水平又升了一級。

這裡說說歷史吧。

從遠古時代的Chrome開始（具體多少我不知道），Chrome就做了一件事情就是Site Isolation，具體是不同的site會跑在不同的render process。這樣做一開始最大的好處就是一個網頁crash了不至於整個Chrome都crash掉或者其他網頁也crash。當然這個東西也有用戶是不喜歡的，因為需要佔用內存。有很多二手資料告訴你每個tab是一個process，那是謠言，並不是Chrome實際上的運行方式，不過Chrome確實有這個選項，可能是曾經的一個試驗引入的。

Site Isolation另外一個作用就是安全了，大家都喜歡搞溢出漏洞，確保能不同的site會跑在不同的render process，那要搞別人的難度就高了，搞自己沒意思。

但是曾經的Site Isolation其實有一個設計上的問題，就是沒有考慮跨域的iframe和彈出窗口。一開始這個沒有考慮，今天已經沒有文檔記錄這個決策的過程，但是從Site Isolation的實現過程（對，我也有給這個項目做出貢獻）往回看主要是實現難度，iframe需要跟main frame有API的交互，有Input上的交互，有layout上的交互。具體有多複雜，就是差不多blink裡面很大比例的方法從原來的直接調用變成需要提供一個RPC版本。還有一些判斷要從blink層面拉到browser的層面，因為現在main frame只能看到一個框了。

比如我做的scrolling和pinch zoom，以前滾動到iframe開始滾iframe然後繼續往下滾滾出iframe是很簡單的，現在滾iframe要rpc到iframe滾，然後iframe滾完還有告訴main frame滾。這還沒完滾動要考慮prevent default的問題，這個狀態又要傳出來傳進去，類似的touch action。

項目難度很大，要改動的代碼很多，前後項目動用的人員也很多。

這個項目在我入職Google之前就已經存在，應該是做了3年才算是做完了，這開始時間可比Spectre發現早多了，

至於內存增長的事情，你如果上的都是正經的網站根本沒多少跨域iframe，也就不存在什麼變化了。

無所謂，雖然32G 的RAM，但是Chrome經常內存佔用才40%左右就報資源不足錯誤了，內存佔多佔少無所謂，穩定性能再提高一些就好。。。

這樣吧，你是愛你的銀行卡密碼還是愛你的內存？