WordPress 對 FLoC 的對抗計畫

Google 打算在 Google Chrome 裡面強推的 FLoC 最近有很多消息,但因為沒看完 spec 就一直丟著了... 可以先參考 iThome 的「繼Brave瀏覽器之後,DuckDuckGo、Vivaldi也要封鎖Google FLoC廣告投放技術」,雖然裡面提的很淺。

目前檯面上除了廣告產業以外,所有看到的人與組織都反對 FLoC。

EFF 的「Google’s FLoC Is a Terrible Idea」,之後 DuckDuckGo 也發表了「Use the DuckDuckGo Extension to Block FLoC, Google’s New Tracking Method in Chrome」,再來是 Brave 的「Why Brave Disables FLoC」與 Vivaldi 的「No, Google! Vivaldi users will not get FLoC’ed.」。

最新的進展是 WordPress 決定把 FLoC 當作 security concern 來看,打算直接推出 security hotfix 更新,預設關閉 FLoC:「Proposal: Treat FLoC as a security concern」,在 Hacker News 上也有討論:「Proposal: Treat FLoC as a security concern (make.wordpress.org)」。

主要的原因是正常的 WordPress 版本會在今年七月才出,會跟不上 FLoC 的進度:

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

我自己也因為 FLoC 而又再次跳到 Brave,還遇到 imgur Uploader 套件不見 (可以參考「What Happen to the imgur uploader extension?」),以及有些套件無法運作的問題...

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2t4g.small 上 (2GB RAM + 20% CPU credit),跑了一陣子把 CPU usage 拉出來看:

當初估大約要 20% 的 CPU credit,結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB,這個量可以看出來一些沒在用的 process 會被丟到 swap:

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算,就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度,就看了一下 Reserved Instances 的價錢,一年 USD$44,三年 USD$84,看起來只要有用兩年就算是 OK,直接買三年解決掉...

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量),就把 blog 搬到 AWSt4g.small (ARM) 上,理論上頁面的速度應該會快不少,過幾天等穩定性沒問題後就來買 RI...

x86-64 轉到 ARM 上面,主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository,所以就改用 MariaDB 了。

其他的倒是都差不多,目前的 Ubuntu + nginx + PHP 沒什麼問題,跑一陣子看看...

PHP 8.0 快要出了

看到 WordPress 的這篇「WordPress and PHP 8.0」,看起來 PHP 8.0 快要出了:

PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.

官網上已經有一些資料可以看了,不過記得畢竟還沒 release,裡面的資訊還有可能會修正:「Migrating from PHP 7.4.x to PHP 8.0.x」,最重要的應該還是「Backward Incompatible Changes」這邊,可以看到這次畢竟是主版號升級,精彩的不相容性應該會搞爆不少應用程式,像是開頭就提到的,對數字與文字之間的 == 行為改變:

比較好的作法是自己先轉型再用 === 比較,這個概念在各家程式語言都類似,loose comparison 只是方便而已...

這幾天 blog 被掃,用 nginx 的 limit_req_zone 擋...

Update:這個方法問題好像還是不少,目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面,結果 CPU loading 變超高,從後台可以看到常常滿載:

看了一下是都是從 Azure 上面打過來的,有好幾組都在打,IP address 每隔一段時間就會變,所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit,搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個,就設起來暫時用這個方式擋著,大概是這樣:

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable,但這邊用 429 應該更正確,從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明:

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來,目前比較困擾的是需要 copy & paste try_filesFastCGI 相關的設定:

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot,至少在現階段應該還是有用的...

如果之後有遇到其他手法的話,再見招拆招看看要怎麼再加強 :o

用事實查核中心的 RSS feed 加上 IFTTT 自動通知到 Line/Telegram/... 內

事實查核中心的澄清內容其實很有趣,可以看到有哪些假消息在流傳,所以想找找看有沒有比較簡單的方法可以設通知...

