破 reCAPTCHA 的 Buster

在「用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA」與「reCAPTCHA 與語音辨識:以子之矛,攻子之盾」都提過用語音辨識功能破 reCAPTCHA,現在又有一套了,而且直接在各瀏覽器的 extension 平台上架:「Buster: Captcha Solver for Humans」。

說明可以看到一樣是透過聲音的部份辨識:

Buster is a browser extension which helps you to solve difficult captchas by completing reCAPTCHA audio challenges using speech recognition. Challenges are solved by clicking on the extension button at the bottom of the reCAPTCHA widget.

除了安裝很簡單以外,設定也弄得很簡單,這個套件支援多種不同語音辨識 API,包括 GoogleMicrosoft 以及 IBM 的服務,只要在套件的設定頁輸入 API key 就可以了...

另外剛好也跟 reCAPTCHA 有關,在 Hacker News 上的「Google's Captcha in Firefox vs. in Chrome (grumpy.website)」看到 Google Chrome 與 Mozilla Firefox 在跑 reCAPTCHA 的不同之處 (Chrome 的流程順很多,Firefox 卡很多),不過我覺得證據還有點弱,需要再看其他的測試...

另外裡面有提到一些奇怪的東西,像是 W3C 的替代方案 (這個組織提的東西...):「Inaccessibility of CAPTCHA」,找時間來研究一下...

測試 GFW 變成一個服務了...

針對分析在 GFW 牆內的情況,看到「GFWaaS - GFW as a Service」這樣的服務出現了,依據價位提供兩個不同等級的功能:

  • $49/month 是 HAR Logs + Screencasts
  • $199/month 則是再加上 Browser VNC

對於人不在中國,但需要照顧中國市場的開發團隊應該會有些幫助?

Tails 裡的注音輸入法終於修好了...

Tails 是一個獨立的 Debian 作業系統,強調匿名性,裡面有很多環境的預設值是為了避免 IP 位置以及其他資訊洩漏而設計。另外因為是獨立完整的作業系統,可以找台電腦用 USB 開機直接跑起來,避免 OS 被埋木馬的問題 (當然如果硬體有問題的話還是沒辦法)。

大多數人用 Tails 的人應該還是拿來跑 Tor Browser,不過我在用的時候發現注音輸入法有問題 (大約三年前?),就跑去開了一張 bug ticket 回報:「Bopomofo input for Chinese is not working」,從裡面的討論可以看到中間有 ping 我,但是我忘記回應了... 直到最近動了起來剛好有看到,就抓了 snapshot ISO 幫忙測了一下,畢竟沒幾個用注音的人在上面可以確認 :o

目前看起來輸入法本身的問題修差不多了,而且有機會在下個版本看到 (或是下下個版本,要看會不會進這次的 merge window)。

想要測試的人,除了要抓這個版本的 snapshot ISO 外 (在 bug ticket 裡有連結),在 Tails 開機時,要記得要在 Language 的地方選擇台灣:

開進去後就可以看到注音輸入法了,用 Super + Space 可以切換輸入法:(Super 通常指的是微軟鍵,或是 Mac 右邊的 Command 鍵,因為左邊的 Command 可能被當 Host key 了)

還有一些小 bug 要另外再處理 (像是切換輸入法的 input focus 會跑掉),不過比以前完全不能用好多了...

荷蘭認為 Cookie Wall 不符合對 GDPR 的規範

Update:弄錯國家了,是荷蘭...

Cookie Wall 指的是不同意接受 cookie policy 就無法使用網站的限制,像是這樣的東西:

在「Cookie walls don’t comply with GDPR, says Dutch DPA」這邊看到荷蘭認為 Cookie Wall 不符合 GDPR 的規範:

Cookie walls that demand a website visitor agrees to their internet browsing being tracked for ad-targeting as the “price” of entry to the site are not compliant with European data protection law, the Dutch data protection agency clarified yesterday.

後面應該會有訴訟,重點會在這...

儘量不使用 JavaScript 的前端設計...

在「A JavaScript-Free Frontend」這邊看到的,目前看起來還是很辛苦啊...

首先是可以看到他對 Asana 的抱怨:

First, I live in a rural area with only 2 Mbit/s down Internet connection. With a warm cache it takes 14 seconds for the Asana UI to become usable. Second, you can see below that the app is comprised of over 10MB of uncompressed JavaScript. That is a huge amount of code to execute. How is this acceptable?

現在前端頁面的 JavaScript 愈來愈大,除了下載時間之外,其實最卡的應該還是瀏覽器要處理編譯的時間。作者試著用現有的元素開發他的產品 Slimvoice,然後把心得整理出來... 其實還蠻考驗對 CSS 的基本功,有些東西是你根本不知道存在,另外有些東西是支援度的問題。

這個概念應該就是十多年前倡導的 Unobtrusive JavaScript,不過在這幾年前端框架雨後春筍般冒出來後就不太有人在管了 (一堆站台關掉 js 就不會動),而這也大幅「促進」了瀏覽器對 js 執行速度的改善...

Chrome 對各種 JavaScript 的優先順序

前陣子看到「JavaScript Loading Priorities in Chrome」這篇,在分析 Google Chrome 對各種 JavaScript 的優先順序。

優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」,另外文章裡也有整理建議「Where should this be used?」。

看起來 <script defer> at the end of <body> 是全部裡面最低的,建議是給 Load "Related articles" 或是 "Give feedback" 這類功能,不過應該沒什麼人真的這樣用...

然後要注意的是,這邊分析的對象是 Google Chrome,實際在設計時應該要先考慮一般性的定義,再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外,在「Preload Scripts」這邊看到的技巧,可以跟 browser 說明哪些資源比較重要,請儘快先下載:

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法,這個技巧應該用在會卡住頁面呈現的部分,確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面,理論上會更快:

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助,建議可以跑 A/B test 看看效果:

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

Twitch 用 VP9 直播...

Twitch 整理了一篇「How VP9 delivers value for Twitch’s esports live streaming」,說明他們用 VP9 的經驗談。

裡面有很大的篇幅是在講 VP9 與 H.264 的比較,不過這兩個用的技術就已經不是同一個年代了,沒有進步的話就不用出來玩了...

裡面有講到一些有趣的東西,像是提到是用 FPGA 即時壓縮:

In this article, we will show that the FPGA-based real-time VP9 encoding can deliver at least 25% bitrate savings compared to the highest-quality H.264 encoders deployed in Twitch’s production today.

然後提到 1080p60 至少省了 25% 的頻寬 (這邊應該是相較於 H.264):

VP9’s Compression Efficiency for Live 1080p60 Encoding: We Can Achieve At Least 25% Bitrate Savings

查了一下,在桌機上的瀏覽器都差不多支援了:

VP9 is implemented in these web browsers:

Chromium and Google Chrome (usable by default since version 29 from May and August 2013, respectively),
Opera (since version 15 from July 2013),
Mozilla Firefox (since version 28 from March 2014),
Microsoft Edge (as of summer 2016).

行動裝置的話 Android 4.4+ 有支援,但在 iOS 上沒有支援...

整體看起來普及率算是不低,可以引入當主力 codec 降低頻寬成本,當設備不支援 VP9 時 (應該只有 iOS 透過 Safari 觀看的情況) 就用 H.264 stream 提供服務。

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac,而不是講 app...

這次從高雄回來,在高鐵上想說用手機看看 Trac,發現桌機版的界面是會動,但在手機上不太好用,所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用),標語是「A responsive, flat, blue theme using Bootstrap」,拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整:

裝好後用手機測了一下,還是有不滿意的地方,不過改善不少了,先這樣撐著...