Home » Posts tagged "web"

幾個 Web API Manager 要設定的東西...

在上一篇提到的「控制瀏覽器裡的 Web API」,用了一兩天後有遇到一些問題,大概整理一下...

  • Gmail 會開不起來,需要將 mail.google.com 列入白名單 (一個阻擋條件都不能設),這是因為遇到瀏覽器的 bug,在「General breakage on specific site · Issue #55 · snyderp/web-api-manager」這邊作者有找到問題,他判斷是瀏覽器的問題後開了 ticket 給 FirefoxChrome,不知道什麼時候會好...
  • 同理,Facebook 右上角的通知也出不來,也是同樣的問題,需要把 www.facebook.com 列入白名單。
  • 另外是 Google Maps 用滑鼠滾輪滾動本來是平滑式的縮放,現在用起來會變成階段式的縮放,原因是 Google Maps 用到 WebGL Specification (在 Lite 裡面會阻擋)。這有兩個方向可以改,一個是把 www.google.com (或是 www.google.com.tw,看你用的網域) 另外開一組設定管理,另外一個是直接把 WebGL Specification 的阻擋關掉。

目前遇到的大概就是這些了...

控制瀏覽器裡的 Web API

在「阻止网站调用不必要的你的浏览器 API」這篇裡面看到的,論文的作者發展了 ChromeFirefox 的延伸套件,可以控制瀏覽器內的 Web API。套件原始程式碼在 GitHubsnyderp/web-api-manager,頁面上有 Chrome 與 Firefox 延伸套件的連結可以直接安裝。

套件本身預設不會擋任何 Web API,但提供了三種不同的 Preset 讓你選 (Lite、Conservative 與 Aggressive),一般情況下用 Lite (擋掉 17 種 Web API) 就有不錯的效果了。另外也可以針對某些網域做另外的調整... (雖然還沒用過 XD)

直接抓 Google Chrome 上給的截圖:

這是個好東西啊,有些 API 出來擺明就是來追蹤使用者的... 關掉省麻煩 XD

純 CSS 的追蹤技巧

Hacker News 上看到的 PoC,程式碼就放在 GitHubjbtronics/CrookedStyleSheets 上。能追蹤的細節當然比較少,不過透過 CSS 還是有不少資訊可以蒐集。

像是連結被觸發時:

#link2:active::after {
    content: url("track.php?action=link2_clicked");
}

瀏覽器的資訊:

@supports (-webkit-appearance:none) {
    #chrome_detect::after {
        content: url("track.php?action=browser_chrome");
    }
}

字型的 fingerprint:

/** Font detection **/@font-face {
    font-family: Font1;
    src: url("track.php?action=font1");
}

#font_detection1 {
    font-family: Calibri, Font1;
}

捲頁行為:

@keyframes pulsate {
    0% {background-image: url("track.php?duration=00")}
    20% {background-image: url("track.php?duration=20")}
    40% {background-image: url("track.php?duration=40")}
    60% {background-image: url("track.php?duration=60")}
    80% {background-image: url("track.php?duration=80")}
    100% {background-image: url("track.php?duration=100")}
}

算是提供了不少除了 <noscript></noscript> 外的手段,不過一般網站要引入這些技巧需要改不少東西就是了... (或是需要透過 server side plugin 的修改進行追蹤)

Googlebot 的 Web rendering service 的細節

在「Polymer 2 and Googlebot」這邊文章裡面才看到 Google 官方在今年八月就有公開 Googlebot 所使用的 Web rendering service (WRS) 的細節:「Rendering on Google Search」。可以想像到是基於 Google Chrome 的修改:

Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.

裡面提到一些值得注意的事情,像是不支援 WebSocket,所以對於考慮 Google 搜尋結果的頁面來說,就要注意錯誤處理了...

用 PublicWWW 分析網站

在「Keylogger Found on Nearly 5,500 Infected WordPress Sites」這邊看到的網站服務 PublicWWW

雖然原文是說 WordPress 被感染的情況,但注意到的反而是他提到的網站 PublicWWW。

在 PublicWWW 上面目前收錄了兩億個網站的資料,有些東西頗不賴的,像是可以搜尋有哪些是使用同樣的 Google Analytics 帳號:

Sites with the same analytics id: "UA-19778070-"

這拿來找誰是內容容場後面的人超棒的啊,而且可以拿來補內容農場的清單,像是「UA-31425034 - 19 Websites - PublicWWW.com」這個 XD

免費版只能搜 Top 3M 的部份,付費版 (USD$49/month) 則是可以搜所有的資料。

LINE 將內部的座位表由 Excel 改成 Web 界面...

LINE 將內部的座位表由 Excel 管理,改用 Web 界面了:「Excel管理の座席表をLeafletでWeb化した話」,這邊不確定是全球的 LINE,還是只有日本的 LINE...

如果跟日本人有過業務合作的話,就會知道他們對 Excel 的用法只能用

出神入化

來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情,覺得還蠻有趣的...

起因是今年四月換辦公室,所以就順便換系統,把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library):

人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。

這是 Excel 版本的樣子:

這是新版本的樣子,UI 上有更多互動的界面可以操作:

然後文末提到了總務業務量減少,而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死,所以就可以更自由換來換去 XDDD):

今回開発した座席表は総務の業務軽減に始まったプロジェクトでした。そして実際に導入後には、座席表の管理にかけていた総務の業務を大幅に削減することに成功しました。また、利用者からもかなり好評で、「これを待っていたんですよ!」といった声もあり、社内コミュニケーションの円滑化に一役買うことができているようです。誰の席でも自由に変更できるという点についても、これまでのところトラブルの報告を受けることなく運用できています。

翻了一下英文版的 blog,好像沒有提到這件事情?XDDD

WordPress 在 Internet 上的情況

WordPress 在 Internet 有很大的佔有率,在「Usage statistics and market share of WordPress for websites」這邊有一直更新的資料,現在是:

WordPress is used by 59.9% of all the websites whose content management system we know. This is 29.1% of all websites.

這數字可以參考看看。而在「State of the WordPress ecosystem」這邊就看到有人在分析 WordPress 在整個 Internet 上的情況。可以看到裡面有蠻多都是透過 BigQuery 分析出來的...

在分析整個頁面的平均下載量時,可以看到 WordPress 的頁面比較肥:

We get 1590 KB for wordpress=false and 1897 KB for wordpress=true.

但是在 WordPress 上未最佳化的圖片比較少,原文裡猜測是歸功於 plugin 的關係:

@amedina I wonder if this has to do with the availability of tools/plugins in the WordPress ecosystem that optimize images effortlessly, as opposed to other web development pipelines that require manual image optimization or installation of specialized tools.

所以就跑去分析了 WordPress 上使用了哪些 plugin,不過這是看 web request 以及 path 得到的,如果 plugin 是純粹在內部執行的話就看不到了:

整個分析還蠻有趣的,而且還在進行...

Archives