Programming Language Notes

  圖片來源 簡介 Web Authentication（WebAuthn）是一種網路身份驗證協議，它為用戶提供了一種更安全和更方便的登錄方式，無需使用傳統的密碼。 WebAuthn使用公開密鑰加密技術，使用戶可以通過使用一個加密金鑰對其身份進行驗證，而無需輸入密碼。這個加密金鑰可以存儲在使用者的智能卡、USB金鑰、手機等安全硬件設備中，以保護用戶的數據安全。 WebAuthn的實現依賴於瀏覽器和服務器之間的相互認證，以確保用戶的安全。該協議已被多個瀏覽器和網站採用，成為了一種推廣的網絡身份驗證方式。 原理 Web Authentication（WebAuthn）的原理基於公開密鑰加密技術，以下是其基本流程： 1. 註冊：當用戶首次註冊一個帳戶時，服務器會生成一對公開密鑰和私有密鑰。其中，公開密鑰會被發送給瀏覽器，而私有密鑰則留存在服務器端。 2. 建立連接：當用戶想要登錄到該帳戶時，瀏覽器會與服務器建立安全的連接。 3. 選擇設備：用戶可以選擇一個合適的安全硬件設備（如智能卡、USB金鑰、手機等）來進行身份驗證。 4. 驗證：當選擇設備後，瀏覽器會向設備發送驗證請求，設備會使用內部的私有密鑰進行簽名，將簽名信息發送回瀏覽器。 5. 認證：瀏覽器將簽名信息與公開密鑰進行比對，如果匹配成功，則瀏覽器將該用戶識別為合法用戶，並讓其進入到帳戶頁面。 由於公開密鑰加密技術的應用，Web Authentication具有很高的安全性，能夠有效地防範偽冒、中間人攻擊等安全威脅，同時也能夠提供更便利的使用體驗。 用於何處 Web Authentication（WebAuthn）已經被廣泛應用於許多網絡應用場景中，其中包括： 1. 在線帳戶登錄：WebAuthn可以用於替換傳統的密碼，提供更安全的登錄方式。用戶可以使用智能卡、USB金鑰、手機等安全硬件設備來進行身份驗證，避免了密碼被盜用的風險。 2. 雙因素身份驗證：WebAuthn可以與其他身份驗證技術（如TOTP、SMS驗證碼等）結合，實現更強大的雙因素身份驗證。 3. 在線支付：WebAuthn可以用於在網絡支付時進行身份驗證，提高支付的安全性。 4. 網絡授權：WebAuthn可以用於對應用程序、服務器或API進行身份驗證，確保只有合法的用戶可以訪問相應的資源。 總之，Web Authentic...

  今天來聊聊我們常常使用的網頁，背後怎麼讓我們用的更順暢的一門傳輸方式，HTTP Keep-Alive，透過一點點的小改變，讓傳輸效率提升，減少非必要的浪費。 圖片來源 當我們溝通的過程中沒有KeepAlive的狀況下，會有多次往來的狀況，這樣對雙方來說開銷成本是非常大的，因此為了改善這個現象，加入了一個機制，就是當前期的握手協議建立之後，就可以不斷的發送請求跟回應，其實就跟通訊軟體一樣，當我們與對方建立關係之後，就能與對方不斷往來進行聊天，但是當今天我們帳號不斷的切換，那麼每次都要先打招呼，打完招呼之後等對方同意才有機會聊天。 與TCP的Keep Alive相同嗎？ 一樣都是Keep Alive，看上去非常相似，但實際上是完全不同的兩個面向，由於HTTP是基於TCP之上的，因此對於TCP本身來說也應該要有Keep Alive的機制，不然的話就算我們的HTTP那一層做的在完美，TCP沒有長連接的機制也是枉然，而本篇不會提到TCP的Keep Alive的機制，目的僅在說明這樣的機制大概是什麼樣的概念，幫助建立比較基礎的知識。 HTTP Keep-Alive具備哪些優點？ ● 減少用戶端與伺服端的負擔，不用頻繁請求，定期確保與對方沒有斷線即可。 ● 提升傳輸效率。 ● 確保與對方持續連線。 -------------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入？ 歡迎加入一起練習寫作，賺取知識，累積財富！

  越來越多的應用都在網頁上完成了，猶如過往的Excel、Word，現在都能直接用網頁來編輯使用，但我們想過嗎？ 所有的運算，除了伺服器以外，網頁是不是也會有一些複雜的計算呢？ 那對於這些複雜的計算，如果讓整個網頁卡住，勢必會影響到使用者的體驗，因此系統運算中的多工技術也被搬移到網頁端了，讓使用者一邊可以正常使用，背後將多餘的資源拿來進行較為複雜的計算。 但網頁端主要使用的語言是Javascript，原本的主要目的是簡單的互動，因此設計為單執行序，但隨著時代的演進，越來越多的功能都依賴這樣的程式進行運算，詳細我們將逐一說明。 為什麼javascript要設計為單執行緒? javascript主要功能是與user操作頁面互動及操作dom，試想若使用多執行緒的概念，那麼一個動作是新增至某個dom節點，另一個動作則是修改該dom節點，此時瀏覽器應該使用哪個動作為準? 所以為了避免複雜性才設計為單執行緒。 理解javascript非同步的概念 單執行緒就表示說所有任務都需要排隊處理，相對的效率較低落，IO或Network request通常需要等待較長的時間，如果前端頁面常常因為這些動作發生堵塞則user看到的畫面就是整個鎖死的，因此javascript使用了一些機制來避免這個問題，主要將任務分為兩種： ● 同步任務： 主執行緒上排隊執行的任務。 ● 異步任務： 不進入主執行緒，而是進入任務佇列等待執行。 上圖的執行機制 1. 主程序會先從stack中執行function 2. 執行過程中遇到setTimeout這類的非同步API呼叫，會透過事件委託的機制掛一個callback到setTimeout之類的Web API，執行完畢後會將該callback傳入上圖的callback queue等待。 3. 執行堆棧空閒時才從callback queue中取出任務執行。 4. 因此我們才會使用setTimeout的技巧讓一些需要長時間計算的任務排到任務佇列中等待，然而主執行緒就不會因為這個任務發生阻塞現象，可以先執行觸發loading動畫的事件後才處理這些耗時的任務，讓user感覺到畫面並非被鎖死。 上面的技巧雖然解決了畫面被鎖死的問題，但實際上執行的時間並沒有減少，因此發展出了Web Worker的機制，讓我們在web上也能有多執行緒的功能，最大化的利用系統資源，但是仍...

  超文本傳輸協定（HyperText Transfer Protocol，縮寫: HTTP），主要做為數據通訊的基礎協定，舉凡我們上網的網頁、圖片…，都是由HTTP協定為基底標準，讓服務端與用戶端可以相互通訊，達到互動、傳遞資訊的作用，而從最初版的單向傳輸也隨著時代的演進，應用漸趨複雜的趨勢下慢慢優化到雙向互動，而大數據的時代下，龐大的數據量也凸顯了傳輸效率的問題，因而也對這部分進行改善，讓傳輸更加順暢，就讓我們一起來看看HTTP的演進史吧！ HTTP 1.0的遠古時代 每一次都需要建立連線，並且只能有一次的請求。 HTTP 1.1 做了些改進 HTTP1.1版本之下，在一個請求中可以夾帶多個請求，並回傳，以此來減少多次連線的開銷，以此來改善HTTP1.0多次連線的問題。 到了HTTP/2的現代又有什麼大躍進？ 在HTTP1的時代雖然做了很多連線上的改進，但是隨著用來越多應用都搬移到網路上，雙向溝通的需求也越趨明顯，而1.x版的架構下並沒有支援Server端主動通知Client端的機制，在HTTP 2也都加入了這些特性。 在傳輸上也將原本整包資料的傳送方式切碎成小包小包， 並給予每一包一個編號， 送到目的地之後再重組， 如此一來就可以傳送多批資料也不會有等待一批資料過於久的現象。 幾個優點如下： Header壓縮，減少傳輸成本。 支援Server Push，由伺服器推送資料到瀏覽器。 連線重複使用，減少開銷。 下一個未來發展的重點「HTTP/3」 我們在簡介說明的部分有稍微提到，未來隨著數據量以及更多的需求轉移到互聯網時，為了避免堵塞造成使用體驗不佳，因而在傳書上持續的演化，而HTTP/2之前仍然是追求可靠性傳輸的TCP協定，在HTTP/3大膽的引進了UDP不可靠傳輸的概念，但也並非完全不可靠，而是基於UDP做了一些改良，這個協定稱為QUIC： 由上圖，很明顯的看到我們原本三次的傳輸來確認雙方可以進行通訊的過程，改良到只要一次就完成，更何況TCP + TLS更多次確認的過程，這邊其實QUIC的過程已經包含TLS了，只是未將詳細過程羅列，有興趣者請參考Wiki。 但我們的心中一定充滿著幾個疑問： 為什麼QUIC能保證可靠性呢？ ⇒ 因為加入了RAID5的演算機制，一次的傳送多個封包中，會加入一包檢驗的加總，並且...

  進入本篇章前建議您可以先了解以下兩個篇章，主要是介紹單向過程中的訂閱概念： 【Web微知識系列】訂閱技術的基石，RSS Feed是什麼？ 【Web微知識系列】系統之間的訂閱機制，Webhook是什麼？ 這種雙向溝通機制主要是為了更即時的反應，舉例來說今天我們有一個應用是即時語音辨識，那麼勢必會有一個互動的過程，使用者端進行錄音後，即時的送到伺服器進行辨識並將辨識結果即時呈現於畫面上時，就必須透過這種雙向溝通機制才能完成。 簡介 傳統的Http是一種Stateless的傳輸方式， 因此不會維持原本狀態， 而是需要更新、新增、查詢...等操作時才進行請求， 因此假設有即時性互動的應用時就不太適用了， 因為每進行一個動作就要向Server端發送請求， 而每次的請求都必須經過交握式連接的過程， 在效能上就不是那麼理想了， Websocket允許瀏覽器跟Server端只經過一次的交握過程， 就能建立一條長連接的溝通管道， 並透過這條管道進行「雙向傳輸」。 Websocket與TCP、HTTP的關係 Websocket與HTTP屬於應用層， 同樣都是基於TCP來進行傳輸， 而進行Handshake時也會透過HTTP進行， 但真正傳輸資料時就不必經過HTTP的方式。 與HTTP一樣可以進行加密傳輸， HTTP的部份為 https ， Websocket則為 wss 。 為什麼要使用Websocket？ 其實以往我們網頁資料刷新有以下幾種方式可以實作： Polling 這種方式是早期透過Javascript定時( setInterval 、 setTimeout )來向後端請求最新資料並呈現於頁面之上， 這麼做的好處是容易實現， 但我們並不知曉Server端何時會更新， 只能傻傻的定時獲取， 造成的影響就是頻寬的浪費以及資料呈現不即時。 Long-Polling 長時間輪詢的方式就是收到前端請求後， Server端會等待， 若這段時間有資料就會將最新資料回傳給前端， 因此等待的這段期間Client什麼事情也不用做， 等待資料回傳後再發送下一個請求， 雖然長時間的連接解決了Polling開銷的問題， 但如果在更新資料很頻繁的狀況下也會造成連續的Polling的動作產生， 未必效能較佳。 Server Sent Events...

  我們前一篇介紹了「 【Web系列】訂閱技術的基石，RSS Feed是什麼？ 」，相信也對於訂閱的機制具備一定的認識了，雖然RSS已經能夠滿足我們訂閱的一些基本需求，但由於主要的訂閱端還是定期去檢查更新資訊，因此假設我們想要在最短時間內掌握最新資訊時，仍會有一些延遲，再者也非常浪費頻寬。 我們為什麼不能改變做法？ 讓通知的決定權交給發佈商，當發佈商更新文章、影片時，主動通知所有訂閱者，相信這樣的模式會更加節省頻寬的浪費，這也就是為什麼我們今天要來談談Webhook的原因。 Webhook到底是什麼概念？ 說到底就是一種「事件驅動」的設計，而什麼是「事件驅動」呢？ 舉例來說就是： 「當(發生什麼事件)時(請主動通知我)」，那被通知的那一方要做什麼事情就跟主動通知方無關了，藉由這樣的設計減少核心系統的複雜程度。 圖片來源 主要的背後運作流程是這樣的： 註冊事件通知資訊。 事件發送時，根據註冊資訊進行通知。 帶來了什麼樣的改變？ 圖片來源 相信上圖聰明的我們應該已經知道帶來了什麼改變，中間減少了好幾次的溝通，對於我們現今複雜的系統架構下，減少了頻寬的浪費，讓我們整體運作上更有效率。 需要思考的幾個問題 通知的過程中發生問題怎麼辦？ 對於主動通知方來說，除了要加強重試機制之外，或許可以將未收到回應的事件先放在某個地方，而訂閱端也可以定期去檢查哪些事件是失敗的，然後應該去哪裡獲得最新資訊，或進行什麼樣的補救措施。 通訊過程安全嗎？ 其實就想像成一般系統的傳輸一樣，也被需加上加密傳輸通道SSL，讓過程更加安全。 需要授權或認證嗎？ 我想我們也不希望任人都能夠註冊進行訂閱吧！所以註冊事件時，最好也能夠加上一個通行證的核發機制，透過這樣的通行證，作為彼此之間的祕密口號。 結語 越趨複雜的系統架構之下，傳統的設計方式已經不敷我們使用了，而這種方式正好解決了頻繁詢問的效能問題，讓整體更有效率，其實套用到我們現實生活也是非常實用，感興趣的消費者向我們訂閱資訊，我們只要對於這些感興趣的消費者投遞廣告即可，取代廣發，或者是讓使用者定期來詢問。 📝 Web微知識系列文章 【Web微知識系列】 關於Web的同源政策(Same Origin Policy) 【Web微知識系列】 跨來源資源共用（Cross-Origin Resourc...

  什麼是RSS Feed？ 我們常常在聽的Podcast、看的Youtube都有提供訂閱的機制，那這個訂閱的背後到底是怎麼做的呢？ 讓我們一起來了解看看吧！ RSS的全名是Really Simple Syndication，中文又稱為「非常簡單的集合體」，而Feed就是餵食的意思，相信光聽名字還是一頭霧水對吧！ 這麼說好了，集合體指的是分享與傳送，那整個RSS Feed主要目的是將最新消息主動通知給訂閱者。 RSS的運作機制 圖片來源 訂閱端通常都會有RSS閱讀器，透過解析資料交換格式將內容呈現於閱讀器，而訂閱之後，訂閱端可以定期更新內容，載入時則載入最新內容，如此一來我們就能透過閱讀器觀看感興趣的最新內容。 為什麼Podcast需要RSS Feed？ 圖片來源 ⭐ 透過以上的機制，讓更新的部分自動化同步，將寶貴的時間花費在創作上。 我們可以透過RSS Feed來做什麼？ 模式帶來什麼改變？ 假設我們常常逛某個部落格網站，而對於該網站的內容也非常的感興趣，每天都會上來看看這個部落格做了什麼更新，但其實部落格的作者並不會每天更新文章，而我們想要第一時間瀏覽新聞章時怎麼辦呢？ 除了每天勤奮的上來看一下，好像也沒有其他的辦法了對吧！ 除非我們跟作者很熟，那就另當別論了。 這時候RSS Feed就可以發揮作用了，我們可以藉由RSS的標準格式，搭配設計好的閱讀器，定期去幫我們抓取最新資訊，一旦資訊有更新時就能在短時間內獲得最新資訊，而對於平台來說也不用一個一個去通知，而是讓有興趣的人自行訂閱，將決定權交還給用戶，而非強迫推銷。 推薦幾個不錯用的RSS平台 Feedly https://feedly.com/ 第三方平台登入： Facebook、Google。 標籤分類。 輸入網址自動抓取。 筆記本分類模式。 搜尋功能，直接搜尋就能找到想要訂閱的主題。 可惜的是需要收費。 RSSMailer https://briefcake.com/rssmailer 透過平台訂閱後，只要有最新資訊就會發送到我們的email。 每天發送一封郵件。 提供免費版服務。 付費版有提供消息的優先順序、自訂發送時間、無限的主題。 📝 Web微知識系列文章 【Web微知識系列】 關於Web的同源政策(Same Origin P...

  延續前一篇談論的主題「 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的排行規則時，想必就會影響曝光率吧！ 因此才會有網站設計彈跳視窗來讓用戶進入網站前，自行決定...