Tag: service

讓使用者可以自己選擇 Push notification service 的 UnifiedPush

前幾天 Hacker News Daily 上看到的，F-Droid 寫了一篇文章介紹可以讓使用者自己選擇 Push notification service 的 UnifiedPush：「UnifiedPush: A decentralized, open-source push notification protocol (f-droid.org)」。

一般在 Android 平台上是透過 Google 自家提供的 FCM 傳遞 push notification 訊息：

A modern Android smartphone relies on a lot of services, from app stores and calendars to messaging and push notifications. Most of them have open alternatives, but until now, the only option for push notifications was Google’s proprietary service, Firebase Cloud Messaging (FCM).

但這樣很明顯會遇到隱私問題 (i.e. Google 可以知道所有的 push notification)，所以一直都有要怎麼解決的討論。

而看起來 UnifiedPush 給了一個方案：使用者在 Android 手機上安裝一隻程式 (ntfy)，這隻程式可以連到使用者指定的伺服器接收 push notification (可以是自架或是用現有的服務)，另外一方面，當然也會跟 app 說要把 push notification 送到哪邊。

另外也考慮到使用者如果極度在意電池的問題，還是可以 fallback 回去使用 Google 的 FCM，也就是不影響現有使用者的體驗。

這樣就可以做到還是單一連線 (降低電力使用)，但是是分散式的架構，而且使用者有一定的控制權。

目前支援的 app 看起來不多，但可以以預期後續 F-Droid 上面的 app 應該會有不少 app 會支援：「Apps using UnifiedPush」。

AS112 計畫

在「Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queries」這邊看到的東西：「AS112 Project」，在維基百科上面也有條目：「Blackhole server」。

Cloudflare 宣佈 2022/12/15 參與 AS112 Project：

We are going to announce the AS112 prefixes starting December 15, 2022.

針對 private network 的反解 (像是 192.168.x.x 這些網段)，目前的 NS RR 會丟到 IANA 的 blackhole server 上：

;; AUTHORITY SECTION:
10.in-addr.arpa.        86400   IN      NS      blackhole-1.iana.org.
10.in-addr.arpa.        86400   IN      NS      blackhole-2.iana.org.

這兩的 domain name 分別是 192.175.48.6 與 192.175.48.42。

而 IANA 的 blackhole server 的負荷愈來愈重，所以就有了透過 anycast 打散負荷的想法，也因為在發 anycast 時的 ASN 是 112，後來也就變成了 AS112 計畫，在 RFC 7534 裡面解釋了要怎麼做：「AS112 Nameserver Operations」。

另外在 AS112 Project 的網站上也有提到 anycast 的範圍：

The address blocks are 192.175.48.0/24 and 2620:4f:8000::/48 and its origin AS is 112.

昨天 HiNet 線路連到 AS112 的 192.175.48.x 網段會丟到日本的 WIDE，剛剛看發現已經是 Cloudflare 在台灣的點了：

;; ANSWER SECTION:
hostname.as112.arpa.    604800  IN      TXT     "Cloudflare DNS, TPE"
hostname.as112.arpa.    604800  IN      TXT     "See http://www.as112.net/ for more information."

但如果是用 Google Public DNS 查詢的話則是會到 STUIX，先前也有在其他地方看到這個有趣的組織：

;; ANSWER SECTION:
hostname.as112.arpa.    300     IN      TXT     "Taiwan Digital Streaming Co. with STUIX"
hostname.as112.arpa.    300     IN      TXT     "Taipei, TW"
hostname.as112.arpa.    300     IN      TXT     "Unicast IP: 103.147.22.82"
hostname.as112.arpa.    300     IN      TXT     "See http://as112.net/ for more information."

回過頭來看這次 Cloudflare 的加入，他們手上的機房與點都很多，這次跳進去看起來會分擔掉不少其他節點的 loading。

但另外隱憂 privacy 的考量，他們手上等於是可以看到一堆 invalid DNS query log...

這次 Amazon EFS 兩個新推出的項目：Elastic Throughput 與更低的 latency

這次 re:Invent 關於 Amazon EFS 推出來的新東西，目前有看到兩個，第一個是「New – Announcing Amazon EFS Elastic Throughput」，介紹 Elastic Throughput。

傳統的 Busrting Throughput 模式會依照你的使用空間分配對應的速度，基礎是 50MB/sec per TB 計算，但可以 burst 到 100MB/sec per TB：

When burst credits are available, a file system can drive throughput up to 100 MiBps per TiB of storage, up to the Amazon EFS Region's limit, with a minimum of 100 MiBps. If no burst credits are available, a file system can drive up to 50 MiBps per TiB of storage, with a minimum of 1 MiBps.

而 Elastic Throughput 是一種高效能的模式，可以提供 3GB/sec 的讀取速度與 1GB/sec 的寫入速度：

Elastic Throughput allows you to drive throughput up to a limit of 3 GiB/s for read operations and 1 GiB/s for write operations per file system in all Regions.

但這然是有代價的，Elastic Throughput 的計費方式按照傳輸量計算，以 us-east-1 的計價來說，讀取是 $0.03/GB，寫入是 $0.06/GB。

