WFH 在美國的比重,以及舊金山辦公室的空屋問題

先講結論:COVID-19 前美國的 WFH (Work from home,或是 Remote work) 的比率大約在 5% 上下徘徊,在疫情開始暴增超過 60%,但到現在後疫情時期已經是常態性高過 25% 了。

報導是從「'Return to Office' declared dead」這邊看到的,裡面提到了今年九月發的 paper (可以免費下載):「The Evolution of Work from Home」。

paper 的作者之一 Nick Bloom 在 X (Twitter) 上提到了目前看起來不同來源的結果是一致的:

先從他在九月時發的 paper 抓這張圖出來,裡面提到的 Census Household Pulse Survey 看起來是美國政府的「Measuring Household Experiences during the Coronavirus Pandemic」這份資料,時間是從疫情開始爆發後蒐集的 (2020/04/23):

裡面有兩張圖,先看大的圖,可以看到 2000 年以後 WFH 是有緩慢上升,但也就是 5% 上下。而在疫情開始直接飆升,然後開始降回來。

接下來看小的圖,這是疫情開始的資料,疫情一開始非常高,到 60%+,但可以看到的確從 2021 年開始美國的 WFH 就平穩下來了,大約在 25%~35% 這邊,而且已經平緩下來了。

另外一篇要提的是從房地產的角度看的,報導是「San Francisco now at 35% office vacancy rate, highest ever recorded: data」這篇,提到舊金山辦公室的空房率達到歷史新高的 35%。

在加州的官網上有比較舊的資料 (資料來源不同,所以主要是看趨勢),上面目前最新的資料可以看到 2023 年三月辦公室的空房率是 26% (這份資料裡面有提到最新資料大約晚一季到兩季):「San Francisco Office Space Vacancy」。

算是不同方向的指標交叉看,看起來算一致。

Tor 的 Onion 導入防禦機制,在遭受 DoS 的時候要求用戶端執行 PoW 任務

在「Introducing Proof-of-Work Defense for Onion Services」這邊看到 0.4.8 的新機制,當 Onion 服務受到 DoS 時,會需要 client 提供 PoW 證明,有證明的會優先處理:

Tor's PoW defense is a dynamic and reactive mechanism, remaining dormant under normal use conditions to ensure a seamless user experience, but when an onion service is under stress, the mechanism will prompt incoming client connections to perform a number of successively more complex operations. The onion service will then prioritize these connections based on the effort level demonstrated by the client.

主要原因是傳統遇到 DoS 時可以透過 IP address 之類的資訊設計阻擋機制,但在 Onion 服務裡面沒有這個資訊,所以需要其他方式阻擋:

The inherent design of onion services, which prioritizes user privacy by obfuscating IP addresses, has made it vulnerable to DoS attacks and traditional IP-based rate limits have been imperfect protections in these scenarios. In need of alternative solutions, we devised a proof-of-work mechanism involving a client puzzle to thwart DoS attacks without compromising user privacy.

這個 PoW 機制的說明可以在「torspec/proposals/327-pow-over-intro.txt」這邊看到,看起來是三年前 (2020/04/02) 就提出來了,直到 0.4.8 才推出。

裡面有提到 PoW 的演算法是用 Equi-X

For our proof-of-work function we will use the Equi-X scheme by tevador [REF_EQUIX].

看起來是個方法,而且從 cryptocurrency 後大家對 PoW 的用法愈來愈熟悉了,在這邊用還不錯...

紐約州通過法案,禁止「競業條款」

Hacker News Daily 上看到「New York State Senate passes prohibitions on non-competes (ogletree.com)」這篇,原報導在「New York State Senate Passes Prohibitions on Non-Competes」這。

在原報導裡面給的連結就是紐約州的官方連結,提到了兩個法案:

  • Senate Bill S3100A: Prohibits non-compete agreements and certain restrictive covenants
  • Senate Bill S6748: Relates to actions or practices that establish or maintain a monopoly, monopsony or restraint of trade, and authorizes a class action lawsuit in the state anti-trust law

可以看到兩個都已經通過參議院了,下一步看起來就是送給州長了;其中 S3100A 就是這次提到的反「競業條款」法案,裡面最重要的內容也很簡單,就是直接禁止禁業條款:

2. NO EMPLOYER OR ITS AGENT, OR THE OFFICER OR AGENT OF ANY CORPORATION, PARTNERSHIP, LIMITED LIABILITY COMPANY, OR OTHER ENTITY, SHALL SEEK, REQUIRE, DEMAND OR ACCEPT A NON-COMPETE AGREEMENT FROM ANY COVERED INDIVIDUAL.

在這條前面有定義什麼是「人」與「NDA」,後面有救濟措施以及一些避免鑽法律漏洞的敘述。

等正式通過後對整個美國的影響應該會不小?應該會有一陣子觀望,然後看結果後可能會有其他州也加入...

FBI 警告愈來愈多使用假身份與 Deepfake 技術應徵遠端工作的事件

Hacker News 上看到「FBI: Stolen PII and deepfakes used to apply for remote tech jobs (bleepingcomputer.com)」這個很「有趣」的文章,原報導在「FBI: Stolen PII and deepfakes used to apply for remote tech jobs」,另外 FBI 的公告在「Deepfakes and Stolen PII Utilized to Apply for Remote Work Positions」這邊。

