Tag: linkedin

LinkedIn 把 SlideShare 賣給 Scribd 了

收到 SlideShare 的信件，提到了 Scribd 接手的事情：「Digital library leader Scribd has acquired SlideShare」，另外 Scribd 這邊也有新聞稿：「Welcome SlideShare to the Scribd community」。

信裡面提到會在九月 24 日生效：

Scribd will begin operating the SlideShare business on September 24, 2020.

另外在 TechCrunch 這邊也有報導「Scribd acquires presentation-sharing service SlideShare from LinkedIn」，看起來目前還沒有小道消息知道轉手的價錢：

SlideShare has a new owner, with LinkedIn selling the presentation-sharing service to Scribd for an undisclosed price.

hiQ 爬 LinkedIn 資料的無罪判決

hiQ 之前爬 LinkedIn 的公開資料而被 LinkedIn 告 (可以參考 2017 時的「hiQ prevails / LinkedIn must allow scraping / Of your page info」)，這場官司一路打官司打到第九巡迴庭，最後的判決確認了 LinkedIn 完全敗訴。判決書在「HIQ LABS V. LINKEDIN」這邊可以看到。

這次的判決書有提到當初地方法院有下令 LinkedIn 不得用任何方式設限抓取公開資料：

The district court granted hiQ’s motion. It ordered LinkedIn to withdraw its cease-and-desist letter, to remove any existing technical barriers to hiQ’s access to public profiles, and to refrain from putting in place any legal or technical measures with the effect of blocking hiQ’s access to public profiles. LinkedIn timely appealed.

而在判決書裡其他地方也可以看到巡迴庭不斷確認地方法院當時的判決是合理的，並且否定 LinkedIn 的辯解：(這邊只拉了兩段，裡面還有提到很多次)

In short, the district court did not abuse its discretion in concluding on the preliminary injunction record that hiQ currently has no viable way to remain in business other than using LinkedIn public profile data for its Keeper and Skill Mapper services, and that HiQ therefore has demonstrated a likelihood of irreparable harm absent a preliminary injunction.

We conclude that the district court’s determination that the balance of hardships tips sharply in hiQ’s favor is not “illogical, implausible, or without support in the record.” Kelly, 878 F.3d at 713.

到巡迴庭差不多是確定的判決了，沒有其他特別的流程的話...

LinkedIn 用機器學習提供雇主可能的職缺對象

先前看到「Learning Hiring Preferences: The AI Behind LinkedIn Jobs」這篇，LinkedIn 用機器學習提供雇主可能的對象。

依照官方的說法，這次提到的改進是透過雇主的行為調整推薦。當雇主對某個人有興趣的時候，LinkedIn 就會調整演算法去配合雇主有興趣的條件：

Based on how you interact with candidates, our algorithm learns your preferences and delivers increasingly relevant candidates across the Jobs product. If you’re consistently interested in candidates who are, say, accountants with leadership skills, or project managers who are adept at social media, we’ll send you more of those. And this all happens online in real time so that your feedback is taken instantly into account.

透過模擬 20% 的加成：

This new algorithm, which is used throughout the Jobs platform, performs nearly 20% better than the previous version in generating recommendations when we simulate our members' past hiring activity.

在 social network 這種演算法其實就是同溫層 (Echo chamber、Filter bubble)，在 LinkedIn 這樣的行為不知道會不會牽扯到 Discrimination 的議題...

在 AWSUG Taiwan 上講的「用 AWS CodeDeploy 解決程式佈署」

前幾天在 AWSUG Taiwan 上講了「用 AWS CodeDeploy 解決程式佈署」，連結是投影片網址，因為在 Speaker Deck 上找不到 embed code 了，只好這樣連結過去。

話說回來，要上傳投影片的時候才發現，這兩個投影片 hosting 服務都跟微軟有些關係... 首先是 SlideShare 在 2012 被 LinkedIn 買下，然後 LinkedIn 在 2016 年賣給了微軟。

