2012年歐洲議會發表的綠皮書「邁向信用卡、網路以及手機支付的整合歐洲市場(Towards an integrated European market for card, internet and mobile payments)」,並進行廣泛的公眾意見徵詢,舉辦公聽會,最後決議進行現有歐洲支付法制架構的修正。歐盟支付服務指令修正案(revised Payment Service Directives, PSD2)於2013年7月由執委會提出,2015年10月歐洲議會通過,今年1月12日生效,預期英國、保加利亞、丹麥、德國、奧地利以及法國將會率先修正原有的支付服務法制完成轉換。產業界一致對於修正案表示歡迎,因為本次修正將會大幅提升支付創新應用的發展可能,尤其是行動支付。
PSD2之重大修正包含針對支付服務的內容作出修正,新增第三方支付服務提供人(third party payment service provider,簡稱TPP)為支付服務之內容(附件一第7項)。TPP的內涵為透過對於其它支付服務提供者的支付帳戶的存取,提供包含支付發動服務(payment initiation services)以及帳戶資訊服務(account information services)。依照第58條規定,TPP服務提供者具備下列義務:
1.確保支付服務使用者的個人化安全資訊不會被其它人取得。
2.以明確的方式向帳戶之支付服務提供者認證自己的身分。
3.不儲存支付服務使用者的敏感支付資訊或個人化安全憑證。
除此之外,PSD2明確將純粹的技術服務提供者排除於支付機構之範圍,無需適用支付服務指令。
PSD2亦授權EBA發布相關規定制定技術門檻,包含強力的客戶身分認證以及通訊資訊標準。
歐盟法院(Court of Justice of the European Union, CJEU)於2023年12月14日對Gemeinde Ummendorf(C‑456/22)案作出判決。歐盟法院試圖釐清《歐盟一般個人資料保護規則》(General Data Protection Regulation, GDPR)第82條的民事求償規範中,資料主體受到非財產上的損害要到何種程度才可獲得賠償。 本案源自於兩位自然人原告與德國的烏門多夫市政府(Municipality of Ummendorf)之間的紛爭。2020年,烏門多夫市政府未經兩位原告同意情況下,在網路上公布市議會議程與行政法院判決,這些資訊內容均多次提及兩位原告的姓名與地址。兩位原告認為市政府故意違反GDPR,因此依據GDPR第82條請求市政府賠償,並進一步主張該條意義下的非財產損害,不需要任何損害賠償門檻。然而,市政府則持相反意見。 長久以來,德國法院傾向認為,GDPR的非財產上損害需要超過某個「最低損害門檻」才可獲得賠償。然而,承審法院決定暫停訴訟程序,並將是否應有「最低損害門檻」以及其基準為何的問題,提交給歐盟法院進行先訴裁定。 歐盟法院考慮到,GDPR的宗旨在於確保在歐盟境內處理個人資料時對自然人提供一致和高水準的保護,如要求損害必須達到一定的嚴重性閾值或門檻才可賠償,恐因為成員國法院認定的基準不同,進而破壞各國實踐GDPR 的一致性。因此,歐盟法院最後澄清,GDPR的民事賠償不需要「最低損害門檻」,只要資料主體能證明受有損害,不論這個損害有多輕微,都應獲得賠償。
在英國種植基因改造作物可能無法可管英國衛報( The Guardian )指出,英國對種植基因改造作物之管制規範存在著漏洞。 1998 年歐盟曾經允許一批基因該造玉米在歐盟境內種植,將之列入歐盟的一般性種子目錄( the EU common catalogue of seeds ),該玉米由孟山都生技公司所研發,被稱為 MON 810 ;當時基因改造作物尚未受到大眾的注意,更未引起各國政府對基因改造作物的反省。對此,英國的環境食品農業事務部( Department for Environment, Food and Rural Affairs, Defra )指出對於這批歐盟所允許的基因改造作物,目前並沒有任何的規範可阻止其進口到英國境內,贊成或熱衷種植基因改造作物的人士,也可在不需通知主管機關或鄰近土地之所有人的情況下,合法種植自己希望的基因改造作物。農民只需在銷售或生產此種玉米時,遵守歐盟所頒佈之基因改造溯源與標示相關規則即可。對此,目前英國的環保團體與農民關心的焦點在於,英國目前並沒有區隔基因改造作物與非基因改造作物,及非基因改造作物受到污染時,計算賠償金範圍及數額等之規定,並呼籲英國政府重視此問題。
IEA報告對合乎能源效率的建築外殼提供政策建議 美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。