GrabFood 用定位資料修正餐廳的資訊

Grab 的「How we harnessed the wisdom of crowds to improve restaurant location accuracy」這篇是他們的 data team 整理出來,如何使用既有的資料快速的修正餐廳資訊。裡面提到的方法不需要用到 machine learning,光是一些簡單的統計算法就可以快速修正現有的架構。

這些資訊其實是透過司機用的 driver app 蒐集來的,在 driver app 上有大量的資訊傳回伺服器 (像是定時回報的 GPS 位置,以及取餐狀態),而這些司機因為地緣關係,腦袋裡的資訊比地圖會準不少:

One of the biggest advantages we have is the huge driver-partner fleet we have on the ground in cities across Southeast Asia. They know the roads and cities like the back of their hand, and they are resourceful. As a result, they are often able to find the restaurants and complete orders even if the location was registered incorrectly.


Fraction of the orders where the pick-up location was not “at” the restaurant: This fraction indicates the number of orders with a pick-up location not near the registered restaurant location (with near being defined both spatially and temporally as above). A higher value indicates a higher likelihood of the restaurant not being in the registered location subject to order volume

Median distance between registered and estimated locations: This factor is used to rank restaurants by a notion of “importance”. A restaurant which is just outside the fixed radius from above can be addressed after another restaurant which is a kilometer away.

另外也有不少其他的改善 (像是必須在離餐聽某個距離內才能點「取餐」,這個「距離」會因為餐聽可能在室內商場而需要的調整),整個成果就會反應在訂單的取消率大幅下降:

整體看起來是系統產生清單後讓人工後續處理 (像是打電話去店家問?),但這個方式所提供的清單準確度應該很高 (因為司機不會沒事跟自己時間過不去,跑到奇怪地方按下取餐),用這些資料跑簡單的演算法就能夠快速修正不少問題...

Adobe Security Team 直接把 Private Key 貼到網誌上面...

Security Team 出這種包...:「In spectacular fail, Adobe security team posts private PGP key on blog」。

Adobe 這次的事情要怎麼說呢,hmmm...

GitHub 的組織管理可以堆階層了...

GitHub 的組織管理可以堆階層了:「Nested teams add depth to your team structure」。

If you're a member of Engineering and someone creates a child team called Security, team members of Engineering aren't automatically direct team members of Security. Security and all other teams nested under the Engineering will inherit repository permissions and @mentions but nothing else.


這功能等好久了,剛好最近會用到... 本來得硬幹做,現在看起來可以比較方便的管理了。

Stripe 的 Increment 雜誌

Stripe 推出了 Increment 雜誌,講團隊合作時的各種議題:「Introducing Increment」。

And so we've decided to start Increment, a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.


A digital magazine about how teams build and operate software systems at scale.

Increment is dedicated to covering how teams build and operate software systems at scale, one issue at a time.

可以看一看 Stripe 對團隊合作的想法...

BGPmon 推出 BGP Stream 警告異常的 BGP 流量劫持

也是兩個禮拜前的新聞,在「OpenDNS BGP Stream Twitter Feed」這邊提到了 BGPmon 將會推出 BGP Stream 服務,將偵測到的 BGP 異常變化發到 Twitter 上。

其中 BGPmon 在幾個月前被 OpenDNS 併購 (2015 年 3 月),而 Cisco 則在上上個月底併購了 OpenDNS (2015 年 6 月)。而在過幾天的 DefCon 23 上將會透露更多細節。

前陣子 Hacking Team 洩漏的資料中就用到了 BGP hijack 來取回控制權:

That nugget that emerged from the 400 Gb of stolen Hacking Team data posted online where Italian law enforcement used Hacking Team’s Remote Control System monitoring software to regain control over a number IP addresses it was watching that were already infected with Hacking Team software by hijacking BGP routes in order to redirect traffic and regain control over a target’s machines.

除了示警外,另外一方面 BGP 上的簽名技術也愈來愈重要了,只是不知道最終會怎麼做...

Hacking Team 的 BGP Routing Hijack

Hacking Team 的事情告訴我們,只能是能做的,都有人會包成 Total Solution 賣。

洩漏出來的資料說明了 Hacking Team 在 2013 年幹的 BGP Routing Hijack:「How Hacking Team Helped Italian Special Operations Group with BGP Routing Hijack」。

The Wikileaks document described how the Italian ROS reached out to Hacking Team to work together on recovering the VPS server that ran on In ROS terminology, the server was called “Anonymizer”. The emails also revealed that this server relays updates to another back end server called “Collector” from which ROS presumably recovers the targets’ data.


When we look at historical BGP data we can confirm that AS31034 (Aruba S.p.A) indeed started to announce the prefix starting on Friday, 16 Aug at 2013 07:32 UTC. The Wikileaks emails outline how ROS complained to Hacking Team that the IP was reachable only via Fastweb but not yet through Telecom Italia, concluding not all RCS clients were able to connect back to the server immediately, since the prefix was not seen globally. BGP data further confirms this per the visualization below.

這些主要的 ISP 分別是:

AS12874 Fastweb
AS6939 Hurricane Electric, Inc.
AS49605 Reteivo.IT
AS4589 Easynet
AS5396 MC-link Spa


