看到「Debug Visualizer」這個 extension,在 VS Code 裡把 debug 過程視覺化:
沒有在用 VS Code,不過這個功能對於需要在腦袋裡面模擬時的 loading 抽出來,看起來還不錯啊 XD
幹壞事是進步最大的原動力
看到「Debug Visualizer」這個 extension,在 VS Code 裡把 debug 過程視覺化:
沒有在用 VS Code,不過這個功能對於需要在腦袋裡面模擬時的 loading 抽出來,看起來還不錯啊 XD
在「2020 Chrome Extension Performance Report」這邊看到有人對 Chrome Extension 上前一千名的效能分析,作者有提到是在 GCP 上的虛擬機測試的,跑七次取中位數:
I ran these tests on an n2-standard-2 Google Cloud instance, the numbers in this report show the median of 7 runs.
在「Chrome Extension Performance Lookup」這頁可以直接互動查詢,像是丟入 block
找跟擋廣告有關的關鍵字可以看到:
只看一般性的 blocker (中間還有 VPN 與一些不是一般性的先跳過),沒什麼意外的 uBlock Origin 的表現很好。
文章內的說明也可以翻一下,看看有沒有哪些 extension 其實不是很必要,但卻榜上有名,可以考慮拔掉省時間與資源...
上個禮拜四家裡的桌機開不了機,找了一天發現是系統的 SSD 掛掉了,就買了張 M.2 SSD,然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04,但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮),加上前陣子系統從 Intel 平台換到 AMD,整個狀況變得超混亂之後,就變成一連串踩地雷的過程...
最一開始是 UEFI + LUKS 的安裝問題,本來想裝到 M.2 SSD 上面,但 Ubuntu 18.04 的 grub-install
就是硬寫到 /dev/sda
不能改:「“Unable to install GRUB in /dev/sda” when installing GRUB」,照著這篇的 workaround 用還是不行,最後放棄,直接生一顆 SATA SSD 接到 SATA Port 1,把 M.2 當作資料碟。
硬體相關的問題:
ifconfig
或是 ip link
這樣的指令)。軟體相關的問題:
pppoeconf
設定會比較好,然後可以改 /etc/ppp/options
加上 IPv6 的設定。現在至少是堪用的程度了,接下來就是不斷的補各種設定...
uBlock Origin 是一個在瀏覽器上擋廣告的軟體,以前在推廣的時候都只提到可以過濾掉網站上的廣告,大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD),但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」,大家接受度意外的爆高,不過這有點扯遠了,回到原來的主題上...
先介紹一下 uBlock Origin 的開發模式,除了一般的 stable 版本外 (「uBlock Origin」這組),另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組),這樣讓使用者比較容易安裝與測試,這個方式也可以在 Tampermonkey 上看到。
這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1
版上傳到 CWS 上後收到被拒絕上架的通知:「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。
拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」,也就是不能把目的不同的東西強迫使用者綁在一起使用:
Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose
後續的 1.22.5rc2
也被拒絕,然後他回信詢問了 CWS 官方,得到的仍然是罐頭回應,然後他就決定丟著 (而這個作法還蠻聰明的),接著這件事情就被丟著變成 PR 事件上了一些媒體,然後昨天就突然解了...
Google 最近的動作愈來愈多了,一方面在嘗試避免觸動反托拉斯法的情況,儘可能打壓這些擋廣告的套件...
uBlock Origin 在 2016 的時候 porting 到 Safari 上,但在 2018 後就沒有再更新了,維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。
主要就是蘋果要廢掉本來的 Extension API,而替代的框架裡沒有對應的 content filtering 能力,所以在新的框架內無法實做 uBlock Origin 的功能...
維護者的建議是換瀏覽器,但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞),所以維護者的建議就是換成 Firefox。
另外我自己會建議用看看 Brave,因為 Brave 已經決定,如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3),他們會繼續維持本來的相容性,所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。
是收到信件通知 (因為之前有開發一些 extension),裡面提到的重點主要是出自「Developer Program Policies」裡的兩項。
第一項是要求權限最小化:
Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.
第二個是你現在沒有實做的功能就不能要權限:
Don't attempt to "future proof" your Product by requesting a permission that might benefit services or features that have not yet been implemented.
這些新條文將會在 2019/10/15 生效:
Your extensions must be compliant with this policy by October 15th, 2019. You can learn more about these changes and how they may apply to you in our User Data FAQ.
在「用 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,包括 Google、Microsoft 以及 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」,找時間來研究一下...
在「DNS flag day」這邊看到 EDNS 的 workaround。
目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。
而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:
The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.
This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.
往下可以看到會做出改變的廠商包括了 Google 與 Cloudflare,可以預期 8.8.8.8
(8.8.4.4
) 與 1.1.1.1
(1.0.0.1
) 都會進行更新。
網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw
看起來會掛掉,不知道二月前會不會修正這個問題... XD
我的桌機平常都是跑 beta channel 的 Chrome,所以前陣子已經升級到 72,然後發現兩個問題:
從 dev console 可以看到問題都是 Referer
沒被送出,導致有檢查 Referer
的網站拒絕存取,後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則,裡面提到了:
Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:
Accept-Language
Accept-Encoding
Referer
CookieStarting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.
不確定這個設計的目的是什麼,但反正已經中獎了,總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一?)。
所以就先去 Tampermonkey 開 ticket,也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版):「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。
另外跟 Referer Control 的開發者回報這個問題,也修正出新版上架了,更新就生效了:「refererControlDisqus.html」。
目前看起來還有「Spoofs Lang」得修,不過這個軟體好久沒更新了,不知道有沒有機會...
我自己再用的 Trac 本來是走 HTTP 的 Authorization
header 登入,但這樣每次重開瀏覽器就要登入一次,覺得麻煩... 就想要找套件改成用 HTML form login。
目前比較有在維護的應該是 AccountManagerPlugin 這套,內建就支援本機密碼,也支援 plugin 掛其他外部服務進去。
但掛進去後發現本來的自動開票機 (i.e. 用 crontab 開票) 就沒辦法登入了,最後找到得用 HttpAuthPlugin 處理。這個套件一開頭就寫了他也是為了 XmlRpcPlugin 而寫的:
This plugin allows you to protect certain paths with HTTP authentication. The AccountManagerPlugin is used to check passwords.
Primarily this is meant to be used with the XmlRpcPlugin, so it will work while using AccountManager's form-based logins.
就是遇到同樣的問題...