Home » Computer » Software » Browser » Archive by category "GoogleChrome" (Page 3)

Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了

Twitter 上看到的:

WoSignStartCom 的移除會發生在 61 版,而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明,stable 應該會在九月出 61 版而生效:

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

除了 DNS 的 TTL 外,還有瀏覽器本身的 cache time...

在看「Reviewing Fastly’s New Approach To Load Balancing In The Cloud」這篇的時候被提醒:

However, most browsers have implemented their own caching layer that can override the TTL specified by the server. In fact, some browsers cache for 5-10 minutes, which is an eternity when a region or data center fails and you need to route end users to a different location.


結果 IE 在「How Internet Explorer uses the cache for DNS host entries」直接說三十分鐘 XDDD 這篇文章是 2011 年更新的,所以至少到 IE9 都是對的?

Internet Explorer 4.x and later versions modify how DNS host entries are cached by decreasing the default time-out value to 30 minutes.

Firefox 的值可以從 Mozilla networking preferences 這邊對 network.dnsCacheExpiration 的說明看到是 60 秒。

Google Chrome 沒找到官方的說明...

不過這可以知道當你要換 IP address 時,如果可以讓新舊 IP 都提供服務的話,至少規劃半個小時會比較保險。如果有其他理由而沒辦法同時提供服務的話,至少公告步驟裡要有「重開瀏覽器」這塊。

而作業系統自己的 cache 又是另外要計算進去的事了...

利用手機的 sensor 取得 PIN 碼

把 side-channel information 配合上統計方法就可以達到 74% 的正確率:「Phone Hack Uses Sensors To Steal PINs」。

透過 browser 的 javascript 就可以拉出這些資料,然後利用這些資料去猜你的手機 PIN 碼:

Researchers from U.K.-based Newcastle University created a JavaScript app called PINlogger.js that has the ability to access data generated by the phone’s sensors, including GPS, camera, microphone, accelerometer, magnetometer, proximity, gyroscope, pedometer and NFC protocols.

而且當可以多抓到更多資訊時 (像是第二次輸入) 準確度就更高了:

Using a sample set of 50 PINs, researchers found that their script was able to correctly guess a user’s PIN 74 percent of the time on the first try, which increases to 86 and 94 percent success rates on the second and third attempts.

有些瀏覽器有做一些修正,讓 side-channel information 變少,於是難度變高:

As for Firefox, starting from version 46 (released in April 2016), the browser restricts JavaScript access to motion and orientation sensors. Apple’s Security Updates for iOS 9.3 (released in March 2016), suspended the availability of motion and orientation data when the web view is hidden, according to researchers.

Google 則是沒修:

As for Google, it’s unclear what measures have been taken. “Our concern is confirmed by members in the Google Chromium team, who also believe that the issue remains unresolved,” the report stated. Google did not reply to a request to comment for this report.

這攻擊方式頗不賴... @_@

Google Chrome 的 Headless 模式與 PhantomJS 的歷史

瀏覽器的 headless 模式讓開發者可以透過 command line 或是 API 界面操作,對於自動化開發測試很有用。而 Google Chrome 將在 59 版 (目前 57 版) 引入 headless 模式:「Headless mode」。

Headless mode allows running Chromium in a headless/server environment. Expected use cases include loading web pages, extracting metadata (e.g., the DOM) and generating bitmaps from page contents -- using all the modern web platform features provided by Chromium and Blink.

To use headless, start Chrome with a command line flag:

$ chrome --headless --remote-debugging-port=9222 https://chromium.org

PhantomJS 則是因為 Google Chrome 決定要支援 headless 模式,主要的貢獻者 Vitaly Slobodin (參考 Contributors to ariya/phantomjs 這邊) 決定退出維護:「[Announcement] Stepping down as maintainer」。


Google 宣佈對 Symantec 發行的 SSL Certficiate 的不信任計畫

GoogleRyan Sleevi 宣佈了對 Symantec 所發佈的的 SSL Certificate 的不信任計畫:「Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates」。

這邊講「不信任計畫」,主要是因為 Google Chrome 不是打算移除,而是限制 Symantec 發出的 SSL certificate 的有效期限。這有種 too big to fail 的感覺...

以市占率來看,無論是「Usage of SSL certificate authorities for websites」這邊算出來的 15.4%,或是「SSL Market Share Report」這邊算出來的 24%,移除的影響都是巨大無比,再加上歷史上最早一批 CA 公司幾乎都被 Symantec 買進去 (像是 VerisignThawte):

