依據刪除 IE 與 Firefox 的 CNNIC 根憑證這篇和在 Linux 上移除 CNNIC 憑證這篇
，提供 Mac OS X 底下刪除 Keychain 裡面的 CNNIC 根憑證。如圖。

Google Chrome 也因為是用系統 Keychain 裡面的憑證，所以 Chrome 就不用額外刪了。
至於 Firefox 3.6 就內建 CNNIC 根憑證，可以直接刪除。或是透過「編輯」把此憑證可以用來識別網站的選項取消。

此外，為何此事如此嚴重？其實不只瀏覽器，作業系統也是，MS 也內建把 CNNIC Root CA 加入新版的 OS Root CA。試想，如果今天瀏覽一個網站，使用者沒有逐一仔細檢視核發憑證的機構，就隨便確定進入網站輸入自己密碼，其實該網站可能是假的惡意網站，而 CA 正是由不是大家認可的 CNNIC Root CA 機構簽發。雖然你看到 mail.google.com 和憑證無誤，但是該網域並非真正 google 的 server farm。或是下載軟體，雖然看到 Microsoft 或是 Google 的憑證，但是事實上該憑證並非真正由原始簽發單位簽署，一般使用者也不會逐一檢視簽署者是誰。如此一來可能又不小心安裝了什麼後門或流氓軟體。

事實上當然偉大的中國政府不會這麼笨，例如 Google mail 有不少異議份子的帳號，就在內地透過 GFW 轉到假的 Google mail server 和自己簽發的 CA 去，透過 Man in the Middle 偷偷過濾和檢視私密資料。如此一來大家都會發現那堆 server 都是假的。但是透過偉大的 GFW，比如說特工可以懷疑某某 IP 來源是異議份子，僅對那子網域或 IP 進行轉向攻擊。某異議份子存取了自己 Google Mail，但其實透過 DNS 和 IP 轉向，轉到中國某內地 server 偽裝成 Google Mail，又有來自 CNNIC Root CA 簽發的簽證，無論在 Chrome、Firefox、IE 看來都像是 Google Mail，事實上他並沒有仔細檢視簽發者是 CNNIC 而不是 Thawte SGC (Google mail 真正核發簽署憑證的單位) 的 CA 簽署。照樣，即使 Google mail 已經因為前陣子中國駭客事件而全部預設 HTTP SSL 加密連線，依然可以照樣被滲透。

（當然以上都是假想和幻想，如有雷同，那就是對岸抄了我的劇本）

我在 Mac 用 Firefox，不要叫我開 ies4mac 或是 Parallels。買個東西還要換瀏覽器真是麻煩。某X國信託越做越回去了，以前的 Verified By Visa 對於 Firefox 用起來還蠻正常的。那個驗證的網頁 JavaScript，找個國中高中生會 HTML/JS 來作都比他強。因為裡面的 JS 用法錯誤一堆，也難怪 Firefox 根本不能用。就算打了驗證碼，按了送出，卻沒有回應，只有取消還能在 Firefox 用。因為 JavaScript 根本就亂寫。最後，找出了一招，只要把

javascript:void(document.getElementsByName('_service')[0].value='0303_OTPV');

這個連結，拖到 bookmark bar，然後在輸入驗證碼之前或之後(總之在送出之前)，按一下這個書籤，就會把網頁內的 form 的隱藏 input 名稱為 _service 填為 "0303_OTPV"。然後直接在文字輸入框按下 Enter，就可以正確繼續驗證了。
要注意的是，這個 JS 只適用簡訊驗證的方式，上面的 0303_OTPV 就是這個服務。因為早已經改成這種驗證方式，所以不知道一般密碼方式識別字串為何。如果還是用密碼方式驗證的話，用這方式會錯喔，基本核對方式就錯了。如果有人知道一般驗證方法的 service 識別字串，再跟我 update 一下。
如何看呢，絕對不是駭客手法，妓者不要說是用網路破解。只要用 Firefox 在該網頁打開 DOM Inspector (沒有這個 Add-on 的要去裝才有)，然後搜尋 Tag name 為 form，名稱為 form1，他的 attributes 裡面就有這種格式的字串囉。

CrossOver 把 Google Chrome 瀏覽器的開發版本 Chromeium，以及 wine 1.1.4 直接包裝成完整的執行檔 CrossOver Chromium。以下是執行畫面，背後的程式是 Firefox 3.1 beta。 下載後，拖拉到桌面或應用程式裡面，就可以馬上執行由 wine 模擬起 windows 環境執行 Chrome 瀏覽器的功能。不過這當然是非常非常嘗鮮的玩法，因為在 wine 裡面執行的 Chrome 會加上參數 --no-sandbox --in-process-plugins，最主要的 multile processes 優點就沒有啦。如此一來，醜醜的 windows 視窗外框，不是很漂亮的 X11 Font Rendering，只能跑 single process 的 multithread，優點大概只剩 V8 Engine 的速度。不過 Firefox 3.1 beta 是 TraceMonkey (記得把 about:config 的 javascript.options.jit.content 和 javascript.options.jit.chrome 打開才有效) 也差不到哪去; Safari 4.0 preview 是 WebKit 搭配 SquirrelFish，既然都是用 WebKit，就直接跑 Safari 就差不多了。

最近消失的十億很熱門，但跟主題無關係，雖然電腦上用掉十億很簡單(1GB=1,073,741,824 bytes）。在 Firefox 的網址列打 about:cache，可以看到 memory 和 disk 的 cache 容量和消耗。 一定會有人好奇，怎麼 memory cache 的 Maximum storage size 是 5000 KiB（這是我設的，因個人設定或電腦記憶體容量而定），結果 Storage in use 反而比 Maximum 還大。如果是 disk 部份就正常，不會超過 Maximum storage size。這個原因是，記憶體的 cache 有部份會存放的是「解壓縮」後的圖片，例如 jpeg、png 這類解開通常容量都不小。所以實際上 memory cache 的檔案可能沒有超過 5000 KiB，但是 cached 未壓縮圖片檔容量卻已經超過這個容量。點選如圖片上面的 List Cache Entries 就會列出每個詳細資料，我的範例如下，一定會有人好奇例如 http://css.funp.com/base/css/v3/nt.png 這個不是照片的圖檔有 3,840,000 bytes，約 3.66MB。第二個 http://css.funp.com/base/css/_4939/B0.png 也不遑多讓，有近 3MB 的空間。實際上，第一個 nt.png 檔案只有 44.33 KB (45392 bytes) 這麼大，但是解析度是 400px × 2400px，也就是 400×2400×4 (32bits color) = 3,840,000 bytes，沒錯，就是上面的大小。只要有 10 個類似的東西，加上 firefox 本身程式內部用量，消耗的記憶體馬上破百不是問題。
當然這是拜 CSS 之賜，可以用 clip 的方式來選擇顯示範圍的圖片，這樣好處當然是瀏覽器只要 cache 一個小圖檔（壓縮後不大），也減少 http server request 和檢查 expire 次數。所以網頁中看到很多用到小圖的地方，可能是圖檔中不同的部位去選擇要呈現的範圍。但是，事實上，圖片上蠻多空白（不會用到）的地方，當然這些空白的地方，電腦還是要花記憶體的空間去儲存地。
後記：為啥拿 funp.com 上面的 background png 來舉例？因為，剛好大小榮登上面排行榜前幾位，純屬巧合 :P。

利用 WebKit 所提供的 SunSpider benchmark 來測試 Mac OS X 上各家的瀏覽器裡面 JavaScript 的效能。 測試平台是 Mac OS X 10.5.2 Leopard on Apple iBook 1.2Ghz。瀏覽器包含正式版的 Firefox 2.0.11、Safari 3，測試版的 Firefox 3.0b5pre、WebKit Nightly Build、Opera 9.5beta。測試結果看來都是測試版的瀏覽器大獲全勝，其中又以 Firefox 3.0b5pre 最為突出，一改 Firefox 讓人詬病的速度問題。再來是 WebKit，效能上只輸 Firefox 3b5pre 一點，很難想像用他來作為核心的 Safari 竟然會有這麼大的差距。接著是 Opera 9.5beta，雖然他們號稱速度上是第一，可能整體上來說沒錯，但是畢竟在單純 JavaScript 上沒有這麼好的成績。敬陪末座的就是舊版 Gecko 核心的 Camino 1.5 和 Firefox 2.0.11。
在 Firefox 3b5pre 釋出後不到一天，一些 Addons 已經更新支援最新的 Firefox 3 beta nightly build，例如 Adblock Plus。

Firefox 3 的第五個測試版本出來了，舊的測試版用戶可以透過 Update 直接升級。但是升級的缺點就是一些 addons 都不能用，其實應該是相容，但是受限版本檢查限制，全部不能用。尤其我最重要的 adblock plus 一失效的話，yahoo、udn 等等廣告全部跑出來了，花花綠綠的真是不習慣。
順便做了 WebKit 上得 Sunspider 效能測試，來試驗現在各家版本的 JavaScript 效能。

1. Firefox 3 b5pre: 13495.8ms
2. Firefox 2: 53977.4ms
3. Safari 3: 42380.8ms

結果很明顯，Firefox 3 的速度完全勝出。測試平台為 PowerPC G4 1.2Ghz。

Firefox 2 在 mac os x 執行，除了網頁資料下載速度快點，顯示還有效能都不如 Safari。連字體都是只有醜醜的 Gray Level AntiAlias。Firefox 3 測試版出來時，就迫不及待的去嘗試。因為主要是把 Carbon 換成 Cocoa，把畫面和字型繪製改由 Cairo。結果一試就大失所望，因為效能真是慢到一個不行。以常用的 Google Spreadsheets 來說，在儲存格上上打注音輸入中文真是慢到一個不行。所以還是想等到他推出正式版本再說吧，畢竟現在還是 beta。在 Slashdot文章和這篇 Undocumented API 才是王道提到一些主要原因。接著再下載最新的 Firefox 3 nightly build 來試試看，果然感覺速度或效能已經比 Firefox 2 快了，搭配 Arial Unicode MS 字體，Cairo 畫出來的 CJK 字型很美觀，已經有點迫不及待想要丟掉 Firefox 2.0。
至於 Apple 在 WebKit 裡面擺的 binary lib 果然是大有來頭，因為從 WebKit repository checkout 的程式碼，擺著沒有 source code 的 lib 就已經很讓人猜疑。

在 WebKit based 的瀏覽器上，瀏覽器顯示的字型是以 International Pane 所選擇的地區順序設定來挑選 fallback 字型。（當該字型沒有該字的 Glyph，則繼續選用候選字型）所以常常可以在某些網頁上看到本來是細明體的字型，穿插著黑體字。或者是在黑體字中間，穿插著粗細或高低不一的字。尤其是在 firefox 瀏覽器上常常看得到。 這個原因是 firefox 本身有 unicode 地區的編碼分類，以及各種語系之間使用不同的字型因素。像是台灣中文是 Apple LiGothic Medium，日文是 Hiragino Kaku Gothic，韓文是 Apple Gothic。而當某些 unicode 網頁中出現某些字型，可能會依照該字碼挑選地區來選擇字型。或者看起來像是繁體的中文字，卻挑選了日文的字型來繪製。而這些字型的挑選，雖然在程式已經提供了讓使用者可以挑選各地區的字型，但是真正繪出文字的字型可能不是使用者希望的。所以最好的方法就是，在這些 CJK 語系地區使用統一的字型，而且該字型又有幾近完整的 unicode glyph 資料，才不會到時候缺字又要使用其他字型補字。 在 Mac OS X 上，有一個字型叫做 Arial Unicode MS。雖然名字有 MS 但不是微軟做的，是一家 Monotype 字型公司。英文字型看起來是 Arial，亞洲字體看起來像是黑體（雖然經過 Apple AntiAlias後看起來沒有黑體那麼黑和清晰）。用起來在 firefox 上效果不錯，對於本身我自己習慣看 Sans-Serif 字體來說，是相當好的選擇，就連 Safari 預設字型都設成這個字型。

Hash table 是 computer science 常用的一種 data structure。在已知 key 的情況下，可以很快的找到相對應的 value。通常這個 key value 可能是數值，pointer，或是字串；通常字串會經過 hash function 算出一個數字來當作的 key。那如果 key 是 regular expression，當程式在做 lookup 動作時，是拿一串文字去 hash table 找，是否有一個 regular expression 的 key 符合這串文字，並且找出相對應的 value。例如

hash[ "^abc.*$" ] = 1;
print hash[ "abcdef" ]; // output 1

問題可能在於 regular expression 怎麼做 hash function，並且由文字去 lookup 得到相對應的 regular expression 為 key 的 value？ 這個問題蠻難的，不過看到的這個應用，倒是並不會完全都是 regex 特殊字元（像是 ^[a-zA-Z]+$）。應用的例子，可能大家都有在用，就是 Firefox add-ons 的 AdBlock Plus。filter 內有上百個廣告 URL 的 patterns（雖然它只提供 wildcard 字元，但是內部是轉成 regex 來 matching），如果使用者 subscribe 多個 filter list，甚至可以多到上千個吧。當 Firefox 瀏覽一個網頁時，少說幾十個網址需要去跟這幾百個 patterns 做比對。當然最簡單的方式就是，每遇到一個網址，就拿去從頭到尾地把 patterns 拿來作 regular expression 的 matching。當然比到了就是可能 white-list or black-list 裡面的一項，看要阻擋還是放行；沒有比到當然就是放行。Regular expression 實際上在比對時，當然所花費的成本比一般 string compare 高很多。 AdBlock Plus 怎麼做呢？其實說穿了就蠻簡單的，事實上它並不是真的完全拿 regular expression 來做出特殊的 hash function。而是用 regular expression 中內含一般文字，像是 "http://ad*.udn.com/*" 這種（會先轉成 /http:\/\/ad.*\.udn\.com\/.*/ 的 regex 格式供 javascript 比對用），裡面穿插了一些普通的字串。而 AdBlock Plus 它會從中去找出這些特徵（它是從 pattern 後半段去找，因為通常大部分 patterns 前面開頭不是 http:// 就是 *.udn.com/* 這種，從頭找對 URL 似乎沒有好處），並且長度是 8 的特徵字串，像是 ".udn.com"，並且不包含 regular expression 特殊字元（當然可能找出來不只一種，像是 "udn.com/" 也是 8 個字）。然後就拿這段文字當作 key 去存 hash table。之後瀏覽 udn.com 內容，每次做 URL 比對時候，例如 "http://ad1.udn.com/RealMedia/ads/something.gif"，它就從字串的頭開始，取每一段長度 8 的字串出來給 hash table 去找，所以它依序是給 hash table 找了 "http://a", "ttp://ad", "tp://ad1", ... 到了 ".udn.com" 終於在 hash table 中有找到東西，然後當然就把相對應的 regex 拿來比對是不是符合這個 filter pattern。 其實說穿了，前面的問題並沒有解決，如果是這個例子，用上面的做法就非常不適用：

hash[ "[0-9]+" ] = 1;
hash[ "[a-z]+" ] = 2;
hash[ "[A-Z]+" ] = 3;
print hash[ "abc" ];

事實上後面的做法，並不是真的拿 regular expression 去算出 hash 來作 pairing，而只是剛好在 URL filter patterns 上有這種特徵，就是內含部份網址或路徑，也是因為有這些特徵才比較好辨別哪些是正常內容，哪些是廣告才會有的 URL。利用這種特性，剛好去找出裡面的一些 signature 來建立 hash table，用來作為之後比對時加速尋找真正要比對的 patterns，並不是盲目地完全都去一一比較。 Ref 1: Perl Tie::Hash::Regex Match hash keys using Regular Expressions Ref 2: How does Adblock Plus process its filters and which filters are faster?

Here is the page of my personal build Mozilla Firefox 2.0. In this version, it adopts a method to bypass the Websense content filter. Just read the details in the page. We have Windows 32bit version binary and Mac OS X PowerPC G4 (7450) version binary of Firefox. For somebody will still encounter browsing difficulities behind Websense network, just adjust some perferences in Firefox (about:config).

1. set network.http.keep-alive to false
2. set network.http.max-persistent-connections-per-server to 0

Please refer to this page for details.