The FBI Internet Crime Complaint Center (IC3) warns of an increase in complaints reporting the use of deepfakes and stolen Personally Identifiable Information (PII) to apply for a variety of remote work and work-at-home positions.

當 deepfake 的技術愈來愈成熟後,這個問題應該會愈來愈嚴重?

另外讓我想到,先前有人發現錄取的人跟面試的人好像不一樣的情況,但一時間找不到那篇文章...

Brendan Gregg 離開 Netflix

Brendan Gregg 宣佈離開 Netflix:「Netflix End of Series 1」,Hacker News 上他也有跳出來回答一些問題:「Netflix End of Series 1 (brendangregg.com)」。

看到有些問題還蠻有趣的,像是被問到桌子的大小:

Off topic: I’m a bit surprised about Gregg’s desk (pre-pandemic). I imagine he’s getting a top level salary at Netflix but yet he’s got a small desk in what it looks to me a shared small office (or perhaps is that a mini open space office? Can’t tell).

大概是在文章裡面有圖,所以被問:

他的回答:

A number of times people have asked about my desk over the years, and I'm curious as to why! I've visited other tech companies in the bay area, and the desks I see (including for 7-figure salary engineers) are the same as everyone else, in open office layouts. At Netflix it's been open office desks, and all engineers have the same desk.

Does some companies give bigger desks for certain staff, or offices, or is it a country thing (Europe?).

目前還沒有提到下一份工作是什麼:

I'll still be posting here in my next job. More on that soon...

在箱型車上安裝六個 Internet 服務 (Remote Work?)

看到「There are six internet links on my office on wheels. Seven when Starlink arrives. Is this the best internet in Australia?」這篇,作者在箱型車上接了六個 Internet 服務,在 Hacker News 上的討論可以翻一下:「There are six internet links on my office on wheels—seven when Starlink arrives (ghuntley.com)」。

作者畫的架構圖:

然後有車子外部的圖片:

另外在這張截圖可以看到其中四個 ISP:

然後作者提到了 Speedify 這個付費軟體 (月費),可以把多個 ISP 的頻寬綁起來,不過我想要看看自己怎麼在 Ubuntu 桌機上搞,畢竟我家裡也有兩條固網 (HiNet北都),能夠自動 failover 就算符合我的用途了...

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡,ap-southeast-1),但發現偶而會很不順,傳輸的時候會很卡,所以後來決定租了一條專線用 AWS Direct Connect 接進去。

不過因為跑在 AWS 上面的服務是掛在 public network 上,而不是 private ip 的網段,所以就不能用 IPsec site-to-site 打通收工,而需要搞 BGP routing,然後就卡關卡的亂七八糟 XD

首先是文書作業的部份,因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權),這部份在 web console 上建立完 Public VIF 後會進入審核階段,接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定,我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。

這邊比較有趣的是,如果你沒有買 support plan 的話無法開 technical support,但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別:「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。

過了審核後接下來是設定 pfSense 的部份,因為是要接通 public network 的部份,所以你要收 AWS 提供的 BGP routing,這部份在 pfSense 上會透過 OpenBGPD 解決,但主要還是因為對 BGP 不熟悉,所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題,不然現在事後來看,自己 tcpdump 應該就有能力找到問題了...

主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。

這是一個 TCP extension,連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改:「Protection of BGP Sessions via the TCP MD5 Signature Option」。

要注意的是這個協定不是 application level,而是在 TCP 層本身就保護起來,包括 3-way handshake 的部份,所以從一開始 SYN 封包過去就要有 md5sig 的資訊。

這也表示用 telnet 不會通是正常的,這點讓我找問題找錯方向好久...

另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD),這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到:

Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.

That module is required for TCP_SIGNATURE to function.

If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.

到了對應的選項那邊要選擇,因為我們的 pfSense 機器比較低階,沒有那堆硬體加速度的東西,所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。

設定完後新的連線也還是不會有效果,後來想了一下還是整台重開機,然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題,純粹就是不熟悉這些東西造成的。

強制每個 Git Repository 都要設定使用者資訊

看到「Setting Up Git Identities」這篇,裡面提到的方法可以解決 Git 裡有多個身份時常見的用錯身份的問題...

個人的 Git repository 會希望用自己的 email address,而公司的 Git repository 則是希望用公司的 email address,但 Git 預設會使用 username 與 hostname 組一個出來,所以常常是推到公司的機器上後才發現 Git repository 沒設定公司的 email address...

上面提到的文章就是關掉 Git 預設會組合的行為,於是就會記得要設定了:

git config --global user.useConfigOnly true

然後記得要把全域設定裡的 nameemail 拔掉,另外有些人可能會掛上 signingkey 也一起拔掉:

git config --global --unset user.name
git config --global --unset user.email
git config --global --unset user.signingkey

這樣當沒設定時想要 git commit,就會被擋下來要求你提供,就能避免把自己的 email address 混在公司的 Git repository 裡面了...

用 PoW 當作防機器人的方式

看到「wehatecaptchas」這個服務試著用 PoW (Proof of work) 擋機器人...

這個方式不需要像 GooglereCAPTCHA 那樣蒐集大量行為 (對隱私不利),也不需要解一堆奇怪的圖片問題。

CAPTCHA 最常用的領域,也就是擋 spam 這件事情來說,PoW 這樣的單一方式應該是不夠,但可以當作綜合方法裡面的一種...