SpeakerDeck (或者說，Ordered List 這家公司) 本來在 2011 年賣給了 GitHub，但今年六月的時候被買回去了：

不知道買回去是不是跟微軟要買 GitHub 有關...

LinkedIn 忘記續約導致 SSL Certificate 過期

Netcraft 上看到 LinkedIn 出包的消息，這次是 country-mixed 的版本出包：「LinkedIn certificate blunder leaves users LockedOut!」。

在 DNS 上也可以看出來這兩個 CNAME 到不一樣的 load balancer 上：

;; ANSWER SECTION:
www.linkedin.com.       260     IN      CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 93 IN   CNAME   pop-ehk1.www.linkedin.com.
pop-ehk1.www.linkedin.com. 3560 IN      A       144.2.3.1
;; ANSWER SECTION:
de.linkedin.com.        86400   IN      CNAME   cctld.linkedin.com.
cctld.linkedin.com.     86400   IN      CNAME   mix.linkedin.com.
mix.linkedin.com.       213     IN      CNAME   pop-ehk1.mix.linkedin.com.
pop-ehk1.mix.linkedin.com. 3546 IN      A       144.2.3.5

而 SSL Labs 上也看得出來在 Alternative names 的地方是不一樣的：「SSL Server Test: www.linkedin.com (Powered by Qualys SSL Labs)」、「SSL Server Test: de.linkedin.com (Powered by Qualys SSL Labs)」。

然後因為 LinkedIn 有設定 HSTS，所以使用者在界面上完全無法登入：

在 Google Chrome 上可以用 badidea 繞過 (參考「在 Google Chrome 連上因 HSTS 而無法連線的網站」)，但在 Mozilla Firefox 上的話目前沒找到方法可以在界面上 bypass，而是需要改 SiteSecurityServiceState.txt 這個檔案：「HTTP Strict Transport Security prevents me from accessing a server that I'm doing development on」。

不過也因為兩個 cluster 獨立運作，網址改一下應該就會動了...

這幾年比較很少看到大公司出這種包，還蠻有趣的 XD

LinkedIn 在 2012 年的密碼外洩比想像中嚴重，超過一億筆帳號密碼洩漏

在「Another Day, Another Hack: 117 Million LinkedIn Emails And Passwords」這邊看到 LinkedIn 在 2012 年的帳號密碼外洩情況比想像中嚴重許多，當時大家認為只有 650 萬筆資料洩漏，但實際上在 2016 年的現在被確認有 1.17 億筆。

官方也確認 2016 的這份洩漏是正確的，兩份公告在：

很多人都收到 password reset 信件了...

LinkedIn 的工程師分析 TCP Anycast 技術的穩定性與效能

LinkedIn 的工程師測試了 TCP Anycast 技術的穩定性以及效能：「TCP over IP Anycast - Pipe dream or Reality?」。

由於 stateless 再加上一個封包就傳的完的情況下，Anycast 技術被用在 DNS 上已經很長一段時間了，目前大多數 CDN 業者也都有用 Anycast 技術加快 CDN 的回應速度。

但 TCP 因為 stateful，如果 router 上採用的方式有問題，那麼就會導致封包可能會送到不同節點，這會是個嚴重的問題。不過很早之前，幾乎所有的骨幹 router 都已經支援 flow-based load balancing policy：

Most routers now do a per-flow load balancing, meaning packets on a TCP connection are always sent over the same path, but even a small percentage of routers with per-packet load balancing can cause the website to be unreachable for users behind that router.

所以 LinkedIn 的人試著測試 TCP Anycast 技術的穩定性：

So, to validate the assumption that TCP over anycast in the modern internet is no longer a problem, we ran a few synthetic tests.

測試的方式是設定 web server，讓下載速度不快，然後設了好幾個點並且放出對應的 routing，用 Catchpoint 服務監控，如果不穩定的話，應該就會收到 RST 中斷連線：

