AWS 推出了與 5G 結合的 AWS Wavelength

看到「Announcing AWS Wavelength for delivering ultra-low latency applications for 5G」這篇,裡面提到了與 5G 結合的 AWS Wavelength

裡面提到的東西包括了把 AWS 的架構延伸到各家電信的架構裡面,看起來跟剛推出的 AWS Outposts 有關 (參考「AWS Outposts 總算要開始出貨了」這邊的介紹):

AWS Wavelength brings AWS services to the edge of the 5G network, minimizing the network hops and latency to connect to an application from a 5G device.


AWS is partnering with leading telecommunications companies around the world, including Verizon, Vodafone, SK Telecom, and KDDI, to launch Wavelength across North America, Europe, Japan, and South Korea in 2020.


Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。


不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Apple 新的「Find My」帶來的隱私問題

這次 WWDC 推出的新功能,已經有人在討論機制與隱私問題了:「How does Apple (privately) find your offline devices?」。

前一代的「Find my iPhone」需要透過網路與 GPS 資料才能在系統上看到,這一代則是加上 BLE beacon,然後任何一台 iOS device 收到後就回傳回給蘋果:

Every active iPhone will continuously monitor for BLE beacon messages that might be coming from a lost device. When it picks up one of these signals, the participating phone tags the data with its own current GPS location; then it sends the whole package up to Apple’s servers.

幾個隱私問題在於,代傳的 iOS device 也會暴露位置資訊給蘋果,另外收到 BLE beacon 的 iOS device 本身是否可以解讀遺失機器的資訊?而商家看起來也可以利用這個方式主動發送攻擊而得知不少資料 (像是文章裡提到先前蘋果透過 randomize mac address 加強隱私的問題,這邊又多開了一個洞),現在蘋果給的資訊還不夠清楚,需要真的逆向工程確認才知道...

利用 Sensor 校正資訊產生 Device Fingerprint 的隱私攻擊

看到「Fingerprinting iPhones」這篇提出的攻擊,標題雖然是提到 iPhone,但實際上攻擊包括了 Android 的手機:

You are affected by this fingerprinting attack if you are using any iOS devices with the iOS version below 12.2, including the latest iPhone XS, iPhone XS Max, and iPhone XR. You are also likely to be affected if you are using a Pixel 2/3 device, although we hypothesise the generated fingerprint has less entropy and is unlikely to be globally unique. A SensorID can be generated by both apps and mobile websites and requires no user interaction.

目前 iPhone 升級到 12.2 之後可以緩解這個問題,Android 看起來還不清楚...

攻擊的方式是透過手機在出場前會使用外部的校正工具,找出手機內 sensor 所偵測到的值與實際值的差異,然後把這些資訊燒到韌體裡,當呼叫 API 時就可以修正給出比較正確的值。

而因為這些校正資訊幾乎每一隻手機都不一樣,而且不會因為重裝而變更 (即使 factory reset),加上還可以跨 app 與 web 追蹤,就成為這次攻擊的目標:

In the context of mobile devices, the main benefit of per-device calibration is that it allows more accurate attitude estimation.

資訊量其實相當大,透過 app 分析可以得到 67 bits entropy,透過網頁也有 42 bits entropy,而且不怎麼會變:

In general, it is difficult to create a unique fingerprint for iOS devices due to strict sandboxing and device homogeneity. However, we demonstrated that our approach can produce globally unique fingerprints for iOS devices from an installed app -- around 67 bits of entropy for the iPhone 6S. Calibration fingerprints generated by a website are less unique (~42 bits of entropy for the iPhone 6S), but they are orthogonal to existing fingerprinting techniques and together they are likely to form a globally unique fingerprint for iOS devices.

We have not observed any change in the SensorID of our test devices in the past half year. Our dataset includes devices running iOS 9/10/11/12. We have tested compass calibration, factory reset, and updating iOS (up until iOS 12.1); the SensorID always stays the same. We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SensorID either.

目前提出來的解法是加入隨機值的噪音 (iOS 的作法),不過作者有建議預設應該要關閉 js 存取 sensor 的權限:

To mitigate this calibration fingerprint attack, vendors can add uniformly distributed random noise to ADC outputs before calibration is applied. Alternatively, vendors could round the sensor outputs to the nearest multiple of the nominal gain. Please refer to our paper for more details. In addition, we recommend privacy-focused mobile browsers add an option to disable the access to motion sensors via JavaScript. This could help protect Android devices and iOS devices that no longer receive updates from Apple.


移除 Facebook 上的行動電話

