科技為民眾帶來溝通的便利性,卻因不夠人性化,常使身心障礙人士無法享受無遠弗屆的服務。因此,為了使身障者易於與他人溝通,FCC推動電信轉接服務( (Interstate Telecommunications Relay Service),讓通訊科技更易於使用。藉由電話中繼服務基金(Interstate Telecommunications Relay Service Fund)的支持,提供文字電話轉接(Text Telephone) 、語音轉語音(Speech-to-Speech)、電話字幕服務(Captioned Telephone Service)、視訊轉接服務(VideoRelay Service)與網路轉接字幕電話服務( Internet Protocol Captioned Telephone Service,下述簡稱IPCTS),協助聽障、語言障礙民眾得以享有電信服務。 但是,近幾個月來,FCC發現電信商要求IPCTS的補助與日俱增,從2012年6月起,每個月成長約11%,且導致10月時面臨請求總支出超過預算4百萬美元之危機。為了解決電話中繼服務基金(Interstate Telecommunications Relay Service Fund)面臨嚴重資金不足的威脅,FCC在2013年01月25日公佈FCC 13-13法規制定建議通知(Notice of Proposed Rulemaking),希望藉由下述規定,短暫性解決民眾過度、不當取得服務之問題: 1.禁止推薦獎勵計畫:禁止業者給予獎勵、回報的方式,鼓勵民眾使用網路轉接字幕電話服務。 2.供應商提供IPCTS服務,需符合三要件,方可取得補助: ‧ 每位使用者均需登記方能取得服務。 ‧ 供應商需取得用戶自我認證,才能完成註冊程序。 ‧ 使用者並非使用從政府計畫中取得IPCTS設備,而其設備卻低於75美元時,供應商需從使用者取得公正第三方證明。 3.供應商提供設備與軟體,必須於每通電話完成後,可以自動關閉。亦即消費者每次使用時,均需經過開啟的步驟,以保護隱私。 在FCC適度處理IPCTS不當使用後,可以預見電話中繼服務基金更能發揮所需,此舉不僅使科技更貼近於大眾、減少溝通障礙外,更可落實普世價值,使美國社會福利更加完善。
歐盟資料保護工作小組修正通過GDPR個人資料當事人同意指引因應歐盟「通用資料保護規則」(The General Data Protection Regulation,或譯為一般資料保護規則,下簡稱GDPR)執法之需,針對個人資料合法處理要件之一當事人「同意」,歐盟資料保護工作小組(Article 29 Data Protection Working Party, WP29)特於本(2018)年4月10日修正通過「當事人同意指引」(Guidelines on consent under Regulation 2016/679),其中就有效同意之要件、具體明確性、告知、獲得明確同意,獲有效同意之附加條件、同意與GDPR第6條所定其他法定要件之競合、兒少等其他GDPR特別關切領域,以及依據指令(95/46/EC)所取得之當事人同意等,均設有詳盡說明與事例。 GDPR第4條第11項規定個人資料當事人之同意須自由為之、明確、被告知,及透過聲明或明確贊成之行為,就與其個人資料蒐集、處理或利用有關之事項清楚地表明其意願(unambiguous indication)並表示同意。殊值注意的是,如果控制者選擇依據當事人同意為任何部分處理之合法要件,須充分慎重為之,並在當事人撤回其同意時,即停止該部分之處理。如表明將依據當事人同意進行資料之處理,但實質上卻附麗於其他法律依據,對當事人而言即顯係重大不公平。 換言之,控制者一旦選擇當事人同意為合法處理要件,即不能捨同意而就其他合法處理的基礎。例如,在當事人同意之有效性產生瑕疵時,亦不允許溯及援引「利用合法利益」(utilise the legitimate interest)為處理之正當化基礎。蓋控制者在蒐集個人資料之時,即應揭露其所依據之法定要件,故必須在蒐集前即決定其據以蒐集之合法要件為何。
個人資料受害該向誰求償? 美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。