自西元2017年1月以來,英國稅務海關總署(Her Majesty's Revenue and Customs, HMRC)開始要求英國民眾使用線上語音方式進行身分認證,而民眾的聲音檔案亦被儲存至英國稅務海關總署的語音資料庫內。英國資訊委員辦公室(Information Commissioner's Office, ICO)深入調查後發現英國稅務海關總署的語音身分認證系統存在下列兩種違法情形:
英國資訊委員辦公室認為英國稅務海關總署前開情形已經違反了歐盟一般資料保護規則(General Data Protection Regulation, GDPR),根據歐盟一般資料保護規則,英國稅務海關總署在蒐集、處理或利用民眾個人資料時,必須合法、公正及透明,並應取得民眾的明確同意。英國資訊委員辦公室後續將要求英國稅務海關總署應刪除違法蒐集的生物識別資料。
本次英國資訊委員辦公室的執法行動是基於2018年5月25日生效的歐盟一般資料保護規則與英國2018年資料保護法(The Data Protection Act 2018),英國資訊委員辦公室強調創新的數位服務雖有助於民眾的生活更輕鬆,但絕不能以犧牲民眾的隱私為代價,同時也隱約透露著:「沒有一個組織(包含政府機關)能夠凌駕於法律之上。」。
2008年,連鎖咖啡店85度C告85.1度C商標侵權,台北地院以85.1度C影響了85度C的商譽和正常收益,判賠新台幣47萬元。-這是商標侵權爭訟常見「商標混淆」的具體場景,也是所謂的「正向混淆」(Direct Confusion)。試想,現在主客易位,85.1度C 是間小店,耕耘許久仍沒沒無聞;而85度C推出即一炮而紅、門庭若市。85度C是後來者,他是否可以商標混淆為由,主張85.1度C影響了其商譽和正常收益?這個「後商標比前商標強勢」的假設就涉及「反向混淆」(Reverse Confusion)。 所謂「商標的反向混淆誤認」,按經濟部智慧財產局〈行政法院105年度判字第465號判決研析〉,係指:「後商標因較諸前商標廣為消費者所知悉,消費者反而誤以為前商標係仿冒後商標,或誤認為前商標與後商標係來自同一來源,或誤認兩商標之使用人間存在關係企業、授權、加盟或其他類似關係。」 美國於1976年之Big O Tire Dealers, INC. v. Goodyear Tire & Rubber Co.案首度在侵害商標權訴訟承認有反向混淆之適用。然而,由於美國採「使用主義」(First to use),商標之認定係以使用的先後判斷之。而我國採註冊主義,商標先後以申請註冊的時間判斷之。我國最高行政法院105年度判字第465號判決則明確表示商標法明文規範商標註冊申請乃採先申請主義,排除反向混淆理論之適用。
美國加州網路身分冒用法2011年01月正式生效2010年12月,加州參議院通過網路身分冒用法(Criminal “E-personation”,Senate Bill 1411),針對在網路上惡意冒用他人名義的行為態樣處罰,法案提案人加州參議員Joe Simitian表示:「現有的身分冒用法規係1872年所訂,無法規範現代科技所衍生的身分冒用態樣。」所以法院一般認為網路上的冒用屬於身分剽竊的態樣,但此類型通常不涉及金錢的損失,法庭上證明困難,受害者求償不易,因而制定此一法案。 本法針對故意、未經同意在網路或其他電子途徑冒用身分,傷害、恐嚇、威脅、詐欺他人的行為,判定為輕罪(standard misdemeanor),最高可處以1000元美金或一年以下有期徒刑。因此,在社群網站中冒用他人名義,發表不雅言論的行為往後可能會受到處罰。 但「傷害、恐嚇、威脅、詐欺」的行為態樣的認定,可能會造成法院實際執法上的困難,而且可能侵害人民憲法第一增修條文的權利。以The Yes Man組織為例,該組織假冒美國商會(American Chamber of Commerce)在網路上發表支持眾議院通過氣候變遷法案,其主要目的在於遊說美國商會改變其立場,本法尚未通過前,美國商會向加州法院提出訴訟,美國商會曾就訴訟過程表達不滿,認為現行法對於身分被冒用者無所助益,然新法正式施行後,本案如何在不侵犯憲法第一增修條文的情況下,嚇阻真正帶有惡意的身分冒用者,值得進一步觀察。
買回用戶迴路的另一種選擇 美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下: 1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。