FCC建議調整普及服務基金以推動寬頻建設
美國聯邦通訊委員會（The Federal Communications Commission, FCC）擬於3月17日向國會提出未來的國家寬頻計畫，並預計於2012年開始，調整目前用來補助電話服務的普及服務基金（Universal Service Fund），以推動高速網際網路。
美國普及服務基金的建立，原本是用以確保所有美國居民接取基本的電話網路。依目前的普及服務基金計畫，除了補助低收入居民電話服務、學校與圖書館的網際網路接取，與鄉間醫療單位的高速網路連結之外，最主要部份是對於由民營事業建設網路不符經濟效益的偏遠鄉區提供電話服務；此部份基金的預算是來自電信業者跨州與國際長途電話收益之稅收，於2010年達約為80億美元，未來將轉作推動寬頻網路之用，至於普及服務基金中的其他部份，則將繼續維持。
在FCC的計畫中，不僅在普及服務基金下設立連結美國基金（Connect America Fund）來補助寬頻服務，並將設立行動基金（Mobility Fund）發展3G無線網路。另外，FCC預計向國會提出的計畫包含多項選擇，包括在不要求國會另行增加預算下，達成在2020年99%美國家戶接取寬頻之目標，以及經由國會同意於未來三年投入額外的90億美元，以加速寬頻網路建設等方案。
為了減少美國專利訴訟泛濫，及防止專利蟑螂輕易向他人提起專利訴訟，美國最高法院在2014年6月 對兩件專利訴訴訟案進行判決，此決定也對專利權人及專利蟑螂不利。 首先，最高法院針對Limelight Networks v. Akamai Technologies否決聯邦上訴法院的判決。聯邦法院認為Limelight雖然沒有使用Akamai商業方法中每一個過程步驟之專利，但其使用其方法專利之其中方法就算造成間接侵權（induced infringement）。然最高法院認為，聯邦法院的判決對於間接構成侵權有誤解，Limelight所使用的商業方法並沒有引導間接構成侵權。此決定對於現今網路科技盛行之時代有很重要的影響，更防止不實施專利體及專利蟑螂隨意對潛在對象提起專利訴訟。 另一個案件為Nautilus, Inc. v. Biosig Instruments, Inc，最高法院亦駁回聯邦上訴法院之判決，對於專利說明（patent claim）的內容清楚性作出新的說明。聯邦上訴法院在此案中對於專利法第112條中專利說明的要求作出解釋，認為凡是專利說明不會難以解釋且模糊（insolubly ambiguous），專利說明皆可符合專利法規定。但最高法院採不同見解，認為聯邦法院的見解不符合專利法之規定，規定專利說明的內容必須要合理且明確，使可符合專利法的要求。此決定對於專利蟑螂尤其是一大打擊，過往專利蟑螂多以模糊的專利說明來進行專利訴訟，但今後要求明確的專利說明，讓雙方有更清楚的專利說明依據進行專利訴訟。
歐洲新著作權指令 將影響互聯網環境下之著作使用2018年9月12日，歐洲議會通過歐盟委員會於2016年制定的「單一數位市場著作權指令」，其中包含最具爭議的兩項條款： 第11條是有關「鏈接稅」（link tax）的條款。針對使用或匯集新聞文章片段的網站，未來恐需向源頭出版之新聞業者支付授權費用。例如若Twitter推文中包含來自Guardian文章的螢幕或文字摘要截取，則Guardian可以要求Twitter支付授權費用。 第13條則是有關「上傳過濾器」（upload filter）或稱「Memes禁令」（meme ban）的條款。為加重網路平台服務業者防止上傳者侵害著作權的監控責任，要求如Google和Facebook等業者，須使用強制內容過濾的軟體以清除違規行為，且須建立快速刪除機制，避免侵害著作權。 該指令在歐洲議會通過後，將進入歐盟委員會、歐盟理事會和歐洲議會之間的非正式談判。這三個組織將決定最終版本，約2018年12月提交給歐盟法律事務委員會，最後於2019年1月再回到歐洲議會進行投票。 歐盟指令本身雖不是法律，如何解釋立法也將取決於各國，惟透過本次歐洲議會的結果，可預見未來在歐洲市場，對於著作權人的保護與使用者的行為，將朝權利衡平的方向作調整。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。