ECODIR之線上爭端解決機制介紹
有鑑於網路使用人口中，不同使用者族群所消耗的傳輸量比例相差懸殊，美國寬頻業者於近來積極推動網路傳輸流量上限管理計畫，且繼Comcast與Time Warner等業者的初步嘗試後，美國最重要的網路服務提供者—AT&T，也宣布將開始進行客戶網路流量管理計畫。 這項嘗試計畫將以限制新的DSL用戶為起點，其所規定的每月下載與上傳流量上限，係依據客戶申請的寬頻方案有所不同，分別被限制在20G至150G (gigabytes)不定。超過的部分則將持續向使用者警告兩個月後，依每超過1G加收一美元的費用，向使用者收費。 至於提出此項管理方案的理由，據AT&T發言人表示，是因為網路頻寬的使用分佈過於不平均，高達46%的頻寬是5%的使用者在使用，而21%的頻寬更是只為極少數的1%用戶所使用，顯然太過集中。根據AT&T的傳輸上限規定，購買傳輸速度3M (megabits)的寬頻使用者，日後每月的傳輸量上限是60G，這大約等於是下載30部DVD畫質電影的傳輸量。 不過，也有分析師指出，現階段欲全面滿足使用者的頻寬需求，對網路服務提供者而言尚非極大的財務負擔，且管制流量上限的作法，可能對既有以「吃到飽」費率方案為基礎，所發展出來的網路應用服務模式，造成極大的衝擊，此亦也可能引發後續有關網路中立性的政策辯論。
中國將對幹細胞臨床研究及應用研擬管理規範為妥適管理中國幹細胞醫療產業，中國衛生部下令停止未經許可之幹細胞臨床研究和應用行為，並展開為期一年的幹細胞臨床研究和應用規範整頓工作。此期間分為「自查自糾」、「重新認證」和「規範管理」等階段。中國衛生部及國家食品藥品監督管理局(以下簡稱食品藥品監管局)辦公室於今年（2012年）1月6日發布一份名為《關於發展幹細胞臨床研究和應用自查自糾工作的通知》之部門規章，明白揭示於「自查自糾」階段各省、自治區及直轄市之衛生廳局及食品藥品監督管理局應如何辦理。 該通知中要求全國各級各類從事幹細胞臨床研究及應用之醫療機構及相關研究單位應依照《藥物臨床實驗質量管理規範》及《醫療技術臨床應用管理辦法》之規範進行自查自糾工作，如實總結並填寫幹細胞臨床研究和應用自查情況調查表，報告已完成或刻正進行之幹細胞臨床研究和應用活動；另外一方面，中國衛生部及食品藥品監管局及各省、自治區及直轄市將分別組成工作領導小組及工作組，制定自查自糾工作方案。針對尚未經批准之幹細胞臨床研究和應用，於通知文件中明白揭示應予停止；已經批准者，亦不得任意變更臨床試驗方案，或自行變更為醫療機構收費項目。值得注意者，為整頓對幹細胞臨床研究及應用之管理，並研擬符合國內需求之管理機制，直至今年7月1日前，相關主管機關將不受理任何申報項目。 中國截至目前為止，尚未針對幹細胞技術之臨床實驗或應用做成法規或政策，僅適用一般性藥品法規，相較於國際間先進國家屬相對鬆散。中國衛生部及食品藥品監管局於近日做成之通知文件顯示了中國政府開始對於幹細胞臨床實驗及應用之規範面向有所重視，針對其後續衍生之管理規範值得我們持續追蹤關切。
歐盟執委會推遲個人資料保護指令修正計畫歐盟執委會主席Barroso在今年年初設立了負責「正義、基本權與公民」（Justice Fundamental Right and Citizenship）事務的新任務單位。而負責此單位的執委會委員Reding自年初以來已多次宣示對個人資料保護以及隱私權的重視。在今年三月份的演講中，Reding更宣布將在年底前提出修正歐盟個人資料保護指令的內容。惟此承諾在歐盟會員國的壓力下恐怕無法踐履了。歐盟執委會於日前已表示將提出一份新的行動宣示來取代原先的修法計畫。 歐盟目前的個人資料保護指令乃在1995年制定，迄今已有15年之久，雖然其許多原則在今日仍然適用，但面對新科技、新應用，如社交網站、雲端應用等的發展，該指令仍不免顯出不足之處。此外，在原先的架構下，執委會也無法介入所謂歐盟「第三支柱」下的事務（亦即與犯罪相關的警政、司法合作事務），但此狀況在里斯本條約通過後理應有所改變。以上兩點也正是Reding提議修正個人資料保護指令的理由。但由於部分歐盟會員國政府認為Reding所提有窒礙難行之處，例如法國即直言Reding的修法時程不切實際，執委會及Reding也因此放棄原先規劃。至於新的行動宣示到底會不會真的納入歐盟個人資料保護指令的修正計畫，其時程與內容如何，值得持續注意。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。