Home » Posts tagged "id"

就算關掉 Google 的定位服務也還是會蒐集位置資訊...

就如標題所寫的,Quartz 獨家刊出來的新聞,即使你關掉 Google 的定位服務,Google 還是會蒐集你的位置 (而且跟 Google 發言人確認後也證實):「Google collects Android users’ locations even when location services are disabled」。

而且是全背景作業,在你沒有開定位服務,沒有插 SIM 卡,也沒有跑任何 app,他就會將定位資訊傳出去:

Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card?

從今年年初開始這樣搞的,Google 發言人只宣稱這個資料並沒有被用來整合到「network sync system」,並且會立即丟掉 (所以你還是不知道被用到什麼地方):

“In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery,” the Google spokesperson said in an email. “However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID.”

這句話的意思其實代表著是丟掉 raw data,改以統計的方式轉移存到其他系統。

另外 John Gruber 在「Google Collects Android Users' Locations Even When Location Services Are Disabled」其實寫的更直接:

If they were “never used or stored”, why did they start collecting them in the first place? This is like a kid caught with their hand in the cookie jar saying they weren’t going to eat any cookies. Sure.

白話一點就是「你當我傻逼啊」。

應該會促進 microG 的發展... (參考「microG 的進展...」)

解鎖 iPhone 的 Diper ID...

Twitter 上看到 Diper ID 這個糟糕的東西:

查了資料,操作方式可以從這個影片看到:

這明顯有資安問題啊 XDDD

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview:「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點,第一個在善用 RedisHyperLogLog 這個資料結構,當量大的時候其實可以允許有微小的誤差:

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時,用 1.5KB 的記憶體只有 2% 的誤差值:

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應),透過批次處理降低對 Cassandra cluster 的負荷:

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來),而使用 Cassandra 存 key-value 非常容易 scale,但讀取很慢。剛好兩個相輔相成。

配合 Touch ID 的 sudo

大概是新的 Macbook 出來後想出來的點子?透過 Touch ID 驗證 sudo 權限:「A fork of `sudo` with Touch ID support.」。

sudo-touchid is a fork of sudo with Touch ID support on macOS (powered by the LocalAuthentication framework). Once compiled, it will allow you to authenticate sudo commands with Touch ID in the Terminal on supported Macs (such as the late 2016 MacBook Pros).

這點子好像還不錯 XDDD

PGP 短 ID 的安全問題

PGP 短 ID 的安全問題出來了,不見棺材不掉淚啊:「Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs.」。

重點在這段,已經有人發出攻擊了:

Search Result of 0x00411886: https://pgp.mit.edu/pks/lookup?search=0x00411886&op=index
Fake Linus Torvalds: 0F6A 1465 32D8 69AE E438  F74B 6211 AA3B [0041 1886]
Real Linus Torvalds: ABAF 11C6 5A29 70B1 30AB  E3C4 79BE 3E43 [0041 1886]

Search Result of 0x6092693E: https://pgp.mit.edu/pks/lookup?search=0x6092693E&op=index
Fake Greg Kroah-Hartman: 497C 48CE 16B9 26E9 3F49  6301 2736 5DEA [6092 693E]
Real Greg Kroah-Hartman: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 [6092 693E]

另外作者給了還蠻重要的觀念:

DO NOT TRUST ANYTHING SHORTER THAN THE FINGERPRINTS.

PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善,尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性:

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象:

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份:

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是,agreesive vacuum 相較於 vacuum 會多吃很多資源,但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較):

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現,不知道會不會變 default...

新的 AWS 帳號將會自動啟用 Long EC2 Resource ID

新的 AWS 帳號將會自動啟用長版的 Resource ID:「New accounts default to long EC2 resource IDs on March 7」。

還是可以 opt-out 改回來,不過官方還是建議儘量用長的 ID 測試,因為今年年底將全面強迫使用:

We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.

Archives