X/Twitter 又繼續在搞競爭對手的外部連結了...

八月的時候提過「X/Twitter 在惡搞外部連結結果被抓包玩陰的」這個,X (Twitter) 故意對某些網站 delay 個幾秒鐘再重導,當時爆料出來後就馬上拿掉了,結果這幾天又被抓到故技重施:「Twitter is Still Throttling Competitors’ Links—Check for Yourself」。

依照測試,Meta 家的 FacebookInstagram 以及 Threads 都中獎,另外沒什麼意外的,Twitter 前頭頭跳出來開的 Bluesky 也都有被搞...

而且這次爆料出來後也沒有「迅速修正」了,到目前也都還是如此... 來看看後續?

微軟的 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...

AWS Elemental Link:直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link,可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上:「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎,大約 524 立方公分):

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI,規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限),然後設備除了透過一般電力供電以外,也可以用 PoE 供電,可以少接一條電源線:

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995,但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品,好像沒看到類似可以直接送到網路服務的產品...

Microbrowser 的影響力

在「Microbrowsers are Everywhere」這篇文章裡提到在討論 Microbrowser 的影響力。這邊講的 Microbrowser 是指在各種平台上面貼連結時產生的預覽資訊,像是 IM 裡面連結的預覽資訊 (左邊的圖):

這些預覽通常都不會執行 JavaScript,所以不會觸動頁面裡追蹤的服務,而一般的業主就會低估這個管道。但透過這個方式觸及到使用者的量以及影響力,作者覺得有可能比 Googlebot 還大:

3. Microbrowser are probably more important than google bot

算是另外一個領域的 optimization,畢竟不同的平台預覽的效果都不同...

用 Userscript 在 Gmail 裡面展開連結

前一篇「在 Gmail 裡面展開 GitHub 信件連結的 Userscript」是展開 GitHub 的連結,但這個套件是用document.querySelectorAll() 抓出來,裡面寫死了不少東西...

用了幾天後我還是只想開 commit 相關的連結 (用 regex 表示的話就是 ^https://github\.com/[^/]+/[^/]+/commit/),所以就找看看 Tampermonkey 能不能有 Config Page 或是 Option Page 可以讓使用者設定,結果發現本身沒支援:「Create a “config” or “options” page for a Greasemonkey script」。

但回覆裡面有提供一些方案可以用,我後來選了 MonkeyConfig,至少可以讓使用者設定 regex...

新的 Userscript 放在「open-links-in-gmail」這邊。

在 Gmail 裡面展開 GitHub 信件連結的 Userscript

從以前用 Subversion 就有習慣用 e-mail 收 diff log (內建的 hook 就有這個功能)。後來有了 Gmail 就更方便了,畢竟搜尋是 Google 的強項,另外一方面 Gmail 也是目前少數可以完全用鍵盤操作的 e-mail client。

現在用 GitGitHub 平台讓這件事情麻煩不少,得透過 webhook + API 自己包出來,目前折衷的方法是收 GitHub 的通知信 (但是沒有 diff log),然後寫個 Userscript,在按下 i 之後會把 GitHub 通知信裡的連結全部點開:「open-github-links-in-gmail」。

寫的很簡單... 最花時間反而是因為 hotkey 都被吃掉了,要測出哪個鍵還沒被用掉。

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外,在「Preload Scripts」這邊看到的技巧,可以跟 browser 說明哪些資源比較重要,請儘快先下載:

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法,這個技巧應該用在會卡住頁面呈現的部分,確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面,理論上會更快:

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助,建議可以跑 A/B test 看看效果:

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel,可以將內部網路與 Cloudflare 之間打通:「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇),這次其實只是改名:

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

關於我在 Twitter 上貼的連結... (像是 Retweet,或是透過 Nuzzle/Pocket 貼的連結)

tl;dr:我把 Twitter 當暫存區,把手機上看到的連結丟到 Twitter 後再用桌機打開來看,所以有很多連結我雖然轉發,但未必看過。

我習慣在通勤或是睡前刷一下手機,看一下各類媒體有什麼資訊 (參考「為什麼我還繼續用 RSS (Feed)」這邊,是我找「未知的來源」的一部分),但這麼一來會遇到幾個問題:

  • 時間很零散,或是不長,所以有些文章我會看標題就先找個地方丟出來。
  • 手機上的廣告阻擋機制不太好,桌機的阻擋機制強大許多。

前陣子有些朋友問到為什麼 Twitter 上會有些明顯跟我的意見不同的 tweet,原因就是這樣啦...