美國「能源效率改革法案」簡介
德國聯邦法院（簡稱：BGH）民事庭於2015/11/26分別在兩件案例中(I ZR 3/14 和 I ZR 174/14)針對網路服務提供者（ISP）責任作出具重大影響力之終審決定。BGH認為即使此侵權網站之內容可在別處被找到，原則上德國ISP仍可阻斷侵權網站之連接。兩案分別由德國音樂集管團體GEMA對德國電信(I ZR 3/14)，以及華納、新力、聯合音樂共同對一德國私人電信公司Telefonica O2所提起 (I ZR 174/14)，聲明請求法院命令網路連接業者切斷對侵權網站之連接。兩案原告等之聲明分別在一審與上訴審皆被駁回，於是分別上告(Revision)至BGH。 BGH於判決中指出，雖不排除ISP可阻斷對侵權網站之連接可能性，然先決條件在於著作權人需先盡合理的努力（Zumutbaren Anstrenungen），去阻止被保護內容之擴散。而兩案中原告等未盡此義務，故以此為理由駁回上告。BGH課予著作權人盡合理的努力後，才能訴諸此切斷侵權網站連接之最終手段，此可為我國處理網路服務提供者（ISP）之第三人侵權行為責任之參考。
歐盟於YouTube架設影音分享頻道EU Tube繼YouTube對美國總統大選的影響力逐漸受到各界矚目後，大西洋彼岸的歐盟執行委員會（European Commission），也漸體認到影音分享網站在商業應用外，對言論傳播乃至於政治活動之潛在影響。 有鑑於此，歐盟執行委員會甫於上月二十九日，於YouTube網站上增置一個名為 “EU Tube” 的視聽頻道，以做為歐盟（European Union）官方和歐洲公民間的溝通渠道。 關於此種利用線上影音分享網站作為政府資訊傳播和政策公開宣傳的創舉，有幾點值得國內注意。 首先，此一歐盟執行委員會與YouTube簽訂的頻道協議，乃是非專屬的協定。換言之，歐盟執行委員會仍可同時與其他網站或媒體簽訂類似之服務協議。其次，EU Tube之內容亦不僅限於硬性的政策或行動討論，而包含了從氣候變遷、能源議題到移民等各種公民相關事項，甚至有內容大膽的 ”Film Lovers Will Love This!” 的前衛影片。更有甚之，使用者對於不同影音檔點擊觀看次數（有數百萬人次與僅一千人次的差異）的資訊，也可作為日後進一步分析利用的原始資料。不過，雖然歐盟極力推動其內部之語言多樣性，目前既有的影片仍以英文為主。 歐盟發言人強調，納入YouTube等網站為對外溝通管道的作法，是為了盡可能擴大與歐盟公民的聯繫，但主要仍以易受YouTube吸引的年輕人為主。由此可見，網路網路對不同年齡層、世代的影響仍有差異，而公領域與影音分享網站日漸深化的關係，也考驗傳統媒體和政治互動的準則。
眾議員提出新法以因應數位科技轉換產生的權利保護問題為避免數位科技轉換所可能發生的權利保護缺口，美國眾議院司法委員會主席 James Sensenbrenner Jr. 與議員 John Conyers 於本月 16 日共同提出了「 Digital Transition Content Security Act 」（ DTCSA ， H.R.4569 ），要求業者應在次世代的數位影像製品中加入反盜版技術。該草案的提出，無疑地為飽受盜版所苦的好萊塢注入一劑強心針。 原本可受到著作權法保護的數位內容，一旦由數位轉換為類比（ analog ）形式，再由類比轉換回數位後，其品質上雖稍受影響，但此一新的數位內容即不再受著作權法的保障，眾議員 John Conyers 將之稱為「類比漏洞」（ analog hole ）， DTCSA 的提出即在於因應此一棘手問題。未來草案若能順利通過，除非業者能提出有效阻斷違法複製的策略，否則在一年緩衝期過後，業者凡有製造或販售可將類比影像訊號轉換為數位訊號之設備，均將被宣布為違法。可能因此受到影響者，包括了電腦調頻器（ PC-based tuner ）與數位錄影機（ digital video recorder ）等。 全美電影協會（ MPAA ）對此新法大表歡迎，主席 Dan Glickman 認為 DTCSA 的提出，不僅保護了權利人，同時也將提供消費者更多的選擇。但另一方面，在 DTCSA 賦予商業部（ Commerce Department ）更大的權力以監視家電製造業者之下，草案無可避免地將遭致來自業者一方強大的反彈力量。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。