Facebook 上的行動電話號碼除了被拿來當作 2FA 的備案外,也被強制分享。更糟的是還被拿來當作廣告的條件:

目前同時有 TOTP (Facebook 的 app 提供的) 與 U2F,完全不會用到簡訊認證,就拔掉吧...

把 b-mobile 的おかわりSIM 換成 190PadSIM 了

因為有養一個日本號碼的需求 (收簡訊),加上去日本時希望可以有個當地的上網方案,可以在還沒到民宿時使用 (不少民宿會提供分享器讓你帶出去),所以當初辦了 b-mobile 的「b-mobile おかわりSIM 5段階定額」這個方案:第一次的設定費是 JPY¥3000,之後每個月基本費用是 JPY¥630,方案包含了每個月 1GB 的流量,可以付費使用到 5GB 的流量 (額外多收 JPY¥250/GB),用完後限速 200kbps。

一開始的速度不太行,就當作養門號用:「b-mobile 的おかわり的速度」,但後來幾次去日本發現好不少 (Twitch 的 720p 也還看的動),就當作是去日本的網路方案之一了 (會準備備案在需要的時候啟用)。這個方案後來停止申請了,但原來的申請者還是可以繼續用。

後來推出的方案是「b-mobile S 190PadSIM」,從名稱可以看出是設計給平板用的。一樣是 JPY¥3000 的設定費用,但之後每個月的基本費用降到 JPY¥190,不過這個方案只包括了 100MB 的流量,但因為是設計給 Pad 使用者,所以方案設計可以付費使用到 15GB 的流量 (分階段是 JPY¥480/1GB,JPY¥850/3GB,JPY¥1450/6GB,JPY¥2190/10GB 與 JPY¥3280/15GB)。

這個方案就流量單價來說比おかわりSIM 便宜 (差不多是 JPY¥200/GB 上下),不過對於流量在 1GB~2GB 與 3GB~5GB 的部份會變得比較貴,所以切過去也不一定比較好。但可以看到因為基本費用變低不少,對於養門號的人來說省了不少...

先前以為需要重新辦一張卡,就一直沒有動力處理 (設定費用與弄回台灣的成本),直到登入到 b-mobile 後台後發現可以直接改服務就改過去了,要注意的是改完後下個 cycle 才會是新的方案。

台灣各 ISP 的 IPv6 使用情況

看到 zmx 提到:

所以 TWNIC 有弄了「Taiwan IPv6」這個網站頁面出來... 所以就 IPv6 使用率來說,中華不管是在固網還是在行動都是最早投入轉移,使用率也是最高的。

其他家行動的部份可以看出來都有在做,只是比率差異而已,但固網的部份扣掉中華後根本是 0%,雖然說其他固網的量偏小...

JavaScript Framework 不可避免的成本

看到「The Baseline Costs of JavaScript Frameworks」這篇文章在研究目前主流 JavaScript Framework 無法避免的成本到底有多高。

文章的結論是目前常見的 JavaScript Framework 其實都很肥重,在網路速度不快的地方得花不少時間下載,在非旗艦的手機上會需要花不少時間處理 (parse & compile)。

這是 gzip 後的大小:

這是 parse & compile 的時間:

這是下載時間 (扣除 latency 與 TLS connection 建立時間):


But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.

最後有建議如果只是要呈現資訊,不要用整套 JavaScript Framework,在有需要互動的地方另外寫就好了:

For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac,而不是講 app...

這次從高雄回來,在高鐵上想說用手機看看 Trac,發現桌機版的界面是會動,但在手機上不太好用,所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用),標語是「A responsive, flat, blue theme using Bootstrap」,拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整:


Android 打算針對 Data Saver + 2G 網路的使用者關閉 JavaScript 功能

在「Chrome for Android may start disabling JavaScript on 2G connections」這邊看到的,引用的文章是 XDA 的「Google Chrome on Android to disable JavaScript automatically on 2G connections」。

在「Disable scripts for Data Saver users on slow connections」這邊可以看到 Android 的計畫,在打開 Data Saver 的情況下,Chrome 會停用 JavaScript,並且提示使用者:

If a Data Saver user is on a 2G-speed or slower network according to the NetInfo API, Chrome disables scripts and sends an intervention header on every resource request. Users are shown a UI at the bottom of the screen indicating the page has been modified to save data. Users can enable scripts on the page by tapping “Show original” in the UI.

在「Enabled NoScript Preview feature by default on Android」這邊可以看到對應的程式修改。

這樣反而可以少收到很多廣告耶,反倒希望是全域打開 XDDD