We configured our U.S. PoPs to announce an anycast IP address and then configured multiple agents in Catchpoint, a synthetic monitoring service, to download an object from that IP address. Our web servers were configured to deliberately send the response back slowly, taking over a minute for the complete data transfer. If the internet was unstable for TCP over anycast, we would observe continuous or intermittent failures when downloading the object. We would also observe TCP RSTs at the PoPs.

而好消息是，測試起來相當穩定：

But even after running these tests for a week, we did not notice any substantial instability problems! This gave us confidence to proceed further.

所以也因此可以看到 CacheFly 與 CloudFlare 兩家採用 TCP Anycast 技術：

[S]ome popular CDNs have also started using anycast for HTTP traffic.

由於穩定性的部份沒問題，所以接下來就是討論效率。

Anycast 是基於 routing 而決定要怎麼走，目標是希望可以透過 routing 取得 latency 最低的點。但實務上會把成本考慮進去，有可能會走到比較遠的點。在測試中可以發現北美的部份 Anycast 表現的比 GeoIP 好，但離開北美就掉很多：

所以 LinkedIn 決定用「Regional Anycast」，先用 GeoIP 決定要丟到哪個洲，而每個洲共用一個 Anycast 位置，這個方法讓效能提昇不少，全球在分配時 sub-optimal 的比率從 31% 降到 10% (i.e. 沒有分配到最好的點的比率)：

上面主要是讀 LinkedIn 文章的心得，後面就是感想了。

TCP Anycast 用 CDN 上其實是相當吃虧的技術，由於 routing 的掌控權不再自己手上，有很多重要的手段是沒辦法做到的。

首先是當對外流量已經滿載時，不能切換到其他機房的機器，這邊講的「對外流量」不是 CDN 本身而已，而是中途任何的線路滿載都算，像是 HiNet 對 CloudFlare 香港機房的情況就很明顯。

另外在被 DDoS 時，由於沒辦法導流，在被攻擊時幾乎只剩下 clean pipe 類的解法，而同時間其他用戶會因為流量大量流入機房而一起被波及到。GeoIP 的方式彈性就大很多。

當然，還是有可以列出來的好處。主要是對於需要有固定 IP 應用來說 (像是 firewall 設定需求)，TCP Anycast 滿足了這點。

只能說不同市場有不同的產品線在供應啦，不同的情境下有不同的需求...

LinkedIn 依照他們的資料對美國的大專院校排名

在 Slashdot 上看到 LinkedIn 對美國的大專院校排名：「Be True To Your CS School: LinkedIn Ranks US Schools For Job-Seeking Programmers」。

軟體工程師的部份在這邊：「LinkedIn 大學排名 — 軟體開發人員」。Slashdot 上的 comment 瞬間就戰起來，然後還有人跑出來問怎麼沒有美國外的資料 XDDD

CMU 第一名不算奇怪，但 Stanford 意外的後面？

WebScaleSQL

WebScaleSQL 是 Facebook、Google、LinkedIn 以及 Twitter 四家公司對 MySQL 5.6 的 fork。

而 Percona 的人也針對 WebScaleSQL 與 Percona Server 5.6 的比較，寫了一篇技術分析的文章：「A technical WebScaleSQL review and comparison with Percona Server」。

Percona 那篇分析文章提到不少改善屬於比較激進類型，對於 Percona Server 以及 MySQL 官方版本的定位並不適合。

而在開發上，語法也換到 C99 與 C++11，也就是打算拋棄很舊的系統 (沒有 C99/C++11 compiler)。不過就這點來說，使得這上面的 patch 要 backport 回 MySQL 又增加了一些狀況...

WebScaleSQL 的出現代表 MySQL fork 又多一家，而且因為背後是這四家公司搞出來的，看起來聲勢會很浩大。進入「合久必分」的階段...