Programming Language Notes

  延續前一篇談論的主題「 Cookieless系列: Floc能解決隱私議題嗎？ 」，我們已經瞭解到 FLoC 這項技術解決的隱私的什麼問題，也明白事實上還是存在著風險的，因此Google準備捨棄 FLoC 迎接新的技術 Google Topic ，我們也會針對這項技術進行簡單的介紹，共同來學習頂尖的科技公司如何針對遭遇的問題設計出解決方案。 雖然 FLoC 的概念很棒，透過群體的方式將個人給模糊化了，但歸屬的群組人數過少時，也很容易經過演算法進行交叉比對識別出個人，而Topic也不是一個非常新穎且截然不同的技術，而是基於 FLoC 這項技術為基底進行改善，讓特徵更模糊，有效期更短，使廣告商不易交叉比對。 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能閱讀打造被動收入 🔔 ✨ 增強了哪些特點呢？ 一、 僅描繪主題輪廓，讓識別度更加模糊 讓主題更加廣泛，例如： 書籍、運動這樣的話題類別，而當使用者瀏覽網站時，會依照使用者瀏覽的歷史，以演算法在自己裝置上推測出用戶感興趣的主題(Topic)，這個計算過程只會在我們的裝置，因此伺服器不會知道計算的過程，另外也不會將性別、種族這種太狹隘的主題納入考量，避免交叉比對，讓廣告商有機會推測出個人，這些主題也會隨機選出幾個透過Topic API傳遞給平台，平台再根據這些主題推送相關的廣告， 二、 時效性的限制 通常保留三周內的興趣主題，並且每一個禮拜重新在本地端計算排行前5名的主題，讓我們的興趣主題具有時效性，提升安全性。 三、 將決定權交給用戶 用戶可自行查看被瀏覽器儲存的分類，並手動進行刪除，甚至關閉Topics功能。 來看看怎麼運作的 大致上的概念就是透過裝置端進行簡單的運算，計算出幾周內最感興趣的三個主題，並透過標準格式送給中介平台，中介平台再根據興趣主題推送適合的廣告，過程中，中介平台只會知道興趣主題，無從識別個人，而廣告商則透過中介平台投遞廣告，因此廣告商與使用者中間多了一層Topics API平台進行控管，故廣告商無法直接取得使用者傳遞的主題，也較難以透過交叉比對來追朔到個人。 結語 目前許多技術細節仍在討論階段，也開放了許多開放性議題讓大家一起討論，有興趣的朋友也可以到 這邊 看看喔。 看完整體技術架構之後，覺得這種作法非常聰明，巧妙的將廣告商與用戶隔開，中介

  FLoC 我們前一篇有介紹過「Cookieless時代趨勢來臨，與我們息息相關的隱私與行銷方式如何應對呢？」建議先行閱讀，裡面包含Cookie的基本觀念，以及為什麼要捨棄的原因，接下來才進入到本篇的主軸，將會針對 FLoC 的基本原理、是否能解決個人隱私議題為主軸進行探討。 FLoC 的全名是 Federated Learning of Cohorts，意思是透過 AI 的 federated learning（聯合學習），由Google推出的自家演算法，目的在於模糊掉個人數據與行為資料，以群體為概念，將類似瀏覽行為的用戶進行分群，產生一組群組識別碼，系統會根據每個群組所感興趣的主題進行標籤分類(美食、旅遊...)，那這樣要如何進行廣告呢？ 演算法會根據美個群組所感興趣的主題進行投放廣告，例如： 小明常常瀏覽旅遊網站，而其他瀏覽相同類型網站的使用者會被歸納到這個群組，而這個群組就被貼上🏷️旅遊的標籤， 因此平台就能將旅行社相關業者的廣告向這個群體進行推播，這就是 FLoC 主要的運作模式。 主要讓活動記錄保留在用戶端，而不會發送到伺服器，之後可以建立起匿名的「群組」從而進行廣告投放。 聽起來是不是很棒，我們將自己隱身於群組之中，但試想假設我們的興趣本身就比較冷門，被歸類在一起的其他人可能是少數人，反而讓廣告可追蹤的範圍更侷限，廣告商透過一些演算法機制或許就能推敲出個人的興趣喜好，這樣就打破了原本Floc要解決的問題，因此才會出現反彈的聲浪，而Google也宣布預計放棄此套演算法。 下一個可能解決Floc缺陷的技術？ 答案就是 Google Topics ，原理大致上與 FLoC 相似，最主要的差異就是加入了時間因子(保留3周...)，並且將群組更加模糊化，避免被交叉比對，追朔描繪出個人隱私，相關的技術細節將留待下一章節進行探討。 結語 科技的演進過程中難免遇到一些缺陷之處，也應該反思，當我們在使用這些免費又優質的服務時，背後是否付出了什麼？ 注意力、個資...等，都可能是我們無形中付出的資產，也越來越多人開始注重隱私，但是對於廣告商平台來說，如果無法知道銷售目標群的興趣，根本無法精準行銷，因此才會衍生這麼多技術迭代的過程，也看到了幾個中途失敗的技術，包括本文的 FLoC 也是Google準備放棄的一套具有爭議的演算法，對於我們來說，瞭解這些

  Cookie簡介與個人隱私議題 在談Cookieless之前我們先來了解什麼是Cookie，這裡的Cookie並不是餅乾的意思，而是為了讓人們在網路上通訊時，能夠創造更無縫的體驗，想像一下，假設我們在使用網站時，每切換一頁就要進行登入一次，我想大部分的人都已經抓狂並放棄使用的吧！ 而Cookie的出現就是為了讓這種體驗更加順暢，那到底如何能讓使用體驗更加順暢呢？ 我們以訂房網站為例，Cookie能夠很貼心的幫我們記住有興趣的房型，並且幫助我們下次進入網站時進行呈現，透過這樣的體驗，不斷提醒我們喜歡的房型要趕緊下訂，提升成交率。 圖片來源 但也隨之帶來一個問題，那麼就是這個Cookie雖然很貼心，但也帶走我們非常多的個人隱私資訊，萬一Cookie被有心人士利用時怎麼辦？而且並非每一個人都願意被記住個人資訊，因此這樣的機制真的合適嗎？ 是否應該遵循使用者的意願來加入此功能呢？ 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 為什麼有些網站要徵求用戶同意是否分享Cookie？ 我們常常進入某些國外網站時，都會跳出訊問「☐ 是否同意透過Cookie來改善使用體驗」，對！這樣做是有尊重使用者的意願，讓使用者自行決定是否提供Cookie，但假設進到每個網站都這樣詢問，我想原本Cookie的美意應該都被破壞殆盡了吧，況且使用者想要清除這些資訊時，還要透過多餘的步驟進行清除，對於整個系統的體驗來說就大打折扣了，除此之外，還有一些網站是強迫我們必須選擇隱私開放或者部分開放才能關閉彈跳視窗，這體驗感非常的差！ 那麼為什麼會這些網站要來徵求用戶的同意呢？ 這就得從GDPR(General Data Protection Regulation)來談起了，於2018年5月25日強制執行，簡單來說就是一套對於歐盟公民個人資料蒐集的範疇規定，因此網站若想蒐集使用者資料來做更多的應用時，就必須符合此規範，那我們可能會說，我們的客戶主要目標又不在歐盟，有需要遵守嗎？答案是還是必須遵守，因為我們的網站只要有一位歐盟成員造訪，註冊、下訂...，假設沒有徵求客戶同意就擅自使用，就等於違反了GDPR法規，加上如果這項法規被各要求到各大搜尋引擎納入SEO的排行規則時，想必就會影響曝光率吧！ 因此才會有網站設計彈跳視窗來讓用戶進入網站前，自行決定是否提供

  我們前面已經介紹過「 關於Web的同源政策(Same Origin Policy) 」，大致上對於Web的安全政策有一些基本的認識了，那麼在嚴格把關之下，仍需適度的開放約定的來源，此為「 Web世界的邦交國政策 — 跨來源資源共用（Cross-Origin Resource Sharing, CORS ） 」，但是開放的同時，難免遇到一些攻擊，諸如「 你的資料如何被偷走？ Web安全篇 - 跨站請求偽造(CSRF ) 」、「 Web世界中潛藏的危機 - 跨網站指令碼(XSS) 」這類的攻擊手法，我們也具備一定的知識，接下來就進入到如何制定一些安全內容政策，來防止這類型的攻擊，也就是今天的主題Content Security Policy(CSP)。 文章最後將會提供一套CSP安全檢查工具，保護自身，避免踏入不安全地帶！ 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 📝 更多文章請到這裡盡情閱覽... 其實簡單來說就是白名單的概念，過濾入境人員，避免造成危害，在Web世界中亦是如此，防止載入不安全的內容，就算網站中具有注入腳本的地方也沒有關係，只要不載入或訪問外部資源就相對安全了。 為什麼制定安全政策這麼重要呢？ 國家與國家之間雖然可以透過護照來入境，但總不可能所有人都無限制的進入吧！來來往往的人難免存在一些犯罪份子、通緝犯...等，如果未進行管制，那對國家的人民來說勢必會造成人身安全問題，因此對於入境人員就會有安檢機制，不能攜帶槍械、彈炮...等有害物品進入，被管制中的通緝犯也不能任意入境，這些都是基於安全政策，那麼網路世界呢？ 其實Web中就是透過Content Security Policy(CSP)的方式來制定這樣的規則。 可以制定哪些規則呢？ 這邊僅著重於概念的描述，因此列出幾個常見的來源白名單配置選項，至於完整選項請參考 這裡 。 connect-src： 指定來訪的連接源， websocket、XHR...等。 script-src：指定外部腳本的來源，通常我們會動態載入外部的腳本，那假設我們僅信任某些網站，就可以將這類網站資源加入白名單。 image-src: 圖片的來源。 media-src： <video>、<audio>...等影音來源。 fram

  互聯網的時代中我們幾乎都離不開網路，那如果能夠對於Web具備基礎的知識，就能夠讓我們在使用網路的過程中提升風險意識，以減少被竊取、盜用的風險，進而保護個人資產，因此多一份知識在身上也就等於多了一份防身的武器，一天學一點，透過 微習慣 讓我們享受複利的效應。 在前幾篇我們介紹了「 同源政策(Same Origin Policy) 」與「 Web - 跨來源資源共用（CORS） 」的基本概念之後，大致上已經了解瀏覽器如何做個守門員，攔截非法的請求/回應，接下來我們就來談談駭客如何繞過「 同源政策(Same Origin Policy) 」進行跨站腳本攻擊的XSS(Cross-Site Scripting)。 由於Web越來越豐富，許多動畫、特效都能在Web上完成，這些都歸功於Javascript，但也由於可程式化的便利性，導致駭客可以利用這樣的特性，注入有害的腳本，造成資安風險。 為什麼Cross-Site Scripting要簡稱為XSS呢？ 因為避免與CSS混淆，因此簡稱為XSS。 試想，當國家與國家之間透過有限度地開放跨來源資源共用 (CORS )時，難免存在一些有心人士，繞過政策進行地下活動，就如同現實世界的偷渡、詐騙皆被搬到Web世界運行，而以下將介紹這樣的攻擊類型有哪些？ 對我們來說有什麼危害？ 我們身為使用者又應該注意什麼呢？ https://button.like.co/willhanchen 🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔 攻擊的類型有哪些？ 儲存型(Stored XSS) 這種類型的攻擊方式就是將惡意的指令碼，注入到網站伺服器進行儲存，而當使用者進到駭客注入的功能區塊時，當滿足特定條件(按下按鈕、觀看圖片...)之後觸發惡意腳本，最常見的例子就是留言版了，這是最普遍能夠輸入文字(指令碼)的入口，並且也會被儲存於資料庫中。 駭客將惡意代碼寫到網站伺服器儲存的DB。 使用者打開網站時，載入惡意程式碼。 惡意程式碼竊取個人資訊或者冒充用戶身分進行深層攻擊。 反射型( Reflected XSS ) 駭客發送夾帶惡意連結的信件，誘導受害者點擊。 受害者點擊後，導至駭客架設的網站。 透過連結的參數觸發惡意腳本，進而攻擊、竊取用戶資訊。 有些也會直接夾帶腳本參