弄個 whoogle.hasname.com 給大家玩

先前提到的 Whoogle:「自架的 Google Search Proxy 伺服器專案:Whoogle Search」與「改寫「Press "g" to Google (DuckDuckGo)」讓他支援 Whoogle」,後來想一想還是讓沒打算自己架的人可以用好了,指到國外的 latency 還是比較高...

如果你是 Chromium 類的瀏覽器,可以把搜尋引擎改成:

https://whoogle.hasname.com/search?q=%s

如果是我寫的 userscript (「Press "g" to Google (DuckDuckGo)」這個),可以改成:

https://whoogle.hasname.com/search?q=

然後 nginx 這邊先 access_log off; 了,理論上這樣應該是差不多了?

目前機器是放在客廳 (加 UPS),之後可能會丟到台灣的 VPS 上?

改寫「Press "g" to Google (DuckDuckGo)」讓他支援 Whoogle

前幾天提到了 Whoogle 這個專案 (參考「自架的 Google Search Proxy 伺服器專案:Whoogle Search」),用 Docker 跑起來後就改寫「Press "g" to Google (DuckDuckGo)」這個專案,讓他可以支援設定 Whoogle,大概像是這樣:

使用者可以自己設定對應的 Whoogle 伺服器,這樣應該會方便一些...

自架的 Google Search Proxy 伺服器專案:Whoogle Search

忘記在哪邊看到的連結,自架的 Google Search Proxy 伺服器專案:「Whoogle Search」,對應的 Hacker News 討論串也可以參考:「Whoogle Search: A self-hosted, ad-free, privacy-respecting metasearch engine (github.com/benbusby)」。

GitHub 上的分析可以看出來主要是 PythonFlask 寫的,然後說明就有提到是從 Google Search 撈資料,去掉所有可能可以被追蹤的項目:

Get Google search results, but without any ads, javascript, AMP links, cookies, or IP address tracking. Easily deployable in one click as a Docker app, and customizable with a single config file. Quick and simple to implement as a primary search engine replacement on both desktop and mobile.

目前最新版是 0.5.4,從他列出來的 Public Instances 找了一個是最新版的測試,看起來沒什麼大問題:「gslin - Whoogle Search」。

應該可以自己在台灣架一個起來玩看看?安裝方式看起來很多,因為是 Python-based 的套件,可以用 pipx 或是 Docker 裝起來跑,然後可以改寫「Press "g" to Google (DuckDuckGo)」(press-g-to-google-duckduckgo) 讓他可以設定要轉到哪個 Google Search Proxy...

Elasticsearch 的 Python 套件開始阻擋 OpenSearch 的伺服器了

Hacker News Daily 上看到的:「Official Elasticsearch Python library no longer works with open-source forks (github.com/elastic)」,連結所指向的是 GitHub 上的 pull request,在「Verify connection to Elasticsearch #1623」這邊。

講白了也就是 Elasticsearch 官方的 Python client 開始阻擋 AWS 主推的 OpenSearch

另外 AWS 這邊也出手,把本來的 client 都 fork 出來:「Keeping clients of OpenSearch and Elasticsearch compatible with open source」,這場戰爭還有得打...

Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

在 tab 上放了一陣子的連結,忘記是哪邊看到的,在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化:「Google’s unfair performance advantage in Chrome」。

作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎,這樣可以大幅降低建立 HTTPS 連線時所需要的時間,包括了 DNS 查詢、TCP handshake 與 TLS handshake:

I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

問題在於這個功能只開給 Google Search 使用:

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.

search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼:

// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
    "PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
}  // namespace features

作者有提到,的確這個功能會對 search engine 有不小的衝擊,但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供,現在這樣寫死在程式碼裡面完全就是不公平競爭。

Google Web Store 裡的黑暗交易

標題只寫了 Google Web Store,主要是因為瀏覽器市占率的問題,其實是包含 Firefox 的 Add-Ons。

這是在 Hacker News 首頁上看到的:「Many temptations of an open-source chrome extension developer」,講一直會有人來接觸,可以付費給開發者,想要在這些專案裡面放一些「東西」,可能是蒐集資料,可能是強制導到特定的 search engine,也有可能更邪惡...

