美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。
微軟對歐盟指令提起第二次上訴,該指令是命令微軟分享其原始碼給開放原始碼軟體公司。 在歐盟第二最高法院判決前,微軟公司發言人 Tom Brookes 說新上訴,是基於 6 月份( 2005 年)與歐盟總部的協議,要透過法庭決定原始碼的爭議問題。 他說「微軟提起申請要求法院撤銷原訴訟決定,特別是關於將通訊協定的原始碼廣泛的授權,因為這都是微軟的智慧財產權」。 「我們採取這步驟,讓法庭能可以檢視現下的爭議,並就全世界智慧產權的保護提供一個長遠的意義」。 歐盟發言人 Jonathan Todd 說微軟公司軟體的互用性( interoperability )協議,無法用智慧財產加以保護,並且應該能在開放原始碼公司中,根據以往的營業執照加以流通使用。 不過,歐盟的執行者-歐洲委員會認為,相信此事件將獲得解決,如果盧森堡的原審法院維持 2004 年 3 月對微軟公司的規範。在 2005 年 8 月微軟公司最近的訴訟中,顯示出第二種情況。 Todd 說歐盟意識到微軟公司並沒有在與開放原始碼公司的分享協議中,分享微軟的觀點。 另外微軟第一次上訴判決的日期益尚未決定,微軟起訴乃針對歐盟命微軟必須支付 4 億 9 千 7 百萬歐元( 6 億 2 千萬多萬美元)的反拖拉斯罰金,這也是歐洲有史以來最大的反拖拉斯罰金。 歐盟聲稱軟體巨人已過度行使其 Windows 軟體統治,而把競爭者封鎖在市場外。它命令微軟公司出售不含媒體播放器的軟體,並強迫它與其他伺服器軟體競爭者分享技術,使那些競爭者的產品可以與 Windows 為作業軟體的電腦進行更好的訊息交流。
USPTO 宣佈將加速綠色科技專利案件審查美國專利商標局USPTO日前宣佈一項專為綠色科技(Green Technologies)而設的前導計劃(Pilot Program),透過這項計劃期望能將相關溫室氣體排減、節約能源等申請案加速其審查、公開及訴願程序,至少縮短流程一年。目前平均來說從申請至最終結果出爐需耗時40個月。這項消息係由美國商務部長駱家輝(Gary Locke)所宣佈,普遍被認為是為了呼應於哥本哈根舉行的聯合國氣候變化框架公約第15次締約方會議。 符合條件的申請案必須於2009年12月8日前送件,而且必須是尚未收到第一次官方通知(First Office Action,包括限縮專利範圍的通知),另外申請人還必須於2010年12月8日前以電子檔提交「特別審查程序」(petition to make special)並符合下列要求: ●必須是正式發明申請案(non provisional utility application),不適用於再領證(reissue) 與再審查(re-examine) 專利 ●必須是上述前導計劃中所包括的約79項專利項目之一 ●申請案必須不包含超過3個獨立項與20個專利申請範圍 ●如欲提早公告需附上申請書 (petition) ●如果USPTO判定為超過一項的發明,申請人必須同意用電話做出選擇 雖然USPTO預估目前有25,000件審核中的專利符合加速審理的資格,但他們預計只受理最初的3000件申請以評估這項計劃的效益與工作量。至於有意提出申請者則需要審慎評估快速審查之外的其他利弊,例如提早公告,限縮的運用範圍與專利申請範圍等。這項計劃公佈的同時USPTO的局長 David Kappos 亦承諾將定期對外更新該計劃的進度,並將成立一個網上的交流平台讓大眾可以對此計劃提出意見。
德國通過《小型電動車條例》,實現清潔現代化運輸並確保道路安全隨著現代德國城市興起騎乘小型電動車(例如:電動滑板車和電動踏板車)風潮,德國聯邦交通及數位基礎設施部(Bundesministerium für Verkehr und digitale Infrastruktur, BMVi)制定小型電動車條例(Elektrokleinstfahrzeuge-Verordnung),以實現清潔現代化運輸並確保道路安全,該條例於2019年6月15日正式生效,並取代原有的行動輔助工具條例(Mobilitätshilfenverordnung),此外,德國聯邦車輛運輸管理局(Kraftfahrt-Bundesamt, KBA)並陸續公布經審驗合格之小型電動車清單。 由於歐洲議會及理事會通過的二輪或三輪和四輪車核可及市場監督規則(EU Nr. 168/2013)將自動平衡車輛和無座椅車輛特別排除,因此BMVi制定行動輔助工具條例,以規範例如Segways的新型運輸工,然而隨著市場推出更多新型小型電動車,原行動輔助工具條例已無法有效規範,因此制定小型電動車條例,除將原本核可小型電動車納入適用外,而本條例所稱小型電動車定義為第一,具備轉向或支撐桿;第二,最高時速設計6~20公里/小時;第三,功率限制為500瓦(自動平衡運輸工具為1400瓦);第四,最低安全要求(例如制動裝置和照明系統,駕駛動態和電動安全設備)。另條例規範重點如下:(1)小型電動車須年滿14歲方能使用,但無須考取任何駕駛執照;(2)小型電動車應行駛於自行車道上,如該段道路無設計自行車道可行駛於側車道,並禁止行駛於人行道或步行區,且不得於踏板上另搭載他人或物品及攀附於其他車輛;(3)須遵守其他一般道路交通法規,特別是保持謹慎駕駛以及酒駕規定須遵守相關規範;(4)保險部分,因小型電動車輛屬於機械動力車輛,故必須投保,並將投保證明貼紙黏貼於車輛上。 另外,BMVi主張並支持小型電動車可攜帶上公共交通工具,然原則上,攜帶小型電動車搭乘公共交通工具,受貨物運輸規範約束,應視電車及無軌電車等固定路線動力車輛之一般條件及服務條例(BefBedV)第11條,或有關運輸公司之特殊運輸條件規範個案判斷。
美國國家標準暨技術研究院規劃建立「人工智慧風險管理框架」,並徵詢公眾對於該框架之意見美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST)為管理人工智慧對於個人、組織以及社會所帶來之風險,於2021年7月29日提出將建立「人工智慧風險管理框架」(Artificial Intelligence Risk Management Framework, AI RMF)之規畫並徵詢公眾意見,截止日為9月15日,並預計於10月發布正式報告。 依照NIST說明,公眾所建議之人工智慧風險管理框架,可促進人工智慧之可信賴性,其中包含如何應對並解決人工智慧於設計、發展及使用過程中所遭遇之「精確度」(accuracy)、「可解釋性」(explainability)、「偏見」(bias)等議題。此外,上開管理框架預計為非強制性、供企業自願性使用於人工智慧設計、發展、使用、衡量及評估之人工智慧標準。 依現有公眾意見徵詢結果,其中DeepMind公司建議於人工智慧設計初期,必須預先構思整體系統之假設是否符合真正社會因果關係。舉例言之,當設計一套可預測民眾健保需求程度之系統時,如輸入參數僅考量民眾於醫療上的花費,將使僅有可負擔較高醫療費用之民眾被歸類為健保需求程度較高者,從而導致健保制度排擠經濟負擔程度較差之公民,故在設計系統時,應從預先設定之假設事實反面(counter-factual)思考並驗證是否會產生誤差或公平性之問題(例如預先思考並驗證「醫療費用支出較低之民眾是否即可被正確歸類為健保需求度低之民眾」)。惟進行上述驗證需要大量社會資料,因此DeepMind也建議NIST應建立相關機制,使這些社會資料可以被蒐集、使用。 此外,亦有民眾建議管理框架應有明確之衡量方法以及數值指標,以供工程界遵循。同時鑒於人工智慧發展極為快速,未來可能有不同於以往之人工智慧類型出現,故亦建議NIST應思考如何在「建構一套完整且詳細之人工智慧治理框架」與「保持人工智慧治理框架之彈性與靈活性」之間取得平衡。 最後,目前也有許多徵詢意見指出,許多人工智慧治理之目標會相互衝突。舉例言之,當NIST要求人工智慧系統應符合可解釋性,則人工智慧公司勢必需要經常抽取人工智慧系統中之「數據軌跡」(audit logs),惟數據軌跡可能被認為是使用者之個人資料,因此如何平衡或完善不同治理框架下之目標,為未來應持續關注之議題。