搜尋引擎的替代方案清單

看到「A look at search engines with their own indexes」這篇在介紹各個搜尋引擎,作者設計了一套方法測試,另外在文章裡面也給了很多主觀的意見,算是很有參考價值的,可以試看看裡面提出來的建議。

另外在 Hacker News 上也有討論可以參考:「A look at search engines with their own indexes (2021) (seirdy.one)」。

在文章開頭的「General indexing search-engines」這個章節,先列出三大搜尋引擎 GBY (GoogleBingYandex),以及使用這三家當作後端資料庫的搜尋引擎,可以看到到處都是 Bing 的影子。

接著作者推薦 Mojeek 這個作為 GBY 的替代方案:

Mojeek: Seems privacy-oriented with a large index containing billions of pages. Quality isn’t at GBY’s level, but it’s not bad either. If I had to use Mojeek as my default general search engine, I’d live. Partially powers eTools.ch. At this moment, I think that Mojeek is the best alternative to GBY for general search.

在「Smaller indexes or less relevant results」這邊也有一些方案,像是這個章節第一個提到的 Right Dao,作者就給他了不錯的評價:

Right Dao: very fast, good results. Passes the tests fairly well. It plans on including query-based ads if/when its user base grows.

接下來的「Smaller indexes, hit-and-miss」與「Unusable engines, irrelevant results」也可以翻一下,看看作者怎麼批評 XD

然後是後面的「Semi-independent indexes」就出現了最近幾個比較有名的,像是 Brave Search 與目前我在用的 Kagi

整理的相當不錯...

HTTP 標準的翻新

HTTP 的標準之前都是用新的 RFC 補充與修正舊的標準,所以整體讀起來會比較累,對於開始了解 HTTP 的人會需要交叉讀才能理解。

而這次 RFC 9110~9114 算是一次性的把文件全部重新整理出來,可以看到蠻多人 (以及團體) 都有丟出來對應的看法,這邊丟這兩篇:「A New Definition of HTTP」與「HTTP RFCs have evolved: A Cloudflare view of HTTP usage trends」。

而這五個 RFC,從名稱列出來就可以看出來命名簡單粗暴,把核心概念先拆出來講,然後再講不同 protocol 的部份:

Cloudflare 這邊提供了一些資料,可以看到三個 protocol 使用率都算高,而目前最高的是 HTTP/2:

另外比較特別的是 Safari 在 HTTP/3 的趨勢居然有倒縮的情況:

然後 bot 的部份幾乎大家都支援 HTTP/2 了,目前還沒看到太多 HTTP/3 的蹤跡,倒是 LinkedIn 的 bot 有個奇怪的 adoption 然後全部 rollback 的情況,而最近又開始少量導入了:

這次看起來淘汰了 (obsolete) 很多之前的文件,以後要引用得往這五份來引...

25Gbps 下 HTTPS 的效率

作者家裡拉了 25Gbps 的 Internet 後 (可以參考先前寫的「25Gbps 的家用 Internet」這篇),然後發現 Internet 上好像拉不動 25Gbps 的量,所以自己在家裡先測試了現在 HTTPS 的極限速度:「25 Gbit/s HTTP and HTTPS download speeds」。

Client 是 AMD 的 5600X,算是目前最新的世代;Server 則是 Intel 的 9900K,目前最新應該是 12 代;測試用 35GB 的檔案來測,然後使用 TCP BBR (這邊沒有特別講,目前 kernel 內建的還是 v1)。

在單條 HTTP 的情況下 curl + nginx 與 curl + caddy 都可以直接跑滿 (23.4Gbps),Gonet/http 會卡在 20Gbps 左右。

如果是多條 HTTP 的話都可以跑滿 23.4Gbps。

但到了 HTTPS 的情況下最快的是 Go + net/http,可以跑到 12Gbps;curl + nginx 剩下 8Gbps;接下來 curl + caddy 的部份只有 7.5Gbps,而 go + caddy 只有 7.2Gbps。

上到多條 HTTPS 的情況大家都可以跑滿 23.4Gbps,除了 go + caddy 只能跑到 21.6Gbps。

另外作者試著用 kTLS 把 TLS 的工作丟進 kernel,就不需要全部在 nginx 內處理,速度基本上沒有太大變化,主要是降低了 CPU loading:

In terms of download speeds, there is no difference with or without KTLS. But, enabling KTLS noticeably reduces CPU usage, from ≈10% to a steady 2%.