另外是老規矩,在 Hacker News 上的討論也可以翻一翻,還蠻有趣的:「Many temptations of an open-source Chrome extension developer (github.com/extesy)」。

先大概看一下 Hover Zoom+ 這個套件在 Google Web Store 的安裝數量,大約 30 萬人:「Hover Zoom+」,作者公佈的信件內容裡面有一些包括價錢與目的...

話說回來,Brave 上的 CRX Viewer 還是沒修好啊:「Stopped working with Brave」,要裝新的套件都得另外再拉 crx 檔下來看,麻煩不少...

Google 推的 AMP 終於廢了...

傳言一陣子了,最近又在「Google AMP is dead! AMP pages no longer get preferential treatment in Google search」這邊看到這個消息,讓人煩悶的 AMP 終於可以丟到垃圾桶了。

Google 的公告說明則是在「More time, tools, and details on the page experience update」這邊。

This means that using the AMP format is no longer required and that any page, irrespective of its Core Web Vitals score or page experience status, will be eligible to appear in the Top Stories carousel.

一般猜測會有這樣的改變,主要是在去年年底啟動的反托拉斯訴訟,針對 Google 在推廣 AMP 技術時利用 search engine 的優勢造成不公平競爭:「Google AMP gets a shock to its system as advisor quits, lawsuit claims foul play」。

Google's Accelerated Mobile Pages technology, known as AMP among web publishers, took a beating this week as an antitrust lawsuit filed by the Attorney General of Texas charged that the ad biz used AMP to hinder competition.

可喜可賀...

AWS 對 Elasticsearch 的戰爭:OpenSearch

AWSElasticsearch 的戰爭繼續升溫,AWS 出來喊,搞了自己的 community 要跟本家 PK:「Introducing OpenSearch」,衍生出來的兩套軟體分別是 OpenSearch (對應 Elasticsearch) 與 OpenSearch Dashboards (對應 Kibana)。

Hacker News 上的討論「OpenSearch: AWS fork of Elasticsearch and Kibana (amazon.com)」裡面有些討論還蠻精彩的,其中這段:

One thing which surprised me: Elastic has a market capitalization of ~$11B.

I think that changes some of the more floaty ethical concerns. This is not a David vs Goliath situation. This is Goliath vs Super-Goliath.

雖然就公司市值比例來看,大約是 100:1 這個數量級的公司在打架 (AWS 的母單位 Amazon 大約在 USD$1T 的等級),但這其實這不是小蝦米被大鯨魚欺負的故事,而是大公司跟暴力超大公司之間的打架。

會怎麼演變其實猜不出來,但因為在 open source search engine 技術這塊的確缺乏其他像樣的競爭者,AWS 這樣丟資源進來未必是件壞事。

另外一方面,這件事情對商業公司在在 open source 的其他領域則是比較負面,很明顯的 Amazon 這樣玩對於其他以 open source 為基礎的商業公司處境就更嚴峻了。

路透社的 RSS feed

翻資料才發現路透社的 feed 已經不見了,大概是去年 2020 年六月的事情:「Returning the "killed" RSS of Reuters from the dead」。

不過文章裡面提到的替代方案還蠻有趣的,Google News 上可以透過 filter 條件輸出:

https://news.google.com/rss/search?q=when:24h+allinurl:reuters.com&ceid=US:en&hl=en-US&gl=US

不過測了一下台灣自家的新聞媒體網址,看起來不會動... 把網站改成 news.google.com.tw 也不行,如果沒有提供的還是得自己寫...

Google Groups 把 comp.lang.c 給禁了...

Hacker News Daily 上看到的,Google Groupscomp.lang.c 給禁了,連到 https://groups.google.com/g/comp.lang.c 可以看到無法使用的訊息:

警告:內容已遭禁止
comp.lang.c 已被認定為包含垃圾內容、惡意軟體或其他惡意內容。

如要進一步瞭解 Google 網路論壇的內容政策,請參閱這篇關於濫用本服務的說明中心文章,以及我們的《服務條款》。

這樣連歷史資料都看不到了...