Yahoo! 要重新搞搜尋引擎?

看到 Hacker News 上提到 Y! 要重新搞 search engine 的消息:「Yahoo is making a return to search」,HN 上的討論在「Yahoo is making a return to search (searchengineland.com)」這邊。

跡象包括了招募資訊與 Twitter 帳號 @YahooSearch 的重啟,還有 LinkedIn 上一些 Y! 的高層公開提到這次的招募。

現在的 Yahoo! Search 應該是 Bing 的資料 (很久沒有聽到新的消息了),至少從維基百科上面看到的說明提到 2019/10 後就又跳回 Bing 了:

As of October 2019, Yahoo! Search is once again powered by Bing.

這樣可以讓市場再多一點變化?

FBI 建議用擋廣告軟體降低瀏覽時的風險

在「Even the FBI says you should use an ad blocker」這邊看到的新聞,FBI 的公告則是在「Cyber Criminals Impersonating Brands Using Search Engine Advertisement Services to Defraud Users」這邊可以看到。

起因是有很多網路犯罪行為會透過購買廣告,在搜尋引擎上曝光誘導使用者點擊:

Cyber criminals purchase advertisements that appear within internet search results using a domain that is similar to an actual business or service. When a user searches for that business or service, these advertisements appear at the very top of search results with minimum distinction between an advertisement and an actual search result. These advertisements link to a webpage that looks identical to the impersonated business’s official webpage.

其中一種方式是,使用者輸入關鍵字想要下載某些特定的軟體,這時候網路犯罪者就會透過下廣告的方式,誘導使用者到假的網站下載有後門木馬的軟體:

In instances where a user is searching for a program to download, the fraudulent webpage has a link to download software that is actually malware. The download page looks legitimate and the download itself is named after the program the user intended to download.

這個方式讓我想到之前北韓政府對 PuTTY 的攻擊:「Trojanized versions of PuTTY utility being used to spread backdoor」。

而 FBI 建議個人的保護方式包括了 ad blocking extension,這算是減少被攻擊的管道:

Use an ad blocking extension when performing internet searches. Most internet browsers allow a user to add extensions, including extensions that block advertisements. These ad blockers can be turned on and off within a browser to permit advertisements on certain websites while blocking advertisements on others.

然後建議擋廣告軟體就是用 uBlock Origin,無論是 Chromium 系列的瀏覽器 (包括 Google Chrome),或是 Firefox 都有支援。

Kagi 可以分享搜尋結果了

先前 Kagi 限制只有註冊的使用者可以搜尋,但這次更新可以分享結果了 (在 Changelog 上可以看到):

Enable sharing of search results pages with people who lack a Kagi account #23 @ivan

這邊連結的是「Enable sharing of search results pages with people who lack a Kagi account」這個功能,看起來也算是個推銷其他人用 Kagi 的功能,所以就被做出來了。

我用無痕模式模擬沒有登入的情況,測了「Kalafina」這個關鍵字,確認可以看到這頁的結果了。

Kagi 的 url rewrite

Kagi 在上個禮拜推出了 url rewrite 的功能,可以把搜尋結果裡面的網址換掉:(在「Changelog」這邊可以看到)

Rewrite rules for domains - ability to e.g. translate "reddit.com" into "old.reddit.com" #158 @TeMPOraL

這個功能其實也可以在瀏覽器上用 extension 或是 userscript 處理掉 (跨機器可以透過瀏覽器的 cloud sync 來做),但目前應該還沒有這樣的東西,得自己寫一個出來。

範例提到把 reddit.com 換成 old.reddit.com 這種用法算是社群蠻常用的 (大家都不愛新版界面),不過我自己是把 *.m.wikipedia.org 轉成 *.wikipedia.org,這邊有多做一些事情,下面一條會提到:

^https://([a-z]+)\.m\.wikipedia\.org/[-a-z]*/(.*)|https://$1.wikipedia.org/wiki/$2

不難看出來是吃 regular expression,只是官方好像沒有特別說支援到哪種類型?(POSIX 系列或是 PCRE 類的,可以加減參考 Wikibooks 上「Regular Expressions」這邊的分類)

我另外一個 rule 是把維基百科有語言代碼的 https://zh.wikipedia.org/zh-*/ 轉成 https://zh.wikipedia.org/wiki/

^https://zh\.wikipedia\.org/zh-([a-z]*)/(.*)|https://zh.wikipedia.org/wiki/$2

這樣做的缺點是會出現兩個,可以看到第一個被轉了以後會出現一個小 icon,移上去可以看到是被哪個 rule 轉的:

