Oalley 這個服務利用「交通時間」來評估地點,最簡單的應用像是給一個地點與時間,畫出範圍:


不過後面是用 OpenStreetMap 的資料,我丟了幾個中文測試好像都找不到,用英文倒是可以...

CloudFront 在東京開到第八個點了...

看到 Amazon CloudFront 宣佈在東京開到第八個點了:「Amazon CloudFront launches eighth Edge location in Tokyo, Japan」。

Amazon CloudFront announces the addition of an eighth Edge location in Tokyo, Japan. The addition of another Edge location continues to expand CloudFront's capacity in the region, allowing us to serve increased volumes of web traffic.

這個成長速度有點驚人,一月才加了兩個,現在又要再加一個... 不過大阪還是維持一個。

南韓出手調查 Google 未經同意蒐集位置資訊的問題了

在「就算關掉 Google 的定位服務也還是會蒐集位置資訊...」這邊提到的蒐集問題,南韓出手調查了:「Regulators question Google over location data」。

Regulators in South Korea summoned Google (GOOGL, Tech30) representatives this week to question them about a report that claimed the company was collecting data from Android devices even when location services were disabled.


U.K. data protection officials are also looking into the matter.

美國與歐盟其他國家反而還沒看到消息... (不過美國有可能是以訴訟的方式進行)

就算關掉 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 的進展...」)

iOS 11 將 Location 的主權交還給使用者

Hacker News Daily 上看到這則 tweet,說 iOS 11 將會把 Location 的主權交還給使用者控制:

查了對應的一些網站,可以看到好幾個站台都有介紹這一點:「iOS 11 Users to Gain More Control Over Apps' Use of Location Services」、「iOS 11 gives users tighter control over when apps can use their location」。

TechCrunch 標題寫的更直接,其實影響最直接的就是這些 app:「iOS 11 stops apps like Uber and Waze from accessing user location data at all times」。

算是不錯的消息啦... (Android 上則可以看「Background Location Limits」,這邊是 Android O 的新功能...)

Amazon CloudFront 又增加東京機房了...

CloudFront 又增加東京的點了,這是第四個點:「Amazon CloudFront adds new Edge Locations in Tokyo, Japan and Dallas/Fort Worth, Texas」。

This is our fourth edge location in the Tokyo area and our third in Dallas, bringing the total number of CloudFront locations to 87 (including 76 points of presence and 11 regional edge cache locations).


CloudFront 在慕尼黑加到第五個機房...

德國是歐洲區重要的交換中心,不過量大到可以讓 CloudFront 加到第五個點就頗意外的:「Announcing New Munich Edge Location for Amazon CloudFront, our 7th Edge Location in Germany」。


The Munich location is our third location in Germany (joining Frankfurt and Berlin), and our 7th edge location in Germany bringing the total number of worldwide edge locations to 69.

Nginx + FastCGI + Trac

先前試著逼自己用 Phabricator,用了一個多月後發現設計的邏輯還是跟 Trac 差了不少,算是為了 Facebook 特化的產品吧。在這一個月查資料的過程也發現當初 Wikimedia 要採用的時候也花了不少力氣送 patch 回官方,然後針對不少地方客製化調整。

另外比較痛的地方是 plugin 的支援能力還沒有很好,變成很多東西都要改主體... 而且效能也不太好 (不支援 PHP 7.0 還蠻痛的),在比較低階的 VPS 上跑特別明顯。

這幾天花了點時間把 Trac 給架起來,之前都是用 FreeBSD ports 架,但已經愈來愈沒有再接觸 FreeBSD 了,所以這次在 Ubuntu 上用 pyenv 裝起來再用 pip 裝起來。

另外一個跟之前不同的,是先前都用 Apachemod_wsgi,在低階的 VPS 上則是要找省資源的方案,這次則是用 nginx + FastCGI 去接,比起之前複雜不少...

最主要是參考了官方的文件以及「Gentoo下使用nginx+fastcgi部署trac」這邊的說明達到效果,重點是這段 location 的設定:

    location / {
        auth_basic "trac realm";
        auth_basic_user_file /srv/domain.example.com/.htpasswd;

        include fastcgi.conf;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param HTTPS on;
        fastcgi_param PATH_INFO $fastcgi_script_name;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_NAME "";
        fastcgi_pass unix:/var/run/trac/trac.sock;

    location /.well-known/acme-challenge/ {
        alias /var/www/dehydrated/;

網路上有找到用 location ~ (/.*) 去 match,然後拉出 $1PATH_INFO 用的,這這會使得這段 location 的優先權太高 (參考官方對於 location 的順序說明),而蓋掉下面 Let's Encrypt 的 acme challenge 過程,所以還是得這樣搞。

另外是自己一個人用,就用 .htpasswd 的方式認證了,沒必要弄 LDAP 之類的認證...

接下來就是裝一堆 plugin 並且調整 css/js 與 SQL query 了...

Facebook 大量蒐集 GPS 定位資訊後用機械學習「猜測」你可能認識的人

Bruce Schneier 這邊看到「Facebook Using Physical Location to Suggest Friends」這則文章,引用自「Facebook is using your phone’s location to suggest new friends—which could be a privacy disaster」這篇報導,報導開頭寫著更新的資訊:

Update (June 28): After twice confirming it used location to suggest new friends, Facebook now says it doesn’t currently use “location data, such as device location and location information you add to your profile, to suggest people you may know.” The company says it ran a brief test using location last year. New story here.

Facebook 第二次確認後發現是標準的「啊!靠腰!是 PR 災難」的處理方式。在第一次跟 Facebook 確認時,Facebook 發言人的正式回覆說明了手機的位置是計算的條件之一:

“People You May Know are people on Facebook that you might know,” a Facebook spokesperson said. “We show you people based on mutual friends, work and education information, networks you’re part of, contacts you’ve imported and many other factors.”

One of those factors is smartphone location. A Facebook spokesperson said though that shared location alone would not result in a friend suggestion, saying that the two parents must have had something else in common, such as overlapping networks.

“Location information by itself doesn’t indicate that two people might be friends,” said the Facebook spokesperson. “That’s why location is only one of the factors we use to suggest people you may know.”


Facebook 更新 iOS 應用程式,修正吃電問題

在「在 iOS 上不使用 Facebook App 時要完全砍掉 process」這邊提到了 Facebook 在 iOS 版的應用程式會在背景播放無聲音樂,導致吃電特別兇的問題,Facebook 的 Ari Grant 出來澄清是 bug 造成的,而非故意行為。

修正了兩個 bug,第一個是 network code 的部分:

The first issue we found was a “CPU spin” in our network code. A CPU spin is like a child in a car asking, “Are we there yet? Are we there yet? Are we there yet?”with the question not resulting in any progress to reaching the destination. This repeated processing causes our app to use more battery than intended. The version released today has some improvements that should start making this better.

第二個則是之前提到無聲 audio 的問題:

The second issue is with how we manage audio sessions. If you leave the Facebook app after watching a video, the audio session sometimes stays open as if the app was playing audio silently. This is similar to when you close a music app and want to keep listening to the music while you do other things, except in this case it was unintentional and nothing kept playing. The app isn't actually doing anything while awake in the background, but it does use more battery simply by being awake. Our fixes will solve this audio issue and remove background audio completely.


The issues we have found are not caused by the optional Location History feature in the Facebook app or anything related to location. If you haven't opted into this feature by setting Location Access to Always and enabling Location History inside the app, then we aren't accessing your device's location in the background. The issues described above don't change this at all.