Tag: control

把 git log 用得很開心...？

看到「git log – the Good Parts」這篇文章，裡面研究了 Git 裡 git log 的各種好用的功能，然後整理出來... (所以是 good parts XD)

作者用的參數是一個一個加上去，所以可以一個階段一個階段了解用途。除了可以用作者推薦的 repository 測試外，我建議大家拿個自己比較熟悉的 open source 專案來測 (有用到比較複雜的架構)：

git log
git log --oneline
git log --oneline --decorate
git log --oneline --decorate --all
git log --oneline --decorate --all --graph

看到喜歡的部份可以在 ~/.gitconfig 裡設 alias 使用，像是用 git l 之類的？保留 git log 本身可以避免一些 script 用到這個指令時因為輸出格式跟預期不一樣而爛掉 XD

Firefox 對 HTTPS 網站中 "Referer" 的保護

Firefox 從 59 之後，在開啟 Private Browsing 的情況下，不會送出完整的 Referer：「Preventing data leaks by stripping path information in HTTP Referrers」。

這篇吸引到我的是 EFF 的研究員發現的事情：

EFF researchers discovered this leak of personal health data from healthcare.gov to DoubleClick.

其中 EFF 研究員的文章是「HealthCare.gov Sends Personal Data to Dozens of Tracking Websites」這篇。

更好的作法應該是平常就完全阻擋，像是 Firefox 可以用 Referrer Control 設定，或是 Chrome 裡用 Referer Control 設定。

新書廣告「為你自己學Git」

Disclosure：我跑去找作者簽名，然後被戳說要介紹廣告一下 XDDD

這是本講 Git 的書，翻內容後的感覺... 定位差不多在入門使用者與中階使用者。先引用作者在 Twitter 的 tweet：

在天瓏掛第一，然後出版社通知要二刷了，應該是賣的還不錯 XDDD

書的章節可以參考「天瓏網路書店-為你自己學Git」這邊，內容是以 Command Line 為主，對於真的要把 Git 用好蠻有幫助的。除此之外，實務上常見的問題都有提到 (像是搞爛東西後可能的解法)，也講了不少冷知識，對於理解 Git 內怎麼運作會有幫助...

唯一覺得奇怪的地方應該是在最後兩章，講 GitHub 與 Git Flow (也就是「A successful Git branching model」這邊提出來的方法)，反而不是 GitHub Flow... 雖然在 GitHub 上也可以走 Git Flow 啦。

用 Xbox 控制器操控潛艇

拿民用品當作軍事器材不是第一次了，不過拿來操作潛艇倒是蠻值得看一下的：「The U.S. Navy's most advanced submarines will soon be using Xbox controllers」。

在 lab 環境測試的畫面。

原因頗簡單，就是成本考量，而且很容易取得：

The company says the photonic mast handgrip and imaging control panel that cost about $38,000 can be replaced with an Xbox controller that typically costs less than $30.

不過有個問題啊，軍用品一般都可以抵抗 EMP，這種民用品應該不行吧 XDDD

Mozilla 的提案「HTTP Immutable Responses」

狀態已經是 Category: Standards Track 了，RFC 8246 的「HTTP Immutable Responses」：

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

對 Cache-Control 介紹了 immutable，像是這樣：

Cache-Control: max-age=31536000, immutable

依照 MDN 上的資料 (Cache-Control - HTTP | MDN)，目前只有 Edge 與 Firefox 支援，不過既然成為標準了，後續其他瀏覽器應該都會支援 (吧)：

在 Git/Mercurial/Subversion 上 "-" 發生的問題

在「[ANNOUNCE] Git v2.14.1, v2.13.5, and others」這邊看到 - 開頭產生的問題：

These contain a security fix for CVE-2017-1000117, and are released in coordination with Subversion and Mercurial that share a similar issue. CVE-2017-9800 and CVE-2017-1000116 are assigned to these systems, respectively, for issues similar to it that are now addressed in their part of this coordinated release.

這算是老問題了，Git 對應的修正主要是朝 filter input 的方向修正，包括了禁用 - 開頭的 hostname，以及禁止 GIT_PROXY_COMMAND 是 - 開頭，另外是禁止開頭是 - 的 repository name：

  • A "ssh://..." URL can result in a "ssh" command line with a hostname that begins with a dash "-", which would cause the "ssh" command to instead (mis)treat it as an option. This is now prevented by forbidding such a hostname (which should not impact any real-world usage).
  • Similarly, when GIT_PROXY_COMMAND is configured, the command is run with host and port that are parsed out from "ssh://..." URL; a poorly written GIT_PROXY_COMMAND could be tricked into treating a string that begins with a dash "-" as an option. This is now prevented by forbidding such a hostname and port number (again, which should not impact any real-world usage).
  • In the same spirit, a repository name that begins with a dash "-" is also forbidden now.

然後中華電信的 DNS server (168.95.1.1 & 168.95.192.1) 都查不到 marc.info，改用 Google 的 8.8.8.8 才查得到... =_=

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 的新功能...)

Web Cache Deception Attack

在「How (Not) to Control Your CDN」這邊看到了「Web Cache Deception Attack」這個攻擊方式。

攻擊的手法是利用網站會把 /user/personal-info/foo.css 與 /user/personal-info 視為一樣的內容時，配合 CDN 或是 reverse proxy server 會把 .css 設定無差異 cache 時，就可以在 cache server (cache edge) 取得使用者的敏感資料。

這主要是 url routing 的條件放太寬造成的。

另外 Mark Nottingham 還建議 cache 應該在 origin server 上控制，而非在 CDN 上設定。也就是說，在 origin server 上送出 Cache-Control，讓 CDN 或是 reverse proxy server 使用這個值來判斷 cache。

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

Facebook 花了不少時間對付 reload 這件事情：「This browser tweak saved 60% of requests to Facebook」。

Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應：

In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.

而 Google Chrome 很明顯偏高：

於是他們找出原因後，發現 Google Chrome 只要 POST 後的頁面都會 revalidate：

A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.

然後在討論後認為這個行為不必要，就修掉了，可以看到降了非常多：

We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.

但還是很明顯比起其他瀏覽器偏高不少，在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter)，Google Chrome 會當作 reload：

The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.

不過這次推出修正後發現沒有大改變：(拿 production 測試 XDDD)

Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.

後來是針對 reload button 的行為修改，max-age 很長的就不 reload，比較短的就 reload。算是一種 workaround：

There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.

Google 也發了一篇說明這個新功能：「Reload, reloaded: faster and leaner page reloads」。

當 Facebook 的人找 Firefox 的人時，Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate，而不像 Google Chrome 的 workaround：

Firefox chose to implement this directive in the form of a cache-control: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。

所以之後規劃前後端的架構時又有東西要考慮進去...