This compatibility risk is especially high for Symantec-issued certificates, due to their acquisition of some of the first CAs, such as Thawte, Verisign, and Equifax, which are some of the most widely supported CAs. Distrusting such CAs creates further difficulty for providing secure connections to both old and new devices alike, due to the need to ensure the CA a site operator uses is recognized across these devices.


To balance the compatibility risks versus the security risks, we propose a gradual distrust of all existing Symantec-issued certificates, requiring that they be replaced over time with new, fully revalidated certificates, compliant with the current Baseline Requirements. This will be accomplished by gradually decreasing the ‘maximum age’ of Symantec-issued certificates over a series of releases, distrusting certificates whose validity period (the difference of notBefore to notAfter) exceeds the specified maximum.

也就是後面的每一個新版的 Google Chrome 都會降低對 certificate 可以設定的有效期限,直到降到九個月 (279 天):

The proposed schedule is as follows:
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)
Chrome 61 (Dev, Beta, Stable): 21 months validity (651 days)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)


Therefore, we propose to remove such indicators, effective immediately, until Symantec is able to demonstrate the level of sustained compliance necessary to grant such trust, which will be a period no less than a year. After such time has passed, we will consider requests from Symantec to re-evaluate this position, in collaboration with the broader Chromium community.

接下來看 Mozilla 端會不會有類似的動作了...

修改 User-Agent 讓 Office 365 服務變快...

Facebook 上看到剛剛在 Hacker News 上熱起來的「Onedrive is slow on Linux but fast with a “Windows” user-agent (2016)」這篇,引用了 2016 年在 Microsoft Community 上的討論:「Onedrive for Business open is very slow on Linux (Chrome/Firefox) but with very fast with a "Windows" user-agent」。

Reddit 的「Office 365 Onedrive looks at user-agent to determine performance.」有更多的討論。

因為工作上也會用到 Office 365,也覺得在 Ubuntu 上用起來超級慢,然後看到有使用者也講了 Linux 下的 Google Chrome 也會有類似的問題:

I just tried this same thing--changing the OS in the user agent--on Chome on Linux. The difference really is incredible. Normally I find 365 to be so slow as to be borderline unusable, now it's almost as quick as Google docs. Even the institutional log-ins for my university are faster.

EDIT: Just to clarify, I was testing specifically the web apps for Word and OneNote hosted by my uni. I tried loading them both in normal tabs and ones where I had changed the OS useragent in Chrome's developer panel. The normal tabs hung badly as usual (30+ seconds to load the UI), while the modified tabs loaded very quickly. I tried this several times, but I suppose YMMV.

所以我也拿「User-Agent Switcher for Chrome」加上 IE11 的 user-agent 後測試:

最明顯的差異就是 redirect 變少了,然後開 Word 與 Excel 的速度變快好多 @_@


As Office 365 for Business services(e.g. SharePoint Online, including OneDrive for Business, Exchange Online) are not supported on Linux as shown below, for the best experience, we recommend the operating system listed in the article.

所以只能拿老招出來,把 User-Agent 改成 IE 後就變得超~級~快~

然後最 helpful 的回答是:

Thank you
I go back to Google Apps suite.


在 Ubuntu 上跑 Selenium (Google Chrome 與 Firefox)

最近可能會用到,所以開了一台 EC2 instance 跑 Ubuntu 16.04 測試 Selenium。拿 ChromeFirefoxLinux 平台上兩個主要的瀏覽器。

要讓他動還蠻簡單的,只是不知道真的用下去後,後面會遇到多少地雷 XDDD

基本上是按照「Installing Selenium and ChromeDriver on Ubuntu」這篇文章的方法安裝,有幾點可以注意一下:

  • ChromeDriver 可以翻一下最新版,文件上寫的是 2.26,但現在最新的是 2.27 (寫這篇時)。
  • 雖然寫「(Optional) Create and enter a virtual environment」表示可以不做,但不做其實不會動 (看錯誤訊息像是要建立目錄時權限不夠),所以乖乖的用 virtual environment 裝在自己目錄下吧 XDDD

同理,Firefox 用 APTfirefox 套件後,再去抓 geckodriver 回來裝。一樣是照文章裡 chromedriver 的方式放,並且設定連結。

原文 Python 程式裡本來的 driver = webdriver.Chrome() 改成 driver = webdriver.Firefox() 就 ok 了。


V8 對 for-in 的最佳化

V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」,比較直接的結果就是維基百科Facebook 都變快了:

For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.

可以看得出來是挑比較大的來改,而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致:

The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.

主要是因為 spec 對 for-in 的定義寫得很模糊,所以就有很多實作的空間可以調整:

When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.

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」解釋這個新功能。