iOS 12.5.6

早上發現 iPhone 6 Plus 被自動更新到 iOS 12.5.6,查了一下發現是八月底的時候 Apple 推了一版 WebKitACECVE-2022-32893:「About the security content of iOS 12.5.6」。

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Description: An out-of-bounds write issue was addressed with improved bounds checking.

上個更新的版本 12.5.5 是 2021/09/23 出的,本來大家都以為已經沒有任何更新了,沒想到居然回過頭來發了一包,照蘋果的敘述看起來是因為這個洞被廣泛使用的關係?

iPhone 5S (目前 iOS 12 支援列表裡最早出的手機) 是 2013 下半年出的,到現在也九年了...

因應 Manifest V3 而推出的 uBlock Minus (MV3)

前幾天在 Hacker News 上看到「“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 (github.com/gorhill)」這個,裡面是 uBlock Origin 的作者 Raymond Hill 針對 Manifest V3 的半殘版,取名為 uBO Minus (MV3):「Add experimental mv3 version」。

在這個版本裡會有不少的功能失效,尤其是用的很多的 cosmetic filtering:

- No cosmetic filtering (##)
- No scriptlet injection (##+js)
- No redirect= filters
- No csp= filters
- No removeparam= filters

這個版本應該是打算要提供給 Manifest V2 被 Google 廢掉後還在用 Google 控制的瀏覽器的人,依照「Manifest V2 support timeline」這邊看起來是明年一月:

Ubuntu 下面搞 Multi-home 架構

家裡的 internet 架構大概是這樣 (省略過其他裝置):

一邊是 HiNet 的線路直接接中華的數據機 (modem),這段是用 PPPoE 撥接;另一邊是第四台網路 (北都),另外上面寫的 Switch 應該是 IP 分享器 (一台 ASUS 的機子,刷 DD-WRT),作圖的時候寫錯了...

最後是電腦的部份,我的桌機是跑 Ubuntu,用兩張個不同的實體線路 (界面分別是中華的 enp4s0 與第四台的 enp6s0f0) 接到了這兩個不同的網段上面。

打算跑 source routing 的架構來善用兩邊的頻寬,想法上面大概是這樣拆解:

  1. 機器本身有個 192.168.3.x 的 static ip。
  2. 針對 source ip 是 192.168.3.x 的封包,預設會往 192.168.3.254 這台分享器丟,然後 NAT 出去。
  3. Squid 在本機上跑一個 proxy server,指定 source ip 是 192.168.3.x

有了這樣的架構,我就可以在瀏覽器上面就透過 SwitchyOmega 這類的套件,指定某些網段要走第四台的頻寬出去了。

另外可以指定 http proxy 的服務也可以透過這個方法往第四台的線路連出去。

其中第二點需要把 source ip 是 192.168.3.x 的封包丟到 192.168.3.254 這段需要一些設定,首先是需要設定一個獨立的 routing table,我是在 /etc/iproute2/rt_tables 裡面放:

2       second

然後因為我是透過 NetworkManager 在管理網路界面的,我希望在 enp6s0f0 啟動時自動設定這個 source routing 邏輯,所以我在 /etc/NetworkManager/dispatcher.d/99-enp6s0f0 這邊寫了:

#!/bin/bash

interface=$1
event=$2

if [[ "$interface" == "enp6s0f0" && "$event" == "up" ]]; then
    ip route add default via 192.168.3.254 table second
    ip rule add from 192.168.3.0/24 table second
fi

然後要記得把這個檔案 chmod 755 讓他可以執行。

接著是 Squid 的設定,在 /etc/squid/squid.conf 裡面這樣寫:

#
http_access allow all
#
access_log /var/log/squid/access.log squid
cache deny all
cache_dir null /tmp
cache_log /dev/null
cache_mem 8 MB
dns_v4_first on
forwarded_for off
http_port 3128
tcp_outgoing_address 192.168.3.x

其中最後的 192.168.3.x 換成自己的固定 IP address。這邊因為 traffic 基本上都是 HTTPS 了,也不需要開 cache,就這樣設定...

這邊比較特別的是 dns_v4_first 的設計,這個是讓 Squid 儘量用 IPv4 的位置連線。這是因為北都的網路沒有提供 IPv6 位置,所以如果網站的 DNS 如果有 IPv6 位置的話就會從 HiNet 這邊的 IPv6 出去了...

另外 ping 與 MTR 之類的工具不會動在這這樣的架構下是正常的,因為這些工具會自己組合 raw packet 丟,不是透過 Linux 的 network stack 處理,所以不會被我們指定的 ip rule 解析。網路上看起來是有方法可以 mitigate,但我就先放著了...

這樣看起來還算堪用,先這樣用一陣子看看... 先前是在 Raspberry Pi 上面跑個 proxy server 導流量,但會受限於 Raspberry Pi 的硬體限制,效能上面就普普通通,現在直接用桌機拼看看...

網頁大小 14KB 與 15KB 的速度差異

Hacker News 上看到「Why your website should be under 14kB in size」這篇,對應的討論在「A 14kb page can load much faster than a 15kb page (endtimes.dev)」,在講網頁大小 14KB/15KB 的速度差異比 15KB/16KB 大很多的問題:

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

原因是 TCP slow start 造成的:

This is because of the TCP slow start algorithm.

而網頁這邊 TCP slow start 目前大多數的實做都是 10 packets 後發動:

Most web servers TCP slow start algorithm starts by sending 10 TCP packets.

然後再組合 1500 bytes/packet 以及 overhead,就差不多是 14KB 了:

The maximum size of a TCP packet is 1500 bytes.

This this maximum is not set by the TCP specification, it comes from the ethernet standard

Each TCP packet uses 40 bytes in its header — 16 bytes for IP and an additional 24 bytes for TCP

That leaves 1460 bytes per TCP packet. 10 x 1460 = 14600 bytes or roughly 14kB!

然後 HTTP/3 也可以看到類似的設計 (出自「QUIC Loss Detection and Congestion Control」:

Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses. Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead.

算是一個小知識... 但對於現在肥滋滋的網頁效果來說就沒辦法了,而且考慮到大一點的網站會在一個 TCP 連線裡面可能會傳很多 request,其實早就超過 TCP slow start 的門檻了。

CSS 的 :has() 有新進展了

在「Using :has() as a CSS Parent Selector and much more」這邊看到 Safari 宣佈對 :has() 的支援,查了一下 Can I use... 上面的資料「:has() CSS relational pseudo-class」,看起來是從 15.4 (2022/05/14) 支援的。

隔壁 Google Chrome 將在下一個版本 105 (目前 stable channel 是 104) 支援 :has(),沒意外的話 Microsoft Edge 應該也會跟上去,看起來只剩下 Firefox 要開了。

先前在「Chromium 的 :has() 實做進展」這邊有翻一下進度,看起來 Chromium 這邊要進入收尾階段了。

等普及後一些延伸套件裡的寫法也可以用 :has() 來處理了,就不用自己在 javascript 裡面檢查半天...

南韓最高法院也對 Web Scraping 給出了類似美國的判例

也是上個禮拜在 Hacker News 上看到的新聞,南韓最高法院對於 web scraping 也做出了類似美國 HiQ Labs v. LinkedIn 案的判例:「Korean Supreme Court Provides Clarity on Web Scraping and Violation of the Relevant Korean Laws, including the Copyright Act and Information Protection Act (Supreme Court, 2021Do1533, May 12, 2022)」,原文似乎已經被 paywall,但可以從 Internet Archive 的「這邊」與 archive.today 的「這邊」讀到原全文。另外在 Hacker News 上的討論「The Supreme Korean court says that scraping publicly available data is legal (lexology.com)」。

hiQ 的案子之前有寫過,可以參考「hiQ 爬 LinkedIn 資料的無罪判決」這邊。

南韓最高法院認為這次的抓取公開資料不違反南韓的法令:

On May 12, 2022, the Korean Supreme Court held in Case No. 2021Do1533 that scraping publicly available data from a competitor’s website does not violate the asserted laws, including the Copyright Act and the Act on Promotion of Information and Communications Network Utilization and Information Protection (“Information Protection Act”).

比較特別的是在講刑事責任的第三點提到了 read only,不確定是不是反駁原告的立論:

The Supreme Court also found Defendants not guilty of violating the Criminal Code in light of the following findings: (i) the Defendants’ act of scraping did not interfere with information processing on Yanolja’s API server; (ii) the Defendants’ act of scraping did not interfere with Yanolja’s booking business; (iii) the Defendants did not interfere with Yanolja’s business, because its scraping did not modify data within Yanolja’s API server; and (iv) the Defendants lacked mens rea for criminal interference with business, as the Defendants merely intended to collect accommodation information from Yanolja’s API server.

整體看起來是被告的大獲全勝?

在 Ubuntu 20.04/22.04 下使用 18.04 的 chromium-browser

Ubuntu 20.04 之後包的 chromium 都是基於 snap 的方案,是個除了 Canonical 的人以外沒人愛的東西,所以大家都在找方法改回 .deb 的版本。

剛剛因為需要測試東西所以才需要找這個方案,發現有個還蠻有趣的解法,是拿 18.04 的 chromium-browser 的套件來裝,因為官方至少會支援到 2023/04:「Is it still possible to install Chromium as a deb-package on 20.04 LTS using some third-party repository?」。

一個 /etc/apt/sources.list.d/bionic-update.list

deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe

另外一個 /etc/apt/preferences.d/chromium-deb-bionic-updates

Package: chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg 
Pin: release a=bionic-updates
Pin-Priority: 900

完全還是使用官方套件的解法,唯一的缺點大概就是到明年四月而已,但對要測試來說夠用了...

CloudFront 支援 HTTP/3

雖然 HTTP/3 還沒有進到 Standard Track,但看到 CloudFront 宣佈支援 HTTP/3 了:「New – HTTP/3 Support for Amazon CloudFront」。

只要在 CloudFront 的 console 上勾選起來就可以了:

看了看 RFC 9114: HTTP/3 文件裡的描述,client 可以試著建立 UDP 版本的 QUIC 連線,但要有機制在失敗時回去用 TCPHTTP/2 或是 HTTP/1.1

A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

另外一條路是在 TCP 連線時透過 HTTP header 告訴瀏覽器升級:

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

像是這樣:

Alt-Svc: h3=":50781"

然後 client 就可以跑上 HTTP/3:

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

另外在 FAQ 裡面有提到啟用 HTTP/3 是不另外計費的,就照著本來的 request 費用算:

Q. Is there a separate charge for enabling HTTP/3?

No, there is no separate charge for enabling HTTP/3 on Amazon CloudFront distributions. HTTP/3 requests will be charged at the request pricing rates as per your pricing plan.

先開起來玩看看...

用 GPT-3 產生 Hacker News 上熱門文章的摘要

看到「Autosummarized HN」這個工具,算是一個組合技的應用:

All summaries have been generated automatically by GPT-3. No responsibility is claimed for their contents nor its accuracy.

透過 GPT-3 解讀並產生出摘要,目前頁面上是沒有 RSS feed,但可以透過一些工具直接拉出來 (像是 PolitePol),然後就可以掛到 Slack 或是 RSS reader 裡面...

iOS Safari 擋 "Open in App" 的付費套件 Banish

在「New iOS App Blocks Those Annoying 'Open in App' Pop-Ups in Safari」這邊看到 John Gruber 的介紹文章「Banish: New Safari Extension to Block 'Open in App' Dickpanels」,裡面提到的 extension 在「Banish for Safari」這邊,一次性的費用,在台灣是 NT$70。

裡面的 screenshot 給了還蠻清楚的說明:

設定上面因為會牽扯到 privacy 的關係,會有點麻煩,需要開好幾個地方。

順道一提,桌面上的話可以透過 Annoyances 系列的 list 在 uBlock Origin 上擋。