粗粗算了一下，比較適合短時間要很大量快速讀寫的應用。如果是不在意時間的 (像是 cron job) 就不需要 Elastic Throughput... 然後 home 目錄拿來用可能是個不錯的選擇？

第二個推出的項目是不用錢的，是 Amazon EFS 效能的改進，降低 latency：「AWS announces lower latencies for Amazon Elastic File System」。

首先是讀取的效能提昇，以敘述看起來像是加上了 cache 層產生的效能改進：

Amazon EFS now delivers up to 60% lower read operation latencies when working with frequently-accessed data and metadata.

另外是對小檔寫入有做處理：

In addition, EFS now delivers up to 40% lower write operation latencies when working with small files (<64 KB) and metadata.

不過這些改進只有在新的 EFS 才會有，而且這波只有 us-east-1 上：

These enhancements are available automatically for all new EFS file systems using General Purpose mode in the US East (N. Virginia) Region, and will become available in the remaining AWS commercial regions over the coming weeks.

AWS 推出加速 Lambda 啟動速度的 Lambda SnapStart

今年 AWS 的 re:Invent 又開始了，這一個禮拜會冒出蠻多新功能的，挑自己覺得比較有興趣得來寫。

AWS 針對 Lambda 推出 Lambda SnapStart，改善冷啟動的速度：「New – Accelerate Your Lambda Functions with Lambda SnapStart」。

他拿了一個比較明顯的例子，Java 的 Spring Boot，範例在「Serverless Spring Boot 2 example」這邊，冷啟動的速度可以從 6 秒降到 200ms：

SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.

方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來，之後的冷啟動第一動變成是 restore 而非再 initialize：

With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.

不過不是所有的應用程式都可以直接套用，有些要注意的地方，比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。

比較特別的是亂數產生器需要重新 initialize，不然會有機率產生出一樣的 random data，這個是一般開發者會忽略掉的：

When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.

所以 AWS 有針對 SnapStart 下的 OpenSSL 修正，另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題：

We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.

另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom，這樣就很自然的不會因為 snapshot 而固定，當然也就沒問題：

Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.

這個功能說不用另外收費，看起來對 Java 族群還不錯？

CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)

看到 CloudFront 宣佈支援帶入 JA3 資訊了：「Amazon CloudFront now supports JA3 fingerprint headers」：

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

JA3 的頁面上可以看到說明，針對 SSL/TLS 這個複雜的 handshake 過程中，就可以從中得知不同的 client 實做，比起容易偽造的 User-agent 有效：

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測：

JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865

先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。

AWS 開西班牙區

前幾天才寫了 AWS 開了中歐的瑞士 (在「AWS 加開中歐區 (瑞士，蘇黎世)」這邊)，剛剛看到開了西班牙：「Now Open–AWS Region in Spain」。

注意到代碼不是掛在西歐 (eu-west)，而是南歐 (eu-south)，然後「Regions and Zones」這頁居然還沒更新...

另外機種比瑞士的豐富一些，像是 t4g 與 r6g 這些 ARM 的機種。

歐洲的機房突然變好多，反倒是美洲暫時沒有新的大消息... (大家都愛 us-east-1 的關係？)

SourceHut 宣佈拒絕 cryptocurrency 與 blockchain 相關的專案

SourceHut 是個 Git 與 Mercurial 的 hosting service，以及提供一些專案管理常見的功能。

他們宣佈不再提供 cryptocurrency 以及 blockchain 相關專案的服務，自 2023 年生效：「SourceHut terms of service updates, cryptocurrency-related projects to be removed」。

SourceHut is planning to roll out updates to our terms of service, effective in 2023. The changes most likely to impact users is the prohibition of cryptocurrency- or blockchain-related projects on SourceHut.

因為這些技術幾乎都是用在違法用途上：

These domains are strongly associated with fraudulent activities and high-risk investments which take advantage of people who are suffering from economic hardship and growing global wealth inequality. Few to no legitimate use-cases for this technology have been found; instead it is mostly used for fraudulent “get rich quick” schemes and to facilitate criminal activity, such as ransomware, illicit trade, and sanctions evasion. These projects often encourage large-scale energy waste and electronics waste, which contributes to the declining health of Earth’s environment. The presence of these projects on SourceHut exposes new victims to these scams and is harmful to the reputation of SourceHut and its community.

不過這年頭自己架 GitLab 也不是什麼難事，該有的功能都有，這個只能算是個宣言...

AWS 加開中歐區 (瑞士，蘇黎世)

AWS 在瑞士蘇黎世開了新的區域，代碼 eu-central-2：「A New AWS Region Opens in Switzerland」，其中代碼 eu-central-1 是德國，這次的歐洲中不稍微往南邊一點開。

I am pleased to announce today the opening of our 28th AWS Region: Europe (Zurich), also known by its API name: eu-central-2.

歐洲的 region 愈來愈多了，但可以看出來東歐一直還沒有點，不過以目前戰火的情況看起來應該不會太快...

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了，Amazon EC2 的 AMI 總算是能直接抽換 root volume，不用先停掉機器：「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題，後來大家都把 workaround 變成 practice 了：每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具)，然後用工具更新 AMI id 改開新的機器，這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD