關於 循跡機器人應用 ，我們在網路上蒐集到這些相關的討論、資訊與評價

AI 助陣醫學、防疫，個人隱私難兩全？

2021/06/09 研之有物

規範不完備是臺灣個資保護的一大隱憂，《個資法》問世遠早於 AI 時代、去識別化定義不清、缺乏獨立專責監管機構，都是當前課題。

評論

本篇來自合作媒體研之有物，作者周玉文、黃曉君，INSIDE 經授權轉載。

AI 醫療、科技防疫的人權爭議

健康大數據、人工智慧（AI）已經成為醫療研發的新聖杯，新冠肺炎（COVID-19）更將 AI 技術推上防疫舞臺，各國紛紛串聯大數據監控足跡或採用電子圍籬。但當科技防疫介入公衛醫療，我們是否在不知不覺中讓渡了個人隱私？

中研院歐美研究所副研究員何之行認為，規範不完備是臺灣個資保護的一大隱憂，《個資法》問世遠早於 AI 時代、去識別化定義不清、缺乏獨立專責監管機構，都是當前課題。

「天網」恢恢，公衛醫療的新利器
自 2020 年新冠疫情大爆發，全世界為了因應危機展開大規模協作，從即時統計看板、預測病毒蛋白質結構、電子監控等，大數據與 AI 技術不約而同派上用場。但當數位科技介入公共衛生與醫療健康體系，也引發人權隱私的兩難爭議。

2020 年的最後一夜，臺灣再次出現本土案例。中央流行疫情指揮中心警告，居家隔離、居家檢疫、自主健康管理的民眾，都不應參加大型跨年活動。而且，千萬別心存僥倖，因為「天網」恢恢，「我們能找得到您」！有天網之稱的電子圍籬 2.0 出手，許多人拍手叫好，但也挑起國家進行隱私監控的敏感神經。

隱私爭議不只在防疫戰場，另一個例子是近年正夯的精準醫療。2021 年 1 月，《經濟學人》（The Economist）發布亞太區「個人化精準醫療發展指標」（Personalised-health-index）。臺灣勇奪亞軍，主要歸功於健全的健保、癌症資料庫及尖端資訊科技。

國際按讚，國內反應卻很兩極。早前曾有人質疑「個人生物資料」的隱私保障，擔憂是否會成為藥廠大數據；但另一方面，部分醫療研究者卻埋怨《個人資料保護法》（簡稱《個資法》）很嚴、很卡，大大阻擋了醫學研發。為何國內反應如此分歧？

中研院歐美所副研究員何之行認為，原因之一是，

《個資法》早在 2012 年就實施，跑在 AI 時代之前，若僅僅仰賴現行規範，對於新興科技的因應恐怕不合時宜。

健保資料庫爭議：誰能再利用我們的病歷資料？

來看看曾喧騰一時的「健保資料庫訴訟案」。

2012 年，臺灣人權促進會與民間團體提出行政訴訟，質疑政府沒有取得人民同意、缺少法律授權，逕自將健保資料提供給醫療研究單位。這意味，一般人完全不知道自己的病例被加值運用，侵害了資訊自主權。案件雖在 2017 年敗訴，但已進入大法官釋憲。

民間團體批評，根據《個資法》，如果是原始蒐集目的之外的再利用，應該取得當事人同意。而健保資料原初蒐集是為了稽核保費，並非是提供醫學研究。

但支持者則認為，健保資料庫是珍貴的健康大數據，若能串接提供學術與醫療研究，更符合公共利益。此外，如果過往的數據資料都必須重新尋求全國人民再同意，相關研發恐怕得被迫踩剎車。

種種爭議，讓醫學研究和資訊隱私之間的紅線，顯得模糊而舉棋不定。何之行指出，「個人權利」與「公共利益」之間的權衡拉鋸，不僅是長久以來政治哲學家所關心的課題，也反映了現代公共衛生倫理思辨的核心。

我們有權拒絕提供資料給醫療研究嗎？當精準醫療的腳步飛也似向前奔去，我們要如何推進醫學科技，又不棄守個人的隱私權利呢？

「精準醫療」與「精準健康」是近年醫學發展的重要趨勢，透過健康大數據來評估個人健康狀況，對症下藥。但健康資料涉及個人隱私，如何兼顧隱私與自主權，成為另一重要議題。

去識別化爭點：個資應該「馬賽克」到什麼程度？

何之行認為，「健保資料庫爭議」短期可以從幾項原則著手，確立資料使用標準，包括：允許退出權（opt-out）、定義去識別化（de-identification）。

「去識別化」是一道安全防護措施。簡單來說：讓資料不會連結、辨識出背後真正的那個人。何之行特別分享 Google 旗下人工智慧研發公司 DeepMind 的慘痛教訓。

2017 年，DeepMind 與英國皇家醫院（Royal Free）的協定曝光，DeepMind 從後者取得 160 萬筆病歷資料，用來研發診斷急性腎衰竭的健康 APP。聽來立意良善的計畫，卻引發軒然大波。原因是，資料分享不僅未取得病患同意，也完全沒有將資料去識別化，每個人的病史、用藥、就醫隱私全被看光光！這起爭議無疑是一大教訓，重創英國社會對於開放資料的信任。

回到臺灣脈絡。去識別化指的是以代碼、匿名、隱藏部分個資或其他方式，無從辨識特定個人。但要達到什麼樣的隱匿保護程度，才算是無從識別特定個人？

何之行指出，個資法中的定義不甚清楚，混用匿名化（anonymous）、假名化（pseudonymised）、去連結（delink）等規範程度不一的概念。臺灣也沒有明確定義去識別化標準，成為爭點。

現行法令留下了模糊空間，那麼他山之石是否能提供參考？

以美國《健康照護可攜法案》（HIPAA）為例，法案訂出了去除 18 項個人識別碼，作為去識別化的基準；歐盟《一般資料保護規則》則直接說明，假名化的個資仍然是個人資料。

退出權：保留人民 say NO 的權利

另一個消解爭議的方向是：允許退出權，讓個人保有退出資料庫的權利。即使健保資料並沒有取得民眾事前（opt-in）的同意，但仍可以提供事後的退出選項，民眾便有機會決定，是否提供健康資料做學術研究或商業運用。

何之行再舉英國國民健保署 NHS 做法為例：英國民眾有兩階段選擇退出中央資料庫 （NHS Digital）的機會，一是在一開始就拒絕家庭醫師將自己的醫病資料上傳到 NHS Digital，二是資料上傳後，仍然可以在資料分享給第三方使用時說不。畢竟有人願意為公益、學術目的提供個人健康數據，對商業用途敬謝不敏；也有人覺得只要無法辨識個人即可。

近年，英國政府很努力和大眾溝通，希望民眾認知到資料分享的共善，也說明退出所帶來的社會成本，鼓勵人們留在資料庫內，享受精準醫療帶給個人的好處。可以看到英國政府藉由公眾溝通，努力建立社會信任。

參照英國經驗，目前選擇退出的比率約為 2.6%。保留民眾某種程度的退出權，但善盡公眾溝通，應是平衡集體利益與個人隱私的一種做法。

歐盟 GDPR 個資保護的四大原則

健保資料庫只是案例之一，當 AI 成為大數據浪潮下的加速器，最周全之策仍然是針對 AI 時代的資料運用另立規範。 歐盟 2018 年實施的《一般資料保護規則》（General Data Protection Regulation，以下簡稱 GDPR），便是大數據 AI 時代個資保護的重要指標。

因應 AI、大數據時代的變化，歐盟在 2016 年通過 GDPR，2018 年正式上路，被稱為「史上最嚴格的個資保護法」。包括行動裝置 ID、宗教、生物特徵、性傾向都列入被保護的個人資料範疇。
歐盟在法令制定階段已將 AI 運用納入考量，設定出個資保護四大原則：目的特定原則、資料最小化、透明性與課責性原則。

其中，「目的特定」與「資料最小化」都是要求資料的蒐集、處理、利用，應在特定目的的必要範圍內，也就是只提供「絕對必要」的資料。

然而，這與大數據運用需仰賴大量資料的特質，明顯衝突！

大數據分析的過程，往往會大幅、甚至沒有「特定目的」的廣蒐資料；資料分析後的應用範圍，也可能超出原本設定的目標。因此，如何具體界定「特定目的」以及後續利用的「兼容性判斷」，便相當重要。這也突顯出「透明性」原則強調的自我揭露（self-disclosure）義務。當蒐集方成為主要的資料控制者，就有義務更進一步解釋那些仰賴純粹自動化的決策，究竟是如何形成的。

「透明性原則的用意是為了建立信任感。」何之行補充。她舉例，中國阿里巴巴集團旗下的芝麻信用，將演算法自動化決策的應用發揮得淋漓盡致，就連歐盟發放申根簽證都會參考。然而，所有被納入評分系統的人民，卻無從得知這個龐大的演算法系統如何運作，也無法知道為何自己的信用評等如此。

芝麻信用表示，系統會依照身分特質、信用歷史、人脈關係、行為偏好、履約能力等五類資料，進行每個人的信用評分，分數介於 350-950。看似為電商系統的信用評等，實則影響個人信貸、租車、訂房、簽證，甚至是求職。

這同時涉及「課責性」（accountability）原則 ── 出了問題，可以找誰負責。以醫療場域來講，無論診斷過程中動用了多少 AI 工具作為輔助，最終仍須仰賴真人醫師做最後的專業判斷，這不僅是尊重醫病關係，也是避免病患求助無門的問責體現。

科技防疫：無所遁形的日常與數位足跡

當新冠疫情爆發，全球人心惶惶、對未知病毒充滿恐懼不安，科技防疫一躍成為國家利器。但公共衛生與人權隱私的論辯，也再次浮上檯面。

2020 年 4 月，挪威的國家公共衛生機構推出一款接觸追蹤軟體，能監控足跡、提出曾接觸確診者的示警。但兩個月後，這款挪威版的「社交距離 APP」卻遭到挪威個資主管機關（NDPA）宣告禁用！

挪威開發了「Smittestopp」，可透過 GPS 與藍牙定位來追蹤用戶足跡，提出與感染者曾接觸過的示警，定位資訊也會上傳到中央伺服器儲存。然而，挪威資料保護主管機關（NDPA）宣告，程式對個人隱私造成不必要的侵害，政府應停止使用並刪除資料。

為何挪威資料保護機關會做出這個決定？大體來說，仍與歐盟 GDPR 四大原則有關。

首先，NDPA 認為挪威政府沒有善盡公眾溝通責任，目的不清。人民不知道這款 APP 是為了疫調？或者為研究分析而持續蒐集資料？而且，上傳的資料包含非確診者個案，違反了特定目的與資料最小蒐集原則。

此外，即便為了防疫，政府也應該採用更小侵害的手段（如：僅從藍牙確認距離資訊），而不是直接由 GPS 掌控個人定位軌跡，這可能造成國家全面監控個人行蹤的風險。

最後 NDPA 認為，蒐集足跡資料原初是為了即時防疫，但當資料被轉作後續的研究分析，政府應主動說明為什麼資料可以被二次利用？又將如何去識別化，以確保個資安全？

換言之，面對疫情的高度挑戰，挪威個資保護機關仍然認為若沒有足夠的必要性，不應輕易打開潘朵拉的盒子，國家採用「Smittestopp」這款接觸追蹤軟體，有違反比例原則之虞。

「有效的疫情控制，並不代表必然需要在隱私和個資保護上讓步。反而當決策者以防疫之名進行科技監控，一個數位監控國家的誕生，所妥協的將會是成熟公民社會所賴以維繫的公眾信任與共善。」何之行進一步分析：

數位監控所帶來的威脅，並不僅只於表象上對於個人隱私的侵害，更深層的危機在於，掌握「數位足跡」(digital footprint) 後對於特定當事人的描繪與剖析。

當監控者透過長時間、多方面的資訊蒐集，對於個人的「深描與剖繪」（profiling）遠遠超過想像──任何人的移動軌跡、生活習慣、興趣偏好、人脈網絡、政治傾向，都可能全面被掌握！

AI 時代需要新法規與管理者

不論是醫藥研發或疫情防控，數位監控已成為當代社會的新挑戰。參照各國科技防疫的爭論、歐盟 GDPR 規範，何之行認為，除了一套 AI 時代的個資保護規範，實踐層面上歐盟也有值得學習之處。

例如，對隱私風險的脈絡化評估、將隱私預先納入產品或服務的設計理念（privacy by design），「未來照護機器人可能走入家家戶戶，我們卻常忽略機器人 24 小時都在蒐集個資，隱私保護在產品設計的最初階段就要納入考量。」

另外最關鍵的是：設置獨立的個資監管機構，也就是所謂的資料保護官（data protection officer，DPO），專責監控公、私營部門是否遵循法規。直白地說，就是「個資警察局」。何之行比喻，

如果家中遭竊，我們會向警察局報案，但現況是「個資的侵害不知道可以找誰」。財稅資料歸財政部管，健康資料歸衛福部管，界定不清楚的就變成三不管地帶。

綜觀臺灣現狀，她一語點出問題：「我們不是沒有法規，只是現有的法令不完備，也已不合時宜。」

過往許多人擔心，「個資保護」與「科技創新」是兩難悖論，但何之行強調法令規範不是絆腳石。路開好、交通號誌與指引完善，車才可能跑得快。「GDPR 非常嚴格，但它並沒有阻礙科學研究，仍然允許了科學例外條款的空間。」

「資料是新石油」（data is the new oil），臺灣擁有世界數一數二最完整的健康資料，唯有完善明確的法規範才能減少疑慮，找出資料二次利用與科技創新的平衡點，也建立對於資料二次利用的社會信任。

資料來源：https://www.inside.com.tw/article/23814-ai-privacy-medical?fbclid=IwAR0ATcNjDPwTsZ4lkQpYjvys3NcXpDaqsmE_gELBl_UNu4FcAjBlscxMwss

跨界圍攻：「AI 視覺」公司已集體殺入智能駕駛圈

2021-05-22
雷鋒網

如今的智能汽車賽道，說挨肩迭背也不為過。

新勢力派引領變革，最為二級市場所看好；泛網際網路派占流量高地，擅技術遷移；傳統車企派根基夯實，品牌名聲享譽在外。

甚至財大氣粗的某地產派也曾放下豪言――力爭 3-5 年成為世界規模最大、實力最強的新能源汽車集團。

如華山比武般，大俠們個個嚴陣以待，各方勢力黃巾高擎，左右開弓。

你看看，前有行業鐵幕，中夾破釜沉舟之心，後是險峻江湖，哪還有初進牛犢的落腳之處？

即便如此，在月前燥熱尚未消退的上海車展後，鮮少被提及的AI視覺公司還是擠了進來。

看慣了巨頭們的聲勢浩蕩，轉身發現AI視覺企業們的入局講究一個循序漸進，起承轉合。

而他們的悄然進入，也給智能駕駛領域增添了幾段新故事。

海康威視：左手自研、右手投資

AI安防老大哥海康，深耕智能駕駛市場履行一貫的低調風格。

其對智能駕駛的綢繆始於2015年，當時海康內部計劃開展新業務，起初確定的業務有三：海康汽車電子、海康機器人、海康螢石。

2016年7月，耗資1.5億的海康汽車技術正式成立。

在此前後，海康還分別於2016年6月投資了威視汽車科技，2017年7月成立了海康汽車軟體。

2018年是海康智能駕駛的上升之年，市場渠道、技術研發上均有突破。

2018年2月，他們上線高級駕駛輔助系統、自動泊車APA+，同年又成功打入2019款保時捷卡宴的配置中。

汽車產業以穩為重，鏈條長、利益盤根錯節，新入者切入並不容易，而海康卻出其不意一舉打入高端。

數據顯示，截至2018年底，海康汽車已經通過了20家OEM的審核並成為其合格供應商，公司的主要客戶包括一汽集團、北京汽車、上汽榮威、上汽名爵、本田汽車等。

其中，定點項目超過200個，已量產的項目超過100個，覆蓋500家渠道合作夥伴。

成立子公司自研之外，投資也是海康較為看中的一大路徑。

在成立汽車電子公司之前，海康就曾在2016年入股毫米波雷達企業森思泰克，並成為後者的第二大股東。

2013年成立的森思泰克既是毫米波雷達第一批探路者，也是成績較為優秀的領軍企業之一。

森思泰克創始人秦屹是英國海歸的雷達專家，在英從事雷達研發和製造十餘年。

據悉，森思泰克所聚團隊成員中80%具有軍工背景，掌握雷達硬體、軟體和量產工藝等幾乎全部核心技術。

據悉，森思泰克毫米波雷達在北京、石家莊設研發中心，在蕪湖設總廠，在杭州設車載事業部。

石家莊，有軍工雷達大本營之稱，軍民毫米波雷達研發人才密集，且電科雷達研發54所和13所都在石家莊。

森思泰克也頗為爭氣。

2019年，思泰克首次實現大批量77GHz車載毫米波雷達國產化、突破國際巨頭壟斷。

森思泰克的77GHz毫米波雷達成為國內首個真正實現「上路」的ADAS毫米波雷達傳感器。

目前，森思泰克已成為紅旗、一汽、韓國現代、東風日產、長城、長安等國內外車企體系內供應商。

海康與森思合作的高分毫米波成像雷達+視覺融合技術，或許將對壘低線束雷射雷達。

大華股份：立足整車，三電、網聯、自動駕駛多點齊發

零跑汽車脫胎於大華股份的汽車部門，獨立後獲得了大華股份的技術和資金支持。

2015年，大華股份副董事長兼任大華股份CTO朱江明親自下場，成立零跑。

經歷2019年新能源補貼大退坡，不少新勢力造車企業已經出現嚴重資金問題，且變現存疑。

零跑汽車亦不例外。

2018年，零跑虧損 3.07 億元後，2019 年上半年又持續虧損約 2 億元。

2019年1月4日，零跑汽車第一款車S01上市，該車2019年全年交付約1000輛。

對於連續虧損的零跑，唱衰論一直也在網上發酵。

朱江明對此表示，「即使不融資，零跑也能再活三年。」他透露，大華股份將持續為零跑輸送資金，「當然我們希望能更多的融資，發展得更快些。」

在經歷融資受阻後，2021年伊始，零跑官宣融資43億元，合肥政府投資平台亦在其中。

今年年初，此前曾投資蔚來的合肥市政府與零跑方面簽訂戰略合作協議，未來合肥方面將對零跑B輪融資投資約20億元，並展開更多合作。

現金流方面，從不被業界看好，到巨額融資的到帳，仿佛又讓市場看到了可能性。

技術層面，零跑汽車稱自主研發了三電系統、智能網聯繫統、自動駕駛系統三大核心技術，並完全掌握自動駕駛核心硬體平台和算法技術，實現對自動駕駛感知、決策、執行層關鍵技術的自主化全覆蓋。

產品層面，零跑汽車目前旗下擁有3款量產車型，分別為：零跑T03、零跑S01以及零跑C11。

三款產品風格各異，銷量不一。

2020年，零跑汽車官方消息稱，2020年累計銷量達11391輛，其中T03為主力軍，貢獻了10266輛。

創始人朱江明也底氣頗足：「2023年零跑進入造車新勢力TOP3、2025年在國內新能源汽車市占率達到10%」。

商湯：求精感知技術，並進艙內艙外

與其他AI獨角獸相比，商湯在自動駕駛上布局較早，也更全面。

2017年進軍自動駕駛，商湯的汽車產業布局可分為艙內（智能車艙）和艙外（智能駕駛）兩大層面。

智能車艙層，基於前裝量產解決方案，以視覺感知技術為錨點，由點及面，覆蓋用戶從上車到用車的多個場景。

商湯的SenseAuto Cabin智能車艙解決方案包括駕駛員感知系統、座艙感知系統、智能進入等等功能。

據悉，在過去的兩年多時間裡，商湯已經拿下了30多個國內外頭部夥伴的智能車艙定點量產項目，覆蓋車輛總數超過1300萬輛，其中10 余個項目已經實現了量產交付。

智能駕駛層，商湯選擇與主機廠合作，做汽車廠商（OEM）及一級供應商（Tier1）的解決方案供應商。

在自動駕駛感知、決策和執行三大要素中，汽車廠商和Tier1占據重要角色。

2017年，商湯與OEM廠商本田簽訂了為期5年的長期合作協議，研發適合乘用車場景的L4級自動駕駛方案。

2018年，商湯完成杭州、上海半開放場地內實現無接管自動駕駛。2019年，在日本落地「AI自動駕駛公園」，將用於自動駕駛汽車的研發和測試，並面向公眾開放。

商湯的自動駕駛業務定位，是以視覺為主，其他元素為輔。

視覺之外，商湯在高精度地圖和雷射雷達、毫米波雷達等方面皆有技術儲備。

通過搭配多種不同傳感器，實現感知、分析預測、決策規劃控制、城市級三維地圖重建及無人車高精度定位能力等技術功能。

目前，商湯對自動駕駛技術進行了多次疊代，形成了一套較為成熟的智能駕駛方案：SenseAuto Pilot智能駕駛解決方案，聚焦 L2+ 級高級輔助駕駛至L4級自動駕駛創新，並在上海車展首次發布SenseAuto Pilot-P駕駛領航方案。

軟體之外，2019年3月，商湯還推出首款原創機器人SenseRover X自動駕駛小車，這是款針對自動駕駛的教學產品。

奧比中光：戰投＋自研，兩條腿走路

奧比中光是AI初創企業中對智能汽車投入最多的公司之一。

作為一家AI 3D感知技術方案提供商，成立於2013年的奧比中光現今已在3D傳感領域深耕近8年。

3D傳感作為人工智慧領域最核心的視覺感知技術，融合了晶片、算法、光學、軟體等多交叉學科技術，是人工智慧時代感知識別、新型人機互動等最為核心的技術載體。

除3D結構光外，奧比中光在雙目、iTOF、dTOF、雷射雷達等主流3D視覺感知技術領域也有長遠布局。

早在2018年，奧比中光就投資雷射雷達晶片級解決方案提供商飛芯電子。

飛芯電子成立於2016年，是一家專注於光電設備、雷射雷達研發、集成電路設計的高新技術企業。

成立僅2年，飛芯電子獲得了博世等注資。

據悉，飛芯電子以研發、生產雷射雷達系統及核心晶片為主要業務，客戶群體主要面向國內外汽車、機器人、無人機等生產研發廠商。

飛芯電子稱，其針對行業痛點，採用了連續波載調製或相干外差探測方案，利用焦平面點雲測距技術，滿足較高的空間解析度和較大的視場角，探測距離可超過200m，且無需複雜昂貴的機械掃描裝置，不斷提高系統可靠性，也使獲得的圖像更為清晰。

2019年4月，奧比中光成立車載3D視覺傳感方案提供商奧銳達。

奧銳達的業務重心在智能座艙，產品包括ToF攝像頭模組、雷射雷達等硬體以及3D ToF智能座艙方案。

承襲了奧比中光的3D視覺感知技術，奧銳達可為智能汽車帶來DMS、OMS、手勢識別、人臉識別、身份驗證等多種3D化智能功能。

其金融級安全的3D人臉識別方案，保護駕乘人員的信息安全；通過3D-ToF 攝像頭，實現多區域手勢控制；同時，智能汽車還可以通過3D信息，判斷駕乘人員體型、座艙內位置等。

近日，奧銳達還發布了為智能汽車量身定製的3D ToF智能座艙方案。

虹軟：主攻艙內，走軟硬一體之路

2018年，為應對手機市場見頂飽和，虹軟正式將業務從智慧型手機領域拓展至智能汽車、IoT等領域，一舉橫向突進自動駕駛市場。

虹軟科技創始人兼CEO鄧暉曾表示，未來每輛汽車裡都有10個以上的攝像頭，智能座艙將成為智能駕駛視覺AI的重點應用場景。

與其手機定位一樣，虹軟的智能汽車走軟硬一體解決方案，力圖做車載視覺一站式解決方案的供應商。

從招股書看，截至2018年底，虹軟科技的「汽車等loT產品」的業務收入僅367.95萬元，占比不足1%。

與多數視覺企業加裝雷射雷達等技術不同，虹軟的的自動駕駛解決方案完全基於視覺層面，且核心聚焦在車內智能。

虹軟科技的智能駕駛視覺解決方案，包括車內安全駕駛預警、駕駛員身份識別、車內安全輔助、輔助駕駛預警、自動泊車等眾多解決方案。

2019年3月，虹軟入股開易（北京）科技，後者主營業務包括主動安全智能終端（ADAS+DMS+人臉識別）、SDK軟體服務以及硬體整體解決方案。

2019年，虹軟在科創板上市。

虹軟表示，其在計算機視覺領域積累深厚，融合其暗光高反差拍攝、防抖等影像視頻增強算法技術，即使在車內光線不佳、人臉角度多變、車輛晃動等特殊情況下，也能夠很好地完成車輛周圍環境監測和車內人員監測等功能。

上市後，虹軟大力布局智能汽車及其他 IoT 智能設備領域，目前成效初現。

據虹軟表示，智能汽車板塊2019年開始真正量產。

數據顯示，2020年，智能駕駛視覺解決方案業務增長較快，實現營業收入6592.99萬元，同比增長310.61%。

據悉，虹軟智能駕駛相關產品包括DMS（駕駛員識別系統）、ADAS（高級駕駛輔助系統）、BSD（盲區檢測系統）、OMS（乘客識別系統）、Interact（視覺互動系統）、Authenticate（生物認證）、AVM（3D環景監視系統）、AR HUD（AR抬頭顯示）和智能後備箱等各類以核心算法為基礎的相關軟體解決方案。

高工智能汽車研究院數據顯示，DMS(駕駛員識別系統)的算法業務是其智能汽車業務的主要收入來源。

虹軟今年透露，其智能駕駛業務已實現37+7個前裝車型定點開發（37款量產車型定點，7款車型預研），以提供純算法為主，公司直接與Tier1或整車廠簽約，涉及多家國內主流車企（含造車新勢力）及部分合資車企。

格靈深瞳：最早入局，協同成長

成立於2013年，格林深瞳是最早的一批AI視覺公司，也是最早一批投入自動駕駛的AI視覺公司。

當年，格靈深瞳聯合英特爾研究院院長吳甘沙、國家智能車未來挑戰賽冠軍團隊負責人姜岩等一同創辦了一家專注於自動駕駛領域的公司――馭勢科技。

2016年，馭勢科技在北京誕生，格靈深瞳作為投資方入股馭勢科技。

過去五年，馭勢科技在洶湧潮水中奮力前行。

2017年1月的CES，馭勢科技向世界推出了無人駕駛概念車「城市移動包廂」，該車型成為了全球第三款獲得紅點設計大獎的無人車。

同年，這家公司分別在4月和6月，於白雲機場、杭州來福士率先展開面向普通公眾的無人駕駛商業化運營。

今年1月21日，香港國際國際機場宣布，由馭勢科技與香港國際機場管理局共同研發的無人駕駛物流車將替代人力駕駛拖車，承擔往返機場和海天客運碼頭的行李運輸任務，意味著其在機場的運用已逐步上量。

在過去的一年中，馭勢科技與長安民生物流、一汽物流、巴斯夫（BASF）等數十家企業建立了商業合作。

據透露，在國內某豪華品牌車型上，馭勢科技提供的軟體算法也已前裝量產，並幫助該自主品牌率先推出 L3 級自動駕駛功能。去年馭勢科技交付了數百套「AI駕駛員」，實現年度業績同比增長150%。

前不久，馭勢科技宣布完成累計超10億元人民幣的新一輪融資，在這場融資中馭勢科技獲得了國家資本的參投。

馭勢科技在無人物流埋頭苦幹，潛心鑽研，其成績是在無人物流領域的業務布局幾乎占到了國內市場的70%。

2016年誕生至今，馭勢科技經歷萬千辛酸，在密如繁星的棋子中探索出一條最優解法，以機場定式，在精進自我的路上捨命狂奔。

而格林深瞳的自動駕駛之路，也隨著馭勢科技越走越遠。

曠視：立足AI視覺，做車載全套解決方案

2018年11月，曠視曾公開展示過車載AI視覺解決方案。

彼時的曠視，其解決方案基於車載系統和駕駛過程的人臉解鎖、帳戶切換、駕駛員識別、多模態交互等功能為主，並收取相應軟體使用費和服務費。

「人臉解鎖」可通過車外的攝像頭捕捉駕駛員人臉信息並進行身份的識別與確認，實現人臉解鎖車門、臨時授權人臉解鎖車門；

通過車內的攝像頭實現刷臉啟動發動機、保險箱等，「帳戶切換」功能可通過人臉識別無感知精準識別駕駛員身份，配合車載智能系統，快速調整用戶預設的車輛各項個性化配置（座椅位置、反光鏡角度、空調溫度、音樂、燈光、導航等）。

「駕駛員識別系統」可通過車內攝像頭，實時查看駕駛員駕駛狀態和行為，在駕駛員出現疲勞駕駛或分心駕駛跡象時觸發預警，保障行車安全。

曠視曾表示，其與蔚來汽車實現了未來在智能汽車應用上的深度合作，真正的無人駕駛商用較遠，曠視聚焦對人類駕駛員的理解和輔助。

的盧深視：基於3D視覺相機，為產業賦能

的盧深視在智能汽車領域的角色，更多是與第三方合作的方式。

作為三維視覺領域的佼佼者，的盧深視在高精度深度感知成像、三維實時高精度重建、三維跟蹤識別及感知等技術方向上深耕多年。

上月，的盧深視出席了2021全球自動駕駛高峰論壇，並展示了其最新3D CV相機及其應用。

的盧深視兩款自研3D CV相機，其在5米範圍誤差小於1mm，指標超越國際3D相機巨頭，量產良率達99%以上。

基於前端低功耗嵌入式平台，兩款相機均可實現非接觸式精準識別，基於結構光原理，更可還原人臉高精度3D細節信息，通過人臉立體尺寸信息精準辨識人員身份，同時對於二維和三維攻擊識別正確率高達99.99%。

多提一句，安全性上，可達金融級別。

據悉，除了智能汽車領域，兩款相機也在智能家居、金融支付、智慧交通等領域展開布局。

智能駕駛：AI視覺第二春

AI視覺眾企入局智能駕駛賽道，並非跑題創作。

其一，布局智能駕駛，是戰略向外牽引使然。

自計算機視覺出走實驗室樊籠，AI安防、自動駕駛便拿到一大波投資人的「S卡」。

當年AI落地之時，安防提供了絕佳的土壤，AI公司在此實現技術與產業的交融。

期間，AI與安防彼此成就：

安防向世界輸送的海大宇等驕子，幾乎主導了全球安防市場話語權，行業極速擴容，向城市各個領域蔓延。

AI獨角獸們也從安防起家，並逐漸走向千行百業，邁向全域。

左邊是AI安防成主要營收來源，右邊是AI安防逐漸占領一席之地。擺在入局者眼前的，是如何保持縱向持續增長的必答題。

擺脫路徑依賴，尋找AI安防之外的市場，已是當務之急。

如果說，過去五年，AI視覺公司的路徑是「通用AI SDK 重定製集成項目實施」的話，那麼未來五年，他們可嘗試「非標領域的標準市場 形成標準化產品 低成本規模化複製」的路子。

非標領域的標準市場在哪？自動駕駛、醫療、晶片赫然在列。

縱觀AI市場，目光所及賽道幾近全員虧損，掘金志認為，與高成本人力無關，因為虧損在放大；與硬體儲備也無關，因為可以OEM。

核心在於：AI安防未能標準化，項目需求又無窮多。

那就去標準化市場？有人問。

標準化市場可以一夜之間把價格做到無窮低，但高額運營支出非AI企業所能承受。

標準化市場上不去，定製化市場下不來，AI公司的突破口在哪？答案是：非標準化市場裡找到標準化路子。

賽道上，自動駕駛正是明顯的非標領域的標準市場。與AI安防共通的是，智能駕駛初創企業也依賴資本輸入。

但前者場景碎片化、項目定製化，產品標準化之路漫漫；後者以智能汽車為載體，技術上軟體定義、人機協同一旦成型，會一招吃遍天下鮮。

眼下，不少智能駕駛新勢力已實現產品量產，並獲得一定規模的現金流。

對於一眾搶灘的各路豪傑，AI視覺的入場似乎有些遲。

但智能汽車賽道正熱、格局未定，智能汽車產業鏈長、細分領域繁雜，此時入場的AI視覺，你可以說它入場稍晚，但不能說它機遇不在。

其二，自動駕駛或是計算機視覺技術應用必登之高峰。

近幾年，機器學習持續深入，計算機視覺應用亦有了飛速進展。

千山萬水跨越的人臉識別小山，是AI最成功，也最基礎的一環。

真正的AI，是貫穿感知-決策-執行的長鏈條，這一點在自動駕駛上體現得尤為極致。

感知層，通過各類硬體傳感器捕捉車輛的位置信息以及外部環境信息；

決策層的「大腦」，基於感知層輸入的信息作環境建模，從而形成對全局的理解並作出決策判斷，再向車輛發出執行的信號指令；

最後的執行層，將決策層的信號轉換為汽車的動作行為。

自動駕駛技術是人工智慧、高性能晶片、通信技術、傳感器技術、車輛控制技術、大數據技術等多領域技術的結合體，落地難度之大，各路AI無不動容。

計算機視覺應用場景萬千，自動駕駛無疑是極具挑戰性、最具想像力的一條。

越是長在懸崖之巔的花，越讓人著迷。

一直以來，在環境感知環節，存在AI視覺與雷射雷達技術路徑之爭。

不管何種路徑更優，已經在視頻物聯領域經歷過殘酷驗證，AI技術儲備上，AI視覺企業們也已攢下不少經驗。

狼多肉少，能吃幾成飽？

「自動駕駛是很低級的行業嗎？所有人都想來分一杯羹。」

這調侃入局者們聽了，大抵會覺得分外委屈。

大多數困在第一道門檻，錢。

「沒有200億不要造車」的聲量振聾發聵，造車明星蔚來也曾資金一度跌入谷底。

雖說AI視覺公司除了大華的零跑汽車外，其他參與者目前都專注於智能駕駛硬體和系統，但這也是個昂貴的行當。

不少企業本身依靠資本輸血，是否有更多資金和精力參與自動駕駛廝殺，是他們需要思考的問題。

行業壁壘不容小覷。

汽車產業發展百餘年才形成了一套嚴謹而完整的生產流程和制度，乃至於衍生出了一套基於安全的工業文明，不是後來者們在短短的幾年時間裡就能夠顛覆的。

作為智能汽車的核心體現，自動駕駛技術遠未達到成熟的程度；車艙內的智能化體驗也還有豐富的想像空間。

換言之，如果跨界選手想要在智能汽車的世界裡找到自己的一席之地，不僅要高度重視安全這一話題，還要擁有強大的軟體能力。

但在前一輪前沿傳統主機廠以及蔚來、小鵬、理想等新造車勢力的人才軍備賽過後，新入局的玩家要如何吸納更多的專業人才？又如何權衡來自世界各地的人才的意見和建議，從而做出最終決策？

與此同時，智能汽車的研發不是一件只要懂軟體就能夠做成功的事情。

隨著電動化、智能化大潮的到來，造車的門檻看似降低了不少，但在這一過程中遇到的內因外因的難題，可能遠比想像中的要多。

行業資源尚需積累。

相比AI安防、智慧城市等領域，AI視覺跨界者在智能汽車領域品牌影響力和渠道資源不足，短期內，造血盈利能力較低。

而且，AI視覺企業布局智能駕駛時間不一，技術雖有共性但終究有別，相較於大多數垂直企業，尚有諸多不足。

故可見，過去幾年，即使AI視覺巨頭，步伐也較為謹慎，大多圍繞艙內智能、ADAS市場。

如果說巨頭們跨界，自帶熱搜體質，AI視覺企業跨界的光彩，多少暗淡了些。

前者身家優渥，拿著頂流體驗卡入場，高屋建瓴，後者更多是以小舟，涉鯨波。

當然，隨著技術日進一桿，資源聚沙成塔，營收逐年增長，他們將投入包括但不限於研發、營銷、資本等層面，難保這一葉扁舟，哪天出其不意成為可遠航的重磅郵輪。

莫道桑榆晚

眾多跨界玩家湧入智能汽車，激發了新的生機。

無論從何種角度來看，智能汽車的市場都蘊藏著無限機遇。

這個市場需要鲶魚的存在。

在新時代的風潮之下，我們固然期待看到不斷有實力強勁的新玩家們入局，留下中國智能汽車史上濃墨重彩的一筆。

我們也殷切地希望，這是一片能夠承載百花齊放，充滿新的生機和活力的沃土，而不是拔苗助長的投機者的港灣。

憑藉先發優勢，不少入局者或已暫列行業前位，但隨著各方力量的持續加碼，後來居上也並非不無可能。

保持警惕，時刻成長。

資料來源：https://www.chinahot.org/science/83632.html?fbclid=IwAR2Mm9ZU17srF7sCywqUPw-hmRAyGN_sN9XnL0_Q6mE4bUYwUpgGNX3wHps

📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Trust Token API 是一個正在標準化的瀏覽器 API，主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能，以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制，而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。

會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私，這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。

問題

大家應該都有點了一個產品的網頁後，很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面，他怎麼會知道我看了這個產品的頁面？

通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。

當使用者登入 Facebook 之後，Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面，當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時，瀏覽器在載入 SDK 時會再度夾帶這個識別碼，此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式，Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡，從你的瀏覽紀錄推敲喜好，餵給你 Facebook 最想給你看的廣告了。

不過跨站追蹤也不是只能用在廣告這樣的應用上，像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。

雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務，但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢？

這就是今天要講的新 API: Trust Token。

Trust Token API - The Chromium Projects

Trust Token / Privacy Pass 簡介

Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制，可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass，所以兩個運作機制類似，但是實作方式稍有不同。

先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春，不過大致上還是可以了解整個概念。

以 hCaptcha 跟 Cloudflare 的應用為例，使用者第一次進到由 Cloudflare 提供服務的網站時，網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。

當使用者答對問題後，Cloudflare 會回傳若干組 blind token，這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token，這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token，在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token，這個步驟稱為 redeem token。

但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起，也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token，但是在後續瀏覽不同網站時把 token 兌換掉時，Clouldflare 並無法區分哪個 token 是來自 Bob，哪個 token 是來自 Alice，但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。

但這樣的機制要怎麼完成呢？以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。

零知識證明 (Zero-knowledge proof)

零知識證明是一種方法在不揭露某個祕密的狀態下，證明他自己知道那個秘密。

Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的，下面簡單的翻譯一下：

假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉，如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力？我們可以設計一個流程來證明這件事情。

Alice 先把眼睛閉起來，請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候，告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到，但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。

而零知識證明的原理大致上就是這樣，你可以用一個流程來證明你知道某個秘密，即使你不真的揭露這個秘密到底是什麼，以上面的例子來說，這個秘密就是超能力運作的方式。

以上就是零知識證明的概念，不過要完成零知識證明有很多各式各樣的方式，今天我們要介紹的是 Trust Token 所使用的零知識證明：DLEQ。

DLEQ (Discrete Logarithm Equivalence Proof)

說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar)，如果是大寫如 G, H則是橢圓曲線上面的點 (Point)，如果是 vG 則一樣是點，計算方式則是 G 連續相加 v 次，這跟一般的乘法不同，有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。

DLEQ 有一個前提，在系統中的所有人都知道公開的 G 跟 H 兩個點，此時以下等式會成立：