算是一個有趣的發現,如果目前的 HTTPS 想要在 25Gbps 上面單線直接跑滿,還需要再 tune 不少東西...

HTTPS Everywhere 將在明年一月 (2023/01) 停止運作

在「Set Up HTTPS by Default in Your Browser」這頁看到的東西:

Note: HTTPS Everywhere will sunset in January 2023.

我把他 submit 到 Hacker News 上:「HTTPS Everywhere will sunset in January 2023 (eff.org)」,裡面有一些有趣的討論,像是這跟 Google 硬幹 Manifest v2 也有關:

It doesn't seem to be mentioned by the EFF, but coincidentally, January 2023 is when Manifest v2 extensions stop working in Google Chrome: https://developer.chrome.com/blog/mv2-transition/

但查了一下,目前好像沒有好的技術標準可以確保第一次的 HTTPS request。馬上想的到的是透過 DNS 的方式指定,這樣就可以透過 DNSSEC 保護不被竄改,但看起來沒有這個標準...

GitHub 可以在 Markdown 文件裡寫 TeX 語法了

Hacker News 首頁上看到 GitHub 上的「Render mathematical expressions in Markdown」這個公告:

You can now use LaTeX style syntax to render math expressions within Markdown inline (using $ delimiters) or in blocks (using $$ delimiters).

其中 TeX rendering 這塊是透過 MathJax 產生的:

GitHub's math rendering capability uses MathJax; an open source, JavaScript-based display engine.

我記得 MathJax 的效能好像不怎麼樣... 反正是跑在使用者端的 javascript?XD

GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了:「GOV.UK drops jQuery from their front end.」,Hacker News 上的討論也可以看一下:「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因,第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂,像是:

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類),可以注意 jQuery 1.0 就已經把基本界面都弄出來了,而 jQuery 1.0 是 2006 年八月出的,另外 IE7 是在 2006 年十月出,也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為,像是經典的 attachEvent (出自 DOM events):

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說,jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力,這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少,而且就算有了 querySelectorAll(),Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象,jQuery 其實也帶入了不少好用的 pattern,其中一個是 fluent interface 讓人寫起來很舒服:(這個範例只是要介紹 fluent interface,不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理:

$('#foo').css('width: 100px;');

與這樣比較:

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年,負面的部份已經大幅改善了,所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果:

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話,~10% 左右的 performance 改變比預期中少很多耶?可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考,如果可以用 jQuery 降低開發的瓶頸,我還蠻偏好就拿 jQuery 進來用...

處理 EasyPrivacy 讓 bookwalker.com.tw 無法購買書籍的問題

有時候在 www.bookwalker.com.tw 上面買書會出現地區問題:

先講解法再講找問題的過程以及解釋原因好了,把這行白名單設定加進 uBlock Origin 的 My filters 列表裡面就可以了:

@@||www.cloudflare.com/cdn-cgi/trace$xhr,domain=www.bookwalker.com.tw

應該有些人看到上面敘述的問題,以及白名單的設法,就大概知道發生什麼事情了,不過這邊還是會從頭說明除錯的過程。

我一開始先確認在無痕模式下是可以看到的 (也就是在沒有延伸套件的情況下),如果是這類 case,最常見的就是延伸套件的鍋,所以接下來研究是哪個套件造成的;然後透過經驗,從容易中獎的套件開始關,一路抓下來就可以抓到是 uBlock Origin。

然後把 uBlock Origin 裡面的 Filter lists 裡面開始關,一路關就可以測出來是 EasyPrivacy 這組造成的。

然後就是拉 uBlock Origin 提供的 Logger 去看 EasyPrivacy 擋了什麼,可以看到有這條:

||cloudflare.com/cdn-cgi/trace$3p,domain=~isbgpsafeyet.com|~wyndhamdestinations.com

而熟知 Cloudflare 的人應該就知道,在 https://www.cloudflare.com/cdn-cgi/trace 裡面有 geolocation 資訊,這樣看起來應該是被 bookwalker.com.tw 拿來跑地區資訊 XD

有興趣的也可以自己跑 curl -v https://www.cloudflare.com/cdn-cgi/trace 看傳回結果。

不過這個部份居然做在前端 javascript,看起來... 好像... 可以...?

公平會對創業家兄弟與松果公司的 SEO 誘導轉向開罰

好像很少提到國內的新聞,但這則應該是這兩天蠻熱門的一個新聞,創業家兄弟與松果公司 (也是創業家兄弟公司) 被公平會開罰:「操作SEO搜尋關鍵字誤導消費者 創業家兄弟、松果公司挨罰」,相關的備份先留起來:Internet Archivearchive.today

公平會官方的新聞稿則可以在「利用程式設計引誘消費者「逛錯街」,公平會開罰」這邊看到,對應的網頁備份:Internet Archivearchive.today

用的是公平交易法第 25 條:

公平會於4月12日第1594次委員會議通過,創業家兄弟股份有限公司及松果購物股份有限公司利用「搜尋引擎優化 (Search Engine Optimization,簡稱SEO)」技術,並在搜尋引擎的顯示結果上不當顯示特定品牌名稱,使消費者誤認該賣場有販售特定品牌產品,藉以增進自身網站到訪率,違反公平交易法第25條規定,處創業家兄弟公司200萬元、松果公司80萬元罰鍰。

這條的條文可以從「公平交易法§25-全國法規資料庫」這邊看到:

除本法另有規定者外,事業亦不得為其他足以影響交易秩序之欺罔或顯失公平之行為。

主要的原因是點進去後卻沒有該項商品:

公平會發現,消費者在Google搜尋引擎打上特定品牌名稱,例如「悅夢床墊」時,搜尋結果會出現「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果,消費者被前述搜尋結果吸引點選進入「生活市集」、「松果購物」網站後,卻發現該賣場並無「悅夢床墊」之產品,此係生活市集及松果購物之經營者創業家兄弟公司及松果公司分別利用SEO技術所產生的現象。

而且會透過使用者在往站上搜尋的關鍵字產生對應的頁面:

公平會進一步調查後發現,創業家兄弟公司及松果公司對其所經營之「生活市集」及「松果購物」網頁進行設計,只要網路使用者在該2網站搜尋過「悅夢床墊」,縱然該2網站賣場並沒有賣「悅夢床墊」,其網站程式也會主動生成行銷文案網頁,以供搜尋引擎攫取。若有消費者之後在Google搜尋引擎查詢「悅夢床墊」時,搜尋結果便會帶出「悅夢床墊的熱銷搜尋結果│生活市集」、「人氣熱銷悅夢床墊口碑推薦品牌整理─松果購物」等搜尋結果項目,經消費者點選後即會導向「生活市集」、「松果購物」之網站。

然後判罰的部份:

公平會過往即曾就事業使用競爭對手事業名稱作為關鍵字廣告,並在關鍵字廣告併列競爭對手事業名稱之行為,認定違反公平交易法第25條規定。本案雖非創業家兄弟公司及松果公司直接使用「悅夢床墊」等他人商品品牌作為關鍵字廣告,但最終呈現之結果,本質上都是「誘導/轉向」(bait-and-switch)的欺罔行為,除了打斷消費者正常的商品搜尋與購買過程,也對其他販售該等品牌商品之經營者形成不公平競爭的效果。若任由發生而不予規範,未來將可能導致其他競爭者之競相仿效,消費者將更難以分辨搜尋結果呈現資訊之真偽,進而威脅電商市場之競爭秩序及消費者利益。故公平會認為違反公平交易法第25條「足以影響交易秩序之欺罔及顯失公平行為」,並分別處創業家兄弟公司200萬元、松果公司80萬元罰鍰。

所以這算是對 Dark pattern SEO 的部份開罰...

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個,維基基金會相關服務的官方狀態頁:「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生),另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量,可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去,不知道有沒有後端 PHP loading 的數字...

掃 Instagram 資料的服務

Hacker News 首頁上看到「Scraping Instagram」這個掃 Instagram 資料的服務,討論在「Scraping Instagram (scrapingfish.com)」這邊。

文章裡面有提到一些 API 的技術細節,不過我覺得這塊倒不是重點,真正的重點應該是後端應該用了很多 IP 換來換去之類的技術在避開偵測...

另外這個服務讓我想到「HiQ Labs v. LinkedIn」這個案子 (之前寫過「hiQ 爬 LinkedIn 資料的無罪判決」),不確定 Instagram 這邊會不會提起訴訟,另外看起來這家公司好像也不在美國?

收費的部份是每千次 US$2,考慮到那堆架構的成本與麻煩度,好像還可以...