這也證明了「鎖 IP」的方法其實還是很危險的。

Hacking Team 購買 Flash Exploit 的信件

前情提要:「Hacking Team 被黑而洩漏出來的資料」。

在「How a Russian hacker made $45,000 selling a 0-day Flash exploit to Hacking Team」這邊提到了 Hacking Team 被黑而洩漏出來的信件,透漏了俄羅斯的人賣 Flash Exploit 給 Hacking Team 的過程。


1) The price is US$45,000.00 for the non-exclusive sale of any special discount for the "first" deal together will be greatly appreciated :)


The two men then exchanged PGP keys, which they used to exchange a number of encrypted messages, presumably one including how Toporov would like to be paid.

然後還有 invoice:

而買了幾個建立關係後,後面還會有 discount:

Now your discount on the next buy is -5k and -10k is for a third bug.


Hacking Team 被黑而洩漏出來的資料

這幾天資安領域最熱鬧的消息莫過於 Hacking Team 被黑之後洩漏出來的 400GB+ 的資料:「Hacking Team hacked, attackers claim 400GB in dumped data」、「Hacking Team hacked, attackers claim 400GB in dumped data」。

洩漏的資料可以在 GitHub 上的「hackedteam」取得,或是透過 BitTorrent 取得 (i.e. 51603bff88e0a1b3bad3962614978929c9d26955)。

烏雲上的「人手一份核武器 - Hacking Team 泄露(开源)资料导览手册」這篇寫得很完整了,現在的系統已經整合到這樣,於是要對這個人做任何事情都很容易:

也因為這次的 leak 而使得不少軟體在修正 0day exploit...


KKBOX 徵人:軟體開發中心 (i.e. Client Team)


在寫自家的介紹時,特地跑去跟軟體開發中心的主管要 Client Team 的介紹,人家交稿的速度快多了... Q_Q

Anyway,這篇是由 Client Team 的主管所寫的介紹,一樣是所有的部門都有職缺 (人力銀行上未必有開),有興趣的可以提供 resume 到 recruit at 這個信箱。

軟體開發中心 (Application Develop)

在 KKBOX 裡頭,我們還蠻習慣以老派的 Client/Server Side 來稱呼不同技術背景的開發人員,Client Side 說穿了就是開發 App 的那群人,只要你喊得出來的主要平台,大概就是我們負責的。

軟體開發隨著功能的演進,程式碼就會變得又肥又大,自然免不了些壞味道,面臨設計架構的難題,我們希望內部開發者能夠清楚三件事情: Design Pattern,Unit Test,和 Refactoring。上述觀念應當不用多說什麼,幾乎都變成顯學了。我們期盼透過一些原則和流程來讓開發工作變得不會那麼難以維護。

Client Side 目前共有四個 App 開發部門和 SQA 部門:

  1. Windows 開發部: KKBOX 在早期開發時,當時主流的作業系統還是 Windows XP,所採用的開發框架是 MFC,儘管技術很老,但那是個什麼事情都可以自己打造的年代,我們也樂此不疲。會用到 C++/COM 與微軟早年推出的視窗各類技術 MFC/ATL/DirectShow 。說個秘密,我們也還最低限度的維護著 KKman 呢。
  2. .NET 開發部: 主要負責的是 Windows Store App 和 Windows Phone 的開發,採用的是微軟在下個世代主推的 Universal App 開發框架來打造 KKBOX 在三個 Windows 平台的體驗。這部門需要熟悉的程式語言是 C#,部門有兩位微軟 MVP 相當熟悉微軟的平台技術,很活躍於微軟舉辦的聚會。
  3. Android 開發部: 很明顯地,就是在 Android 手機作業系統上開發 App 的部門,除了手機之外,我們也在 Tablet / STB / Smart TV 各式裝載 Android 系統的裝置上開發。需要熟悉 Java 程式語言和 Google Android SDK。這部門的開發人員很常在 Android Taipei 上出沒,分享開發心得。
  4. iOS 開發部: 聽名字應該也不用多解釋,主要就是在 Mac/iPhone/iPad 上開發 App,為了掌握最新技術每年我們都會派人前往舊金山參加 WWDC。需要會的程式語言是 Objective-C,當然蘋果力推的 Swift 也開始加入開發行列,每個月也都在 CocoaHeads 聚會中跟其他開發者閒聊。
  5. 測試開發部: 俗稱 SQA 部門,著重依據測試的原理和方法來設計測試案例,因此像是黑箱測試方法的 BVA 和 ECP,以及 MBT … 等等都是在設計測試案例時,會用到的測試原理。內部有個小組專門負責研究與建置自動化測試框架,讓各個專案可以各自依照需求建立自己的測試系統。需要熟悉 Python 程式語言,同時我們也將日常得到的心得放在「科科和測試 Testing with KK」上,提供給同樣想把軟體測試工作做好的每個人。

順道一提,除了 KKBOX 以外,還有 KKTIX,Hami Music 和日本服務 Utapass,也都是上述開發部門負責的。所以你要真的那麼愛寫 App 的話,那這裡應該蠻適合你的。