假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何，並且在這個過程中不揭露 s 真正的數值，此時 Victor 可以產生一個隨機數 c 傳送給 Peggy，而 Peggy 則會再產生一個隨機數 v 並且產生 r，並且附上 vG, vH, sG, sH：

r = v - cs

所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值：

vG = rG + c(sG)vH = rH + c(sH)

我們舉第二個等式作為例子化簡：

vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH

這樣只有 Peggy 知道 s 的狀況下才能給出 r，所以這樣就可以證明 Peggy 確實知道 s。

從簡易到實際的情境

Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境，不過前面的例子就會相對比較天真一點，就請大家一步步的往下看。

基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的，以下參與的角色分為 Client 與 Server，並且都會有兩個階段 issue 與 redeem token。

Scenario 1

如果我們要設計一個這樣可以兌換 token 來確認身分的系統，其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server，Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client，這個產生 sT 的過程稱為 Sign Point，不過實際上運作的原理就是橢圓曲線上的連續加法運算。

SignPoint(T, s) => sT

等到 Client 需要兌換時只要把 T 跟 sT 給 Server，Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。

Issue

以下的範例，左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server，反之亦然。

// Client 發送 T 給 Server, 然後得到 sT

T -> <- sT

Redeem

// Client 要 redeem token 時，傳出 T 與 sT

T, sT ->

問題：Linkability

因為 Server 在 issue 的時候已經知道了 T，所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。

Scenario 2

要解決上面的問題，其中一個方法是透過 Blind Signature 達成。Client 不送出 T，而是先透過 BlindPoint 的方式產生 bT 跟 b，接下來再送給 Server bT。Server 收到 bT 之後，同樣的透過 Sign Point 的方式產生結果，不一樣的地方是情境 1 是用 T，而這邊則用 bT 來作 Sign Point，所以得出來的結果是 s(bT)。

Client:BlindPoint(T) => (bT, b)

Server:SignPoint(bT, s) => sbT

而 Blind Signature 跟 Sign Point 具備了交換律的特性，所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind：

UnblindPoint(sbT, b) => sT

這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了，而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點，同時因為 T 從來都沒有送到 Server 過，所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。

Issue

bT -> <- s(bT)

Redeem

T, sT ->

問題：Malleability

以上的流程其實也有另外一個大問題，因為有交換律的關係，當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT)：

BlindPoint(sT) => a(sT), a// a(sT) === s(aT)

此時如果將 aT 跟 s(aT) 送給 Server Redeem，此時因為

SignPoint(aT, s) => s(aT)

所以就可以兌換了，這樣造成 Client 可以無限地用任意數值兌換 token。

Scenario 3

這次我們讓 Client 先選擇一個純數 t，並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T，並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。

因為 redeem 要送出的是 t，上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了，因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到，所以就沒辦法無限兌換了。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, sT ->

問題：Redemption hijacking

在這個例子裏面，Client 其實是沒有必要傳送 sT 的，因為 Server 僅需要 t 就可以計算出 sT，額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題，如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。

不過在網站上沒講出實際上要怎麼利用這個問題，但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好，而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。

Scenario 4

步驟跟前面都一樣，唯一不一樣的地方是 redeem 的時候原本是傳 t, sT，現在則改傳 t, M, HMAC(sT, M)，如果再介紹 HMAC 篇幅會太大，這邊就不解釋了，但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。

這樣的特性在這個情境用很適合，因為 Server 透過 t 就可以計算出 sT，透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, M, HMAC(sT, M) ->

問題：Tagging

這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’，這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。

要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。

Scenario 5

前面的 DLEQ 講解有提到，如果有 Peggy 有一個 s 秘密純量，我們可以透過 DLEQ 來證明 Peggy 知道 s，但是又不透漏 s 真正的數值，而在 Privacy Pass 的機制裡面，Server 需要證明自己每次都用 s，但是卻又不用揭露真正的數值。

在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端，但 Server 端的回應就不一樣了，這次 Server 會回傳 sbT 與一個 DLEQ 證明，證明自己正在用同一個 s。

首先根據 DLEQ 的假設，Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client，而 H 則改用 bT 代替。

回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token，所以附上了一個 DLEQ 的證明 r = v - cs，Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替，此時 client 也有 sbT 也就是 sH)：

vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT

這樣就可以證明 Server 依然用同一個 s。

Issue

T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)

Redeem

t, M, HMAC(sT, M) ->

問題：only one redemption per issuance

到這邊基本上 Privacy Pass 的原理已經解釋得差不多了，不過這邊有個問題是一次只發一個 token 太少，應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。

Scenario 7

由於一次僅產生一個 redeem token 太沒效率了，如果同時發很多次，每次都產生一個 proof 也不是非常有效率，而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法，這樣就可以大大的降低頻寬需求。

不過這邊我們就不贅述 Batch DLEQ 的原理了，文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。

Issue

T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)

Redeem

t1, M, HMAC(sT1, M) ->

結論

Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式，期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。

不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去，而協議制定的過程中其實廣告龍頭 Google 也參與其中，希望這份協議還是可以保持中立，盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。

參考資料

IETF Privacy Pass docs

Privacy Pass: The Protocol

Privacy Pass: Architectural Framework

Privacy Pass: HTTP API

Cloudflare

Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)

Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化

Other

Privacy Pass official website

Getting started with Trust Tokens (web.dev)

WICG Trust Token API Explainer

Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用，列了很多零知識證明的源碼參考，但可惜的是 DLEQ 這個演算法講解有錯，讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心，源碼應該是可以參考的，解釋的話需要斟酌一下。

關鍵源碼

這邊我貼幾段覺得很有用的源碼。

privacy pass 提供的伺服器端產生 Proof 的源碼

privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼

github dedis/kyber 產生 Proof 的源碼

[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