Kagi 公佈了收費三個月後的進展

Kagi 公佈了收費三個月後的進展 (可以參考「Kagi 開始收費了」這篇):「Kagi status update: First three months」。

搜尋的部份 (Kagi 這個產品線),目前有 2600 個付費使用者,以 US$10/mo 的費用來算大概是 US$26K/mo 的收入:

Kagi search is currently serving ~2,600 paid customers. We have seen steady growth since the launch 3 months ago. Note, this is with zero marketing and fully relying on word of mouth. We prefer to keep things this way for now, as we are still developing the product towards our vision of a user-centric web search experience.

後面在講財務狀況也是類似的數字 (幾乎都是 Kagi 的付費收入):

Between Kagi and Orion, we are currently generating around $26,500 USD in monthly recurring revenue, which incidentally about exactly covers our current API and infrastructure costs.

這個收入差不多 cover 目前的 infrastructure 部份,但還有薪資與其他的 operating cost 大約在 US$100K/mo 這個數量級,看起來還有很大的距離:

Between Kagi and Orion, we are currently generating around $26,500 USD in monthly recurring revenue, which incidentally about exactly covers our current API and infrastructure costs.

That means that salaries and all other operating costs (order of magnitude of $100K USD/month) remain a challenge and are still paid out of the founders’ pocket (Kagi remains completely bootstrapped).

然後要大概是目前十倍的付費數量才會打平 (25K 個使用者):

We are planning to reach sustainability at around 25,000 users mark, by further improving the product, introducing new offerings and pricing changes. With the product metrics being as good as they are, we should be able to reach this as our visibility increases.

比較好一點的消息是 churn rate 很低:

Product stickiness is also very high, with churn being lower than 3%.

然後提到每個使用者大約 27 次查詢 (包括 free tier),有些 user 大約在 100 次,peak 是 400 次:

We are currently serving around 70,000 queries a day or around ~27 queries/day/user (this includes free users which are about 10% of total users). There is a lot of variance in use though, with some users regularly searching >100 times a day. Every time we see a search count go >400 times in day we are happy to be an important part of someone’s search experience.

我看了一下自己的用量,看起來偏高一些,但沒到他說的每天平均 100 次:

然後提到了推出新方案的計畫,包括 Teams Plan & Family Plan,而目前在跑的方案會被分類到 Individual Plans。

另外比較重要的是 Individual Plans 有漲價的計畫。新的方案預定分成三個層級,主要是增加了一個 Kagi Starter 的版本:

  • Kagi Unlimited - $19/mo or $180/year ($15/mo) or $288/biennial ($12/mo) - Original Kagi experience, with unlimited searches
  • Kagi Starter ($5/mo; 200 searches) - For casual users who make less than 200 searches per month
  • Free basic - 50 free searches that reset every month

漲不少,雖然有提到在漲價前既有的付費使用者將會維持原價:

If such change to Individual plans is to occur, we plan to grandfather-in all early adopters (meaning all current and future paid customers, up until this change) allowing them to keep their existing subscription price as long as they don’t cancel it.

繼續觀察看看...

滲透測試的工具,各種搜尋引擎

Twitter 上看到的東西:

裡面是一張圖,整理一下這 24 個站台:

一堆 .io 網域...

裡面有蠻多服務是偶而會用到的,改拿來當作 pen test 的基礎工作也是蠻好用的,各種預先掃好的結果拿來搜...

Google 說要把 double quote 強制搜尋的功能加回來...

Hacker News Daily 上看到「We're improving search results when you use quotes (blog.google)」這則,才知道原來被拔掉了?(不過已經很久不是拿 Google Search 當主力了...)

原文在「How we're improving search results when you use quotes」這邊,裡面提到:

For example, if you did a search such as [“google search”], the snippet will show where that exact phrase appears:

[...]

In the past, we didn’t always do this because sometimes the quoted material appears in areas of a document that don’t lend themselves to creating helpful snippets.