事實查核中心的官網用的是 netiCRM 這個平台 (看起來底層是 Drupal),而在 HTML 頁面的開頭可以看到 RSS 1.0 的 xmlns 宣告:

  xmlns:content="http://purl.org/rss/1.0/modules/content/"

本來想說直接用 feed 接到 IFTTT 就好了,不過 HTML 頁面上沒有放 feed entry 讓閱讀器可以直接找到 feed 本身,也就是像這樣的標籤資訊:

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />
<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Comments Feed" href="https://blog.gslin.org/comments/feed/" />

找了一下 Drupal 的設定慣例,發現 feed 可能會放在 /rss.xml 這個位置,測了一下發現順利在 https://tfc-taiwan.org.tw/rss.xml 這邊看到 feed,接下來就可以加進 IFTTT 了:

給有興趣想要用 feed 做些事情的人參考看看,像是加到 Line 或是 Telegram 的群組裡面,或是放到 Slack channel 裡面 (Slack 裡應該可以直接在某個 channel 裡用 /feed add https://tfc-taiwan.org.tw/rss.xml 把這個 feed 加進去)。

把 TLS 1.0 關掉...

突然想到所以到 SSL Report 上測試 blog.gslin.org,發現如果還支援 TLS 1.0,在 Overall Rating 的部份會直接被降為 B。

翻了一下 access log (我在 log 裡有多記錄連線的 TLS Protocol),看起來用 TLS 1.0 連的主要都是 bot,關掉應該是還好...

另外看了一下報告裡的 Cipher Suites 部份,發現不少 cipher (像是 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)) 被列為 weak,看起來像是把使用 CBC 的 cipher 都認為是 weak,是個推廣 AEAD 的概念。

影響應該不大,但還是記錄一下... 另外等 Ubuntu 20.04 出了以後把整台重灌好了,目前還在用 Ubuntu 16.04,系統內建的 nginx 不支援 TLS 1.3。

AWS 官方推出 WordPress 整合套件

AWS 自己推出了跟 WordPress 的整合套件:「Accelerating WordPress with CloudFront using the AWS for WordPress Plugin」、「AWS for WordPress plugin now available and with new Amazon CloudFront workflow」。

這次的套件主要是將 Amazon CloudFront 整合進 WordPress:

Amazon Web Services announces the general availability of the AWS for WordPress plugin. Previously known as the Amazon Polly and Amazon AI plugin, the new AWS for WordPress plugin now provides a workflow to configure an Amazon CloudFront distribution that is highly optimized for WordPress websites.

如果想要都控制在自己手上,AWS 算是提供了一個官方的方案,也應該有一定的支援。不過大多數人還是會拿 Cloudflare 的免費方案吧...

換到 PHP 7.3

上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」),這次是在整理機器時發現 blog 這台機器還在跑 7.2,就更新一下系統把上面的站台都換到 7.3。

蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」),目前看到的資料都會快一些,應該是沒有太大問題,之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB,但用 opcache-status 看起來只用了 65 MB 左右),把記憶體空間讓給其他程式用...

不過 7.4 也快出了...

使用 RSS 的呼籲

在「Please Add RSS Support To Your Site」這邊看到文章作者在呼籲使用 RSS (這邊應該是包括 Atom)。

主要是 RSS/Atom 算是很成熟的架構了,有很多工具可以閱讀 (RSS/Atom Reader),提昇閱讀的效率。像我是用 Bazqux,另外也有不少人在使用 Feedly... 而除了訂閱外,RSS/Atom 也可以再串出去接其他東西,像是串到 IFTTT 後就可以接上 IFTTT 上面的應用程式。

除了文章作者的呼籲以外,我自己也對我自己常用的網站操作 (在 GitHub 上的 hasname/feedgen 這邊),把網頁結果轉成 RSS/Atom (裡面大多就是去讀 search 相關功能了),這樣有新東西就可以透過 RSS/Atom Reader 讀到...