Google Chrome 也要打開 DoH

Google Chrome 也要支援 DNS over HTTPS (DoH) 了,不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估?),會先判斷系統的 DNS 是否在支援 DoH 的清單內,在不改變 DNS 服務商的情況下,從本來的 UDP 查詢變成 DoH 查詢:「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到,除了 Google 自己外,也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77):

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

hiQ 爬 LinkedIn 資料的無罪判決

hiQ 之前爬 LinkedIn 的公開資料而被 LinkedIn 告 (可以參考 2017 時的「hiQ prevails / LinkedIn must allow scraping / Of your page info」),這場官司一路打官司打到第九巡迴庭,最後的判決確認了 LinkedIn 完全敗訴。判決書在「HIQ LABS V. LINKEDIN」這邊可以看到。

這次的判決書有提到當初地方法院有下令 LinkedIn 不得用任何方式設限抓取公開資料:

The district court granted hiQ’s motion. It ordered LinkedIn to withdraw its cease-and-desist letter, to remove any existing technical barriers to hiQ’s access to public profiles, and to refrain from putting in place any legal or technical measures with the effect of blocking hiQ’s access to public profiles. LinkedIn timely appealed.

而在判決書裡其他地方也可以看到巡迴庭不斷確認地方法院當時的判決是合理的,並且否定 LinkedIn 的辯解:(這邊只拉了兩段,裡面還有提到很多次)

In short, the district court did not abuse its discretion in concluding on the preliminary injunction record that hiQ currently has no viable way to remain in business other than using LinkedIn public profile data for its Keeper and Skill Mapper services, and that HiQ therefore has demonstrated a likelihood of irreparable harm absent a preliminary injunction.

We conclude that the district court’s determination that the balance of hardships tips sharply in hiQ’s favor is not “illogical, implausible, or without support in the record.” Kelly, 878 F.3d at 713.

到巡迴庭差不多是確定的判決了,沒有其他特別的流程的話...

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN),不使用 AWS 自己提供的串接服務,而是用 pfSense 串接。

會自己搞主要有幾個考慮:

  • 考慮到 AWS Transit Gateway 的費用,每掛一個上去就要多收一次錢,另外上面處理的流量要再收費。
  • 應用的流量不大,所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity,算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理,加上用戶端的網路本來就不怎麼穩定,AWS Transit Gateway 的 SLA 再怎麼高,我也還是得處理斷線時的後續機制,不如就不要那麼緊張...

在設定的時候要注意的事情:

  • EC2 的 Source IP/Destination IP 檢查要關掉,這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開,因為 pfSense 會丟出不屬於他自己 IP address 的封包,也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing),這些都還是會經過 Security Group 的檢查,而 Security Group 能設定的數量有限,基本上應該會全開...
  • pfSense 在設完 IPsec 後,同樣在 pfSense 上面的 firewall 需要手動加開,因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法,只是老方法還是很好用...

OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

OpenBSD 決定關閉 Firefox 預設的 DoH (DNS over HTTPS):「DoH disabled by default in Firefox」。

原因是 OpenBSD 的人認為,DoH 本身 ok,但是預設導去 Cloudflare 不 ok:

Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. ok landry@ job@

我覺得這槍開的很好 XD

用 PoW 當作防機器人的方式

看到「wehatecaptchas」這個服務試著用 PoW (Proof of work) 擋機器人...

這個方式不需要像 GooglereCAPTCHA 那樣蒐集大量行為 (對隱私不利),也不需要解一堆奇怪的圖片問題。

CAPTCHA 最常用的領域,也就是擋 spam 這件事情來說,PoW 這樣的單一方式應該是不夠,但可以當作綜合方法裡面的一種...

各種對 AWS Managemenet Console 的抱怨...

Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文,差不多是兩個月前開始累積的:「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主,而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發,然後呼叫 API),而且的確是常常中 bug,所以會有這樣的抱怨其實不太意外...

然後就有人放火了:

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了:

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念),而 AWS Managemenet Console 當作是輔助,因為目前的雲端服務在設計上的確是希望你多用 API...

用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時,會定義自己的 Message-ID,另外後續變更的通知信件會增加 References 欄位,讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 Message-ID 改掉,使用自己的 Message-ID 欄位,可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來,只剩下後續的信件因為有相同的 References,所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin,只要是沒有 References 的信件 (像是每張 ticket 的第一封信),就從 Message-ID 複製一份到 References 裡,這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好,所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

Canonical 推出的 Dqlite (High-Availability SQLite)

第一眼看到的時候直接有種不知道 Canonical 在幹什麼的感覺,翻完說明後大概知道可以用的地方,但還是覺得範圍有點小:「Dqlite - High-Availability SQLite」。

一種使用情境是,在 embedded system 上面同步資料的一種方案... 吧?例如網路連線的頻寬或是品質受限,無法順利傳到 Internet 端的伺服器上,所以希望在本地端就可以解決一些事情,但又不方便在本地端直接弄個 PostgreSQL 出來?

Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.

另外一個是用到了 C 實做的 Raft 協定:

Dqlite (“distributed SQLite”) extends SQLite across a cluster of machines, with automatic failover and high-availability to keep your application running. It uses C-Raft, an optimised Raft implementation in C, to gain high-performance transactional consensus and fault tolerance while preserving SQlite’s outstanding efficiency and tiny footprint.

讓 IoT 裝置參與 Raft 嗎... 好像只能說有趣... XD

Hacker News

早上看到「Tell HN: Thank you for not redesigning Hacker News」這篇,作者在網路速度受限的地區,上各種網站幾乎都不會動,但 Hacker News 沒有改用一堆前端框架,而是保留使用 HTML 反而讓頁面維持極小:

I’m currently in a country with low speed internet and the entire ‘modern’ web is basically unusable except HN, which still loads instantly. Reddit, Twitter, news and banking sites are all painfully slow or simply time out altogether.

To PG, the mods and whoever else is responsible: thank you for not trying to ‘fix’ what isn’t broken.

順手開了一下網路工具來看,發現單一元件最大的居然是 favicon XDDD:

Wikipedia 上列出來的相容性,如果只支援 IE11+ 的話,看起來可以改用 PNG,大小就已經有明顯的改善了:

-rw-r--r-- 1 gslin staff 7527 Sep  2 09:50 favicon.ico
-rw-r--r-- 1 gslin staff 2598 Sep  2 09:51 favicon.png

使用 RSS 的呼籲

在「Please Add RSS Support To Your Site」這邊看到文章作者在呼籲使用 RSS (這邊應該是包括 Atom)。

主要是 RSS/Atom 算是很成熟的架構了,有很多工具可以閱讀 (RSS/Atom Reader),提昇閱讀的效率。像我是用 Bazqux,另外也有不少人在使用 Feedly... 而除了訂閱外,RSS/Atom 也可以再串出去接其他東西,像是串到 IFTTT 後就可以接上 IFTTT 上面的應用程式。

除了文章作者的呼籲以外,我自己也對我自己常用的網站操作 (在 GitHub 上的 hasname/feedgen 這邊),把網頁結果轉成 RSS/Atom (裡面大多就是去讀 search 相關功能了),這樣有新東西就可以透過 RSS/Atom Reader 讀到...