在「Google for the exact phrase (and no, quotation marks don't help)」這邊可以看到 2020 的時候 double quote 就已經不是傳回精確的結果了。

不過應該不會回去用 Google Search 了,一方面是 Kagi 的表現還不錯,另外一方面是避免讓 Google 拿到更多資訊...

ClickHouse 自家做的 benchmark 比較

在「Show HN: A benchmark for analytical databases (Snowflake, Druid, Redshift) (clickhouse.com)」這邊看到 ClickHouse 自家做的 benchmark 比較,網站在「ClickBench — a Benchmark For Analytical DBMS」這邊。

這種 benchmark 基本上是拿來當作清單來看,另外 Hacker News 上的討論一定得看,尤其是沒被列上 benchmark 的...

講到 ClickHouse,先前是有朋友跑來說他有個需求是需要跑分析,但遇到用 PostgreSQL 時發現寫入速度不夠快的問題,看看有沒有什麼方法可以解。問了多一點以後發現他的需求是 OLAP 類而不是 OLTP 類,就先跟他講要去找 OLAP engine 來解決。

然後就聊到維基百科上「Comparison of OLAP servers」這個條目,裡面列出來的 open source 軟體是不少,但 Apache 家基本上大家都知道是回收場,裡面就剩下 ClickHouse 比較常在 Hacker News 以及其他地方被提到,但我有跟他講我連玩都沒玩過,我們家自己反而是用 CassandraTrino 搭出來的,當時沒有花太多時間研究市場上的方案,就挑了一個自己熟悉的方案趕快先解決。

但過了兩天後他就說用 ClickHouse 解決了,反而讓我對 ClickHouse 有興趣起來,反正記憶體當時裝了一堆沒用到。

拉了一下「Summary of the 1.1 Billion Taxi Rides Benchmarks」這邊的資料看,這個作者常常會測各種資料庫,算是一個可以參考的資料來源,可以看到 2019 年測的「1.1 Billion Taxi Rides: 108-core ClickHouse Cluster」其實就相當不錯了?

基本上先照「Usage Recommendations」這邊看一輪,基本的要求不低,但剛好機器是 32GB RAM:

If your system has less than 16 GB of RAM, you may experience various memory exceptions because default settings do not match this amount of memory. The recommended amount of RAM is 32 GB or more. You can use ClickHouse in a system with a small amount of RAM, even with 2 GB of RAM, but it requires additional tuning and can ingest at a low rate.

如果要跑 cluster 模式的話會需要 ZooKeeper 或是替代品 ClickHouse Keeper

然後除了使用官方的 clickhouse-client 連線以外,也可以用 MySQL 或是 PostgreSQL 的 client 連,裡面操作其實蠻簡單的,好像值得投資看看?

用 JavaScriptCore 實做的一站式方案 Bun

前幾天在 Hacker News 上討論得很熱烈的 Bun:「Bun: Fast JavaScript runtime, transpiler, and NPM client written in Zig (bun.sh)」。

從 Hacker News 上的標題上就可以看到 Bun 做了不少事情,看起來想要打造一個 all-in-one 環境,把所有開發與 server 端 JavaScript 所需要的東西就一次包進來,不需要在自己東挑西挑...

比較特別的是 Bun 在選 JavaScript Engine 的時候是選擇 Apple 家推出的 JSC (或者稱 JSCore,正式名稱是 JavaScriptCore),而不是現在主流的 V8 (Google 家),據說這樣比較省記憶體,但 server 端應用應該是不缺這個記憶體才對?

JavaScript runtime with Web APIs like fetch, WebSocket, and several more built-in. bun embeds JavaScriptCore, which tends to be faster and more memory efficient than more popular engines like V8 (though harder to embed)

另外一個是強調啟動速度,這對開發應該有幫助,但對 server 應用來說好像還好:

Bun.js uses the JavaScriptCore engine, which tends to start and perform a little faster than more traditional choices like V8.

在官方宣稱的效能測試上可以看到很多改善,感覺是個還蠻「有趣」的方案,可以繼續觀察看看,畢竟現在是 beta 版,另外也讓子彈飛一下,是不是只有列出來的那些會比較快...

微軟的 Outlook 系統會自動點擊信件內的連結

前幾天在 Hacker News Daily 上翻到的,微軟的 Outlook 系統 (雲端上的系統) 會自動點擊信件內的連結,導致一堆問題:「“Magic links” can end up in Bing search results — rendering them useless.」,在 Hacker News 上的討論也有很多受害者出來抱怨:「“Magic links” can end up in Bing search results, rendering them useless (medium.com/ryanbadger)」。

原文的標題寫的更批評,指控 Outlook 會把這些 link 丟到 Bing 裡面 index,這點還沒有看到確切的證據。

先回到連結被點擊的問題,照文章內引用的資料來看,看起來是 2017 年開始就有的情況:「Do any common email clients pre-fetch links rather than images?」。

As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.

在 Hacker News 上的討論也提到了像是 one-time login email 的機制也會因此受到影響,被迫要用比較費工夫的方法讓使用者登入 (像是給使用者 one-time code 輸入,而不是點 link 就可以登入)。

先記起來,以後在設計時應該會遇到,要重新思考 threat model...