加拿大反垃圾郵件法的施行可能衝擊電子商務產業
加拿大政府於2010年12月通過反垃圾郵件法，並將於2011年底前生效，加國訂定此法律目的在於藉由遏止垃圾郵件、身分盜用、網路釣魚、間諜軟體、病毒、殭屍網路及誤導性的商業表示等行為，建立新的規範機制與罰則，解決此類線上威脅，從而促進電子商務發展。
目前引發兩派看法，自電子商務角度以觀，企業經營者倚賴電子郵件與消費者互動，而新法要求企業經營者在發商業行銷郵件前須先獲得同意，且必須有明確的取消訂閱機制供收信人選擇。雖在交易過程中獲得的電子郵件地址，將被視為已默示同意發送信息，但只能於最後一次購買日期後兩年內發信，如此企業必須另外建立符合法令規定的郵件清單並加以管理，對企業經營者而言著實是一種負擔。且因為新法定有罰則，若違反法令，加拿大廣播及電訊管理委員會（Canadian Radio-television and Telecommunications Commission, CRTC）有權對個人處以最高100萬元的行政罰款，對公司最高罰款可達1,000萬元，如此使因業務需要而發送大量電子郵件的公司，包括電信公司、銀行等感到惶惶不安。同時另一方面有論者質疑此法律的執行成效，因大部分的垃圾郵件非自加拿大當地所發出，要如何達到減少並遏止前述線上威脅，效果存疑。
另一派見解則認為，在此法案通過前，加拿大是八大工業國中，唯一没有具體的垃圾郵件管理辦法的國家。雖然此法影響電子商務產業，然而知名企業也可能會濫發商業郵件，且縱使發送郵件公司並非在加拿大本地發送垃圾郵件，其未必在加拿大無分支機構，垃圾郵件確實對加拿大人民造成損害，因此制定並施行反垃圾郵件法是必要的。
歐洲法院(European Court of Justice)於2011年9月6日作出一項指標性的判決，係針對蜂蜜或食物補充品(Food Supplement)中，若其花粉成分受到基因改造作物之污染，則無論該污染是有意或無意所造成者，未經審核前均不得任意販售。據此，蜂蜜或食物補充品的生產者得就因不得販售所產生之損失向污染源或政府求償。 該案原為德國的養蜂人認為其生產之蜂蜜中的花粉受到鄰近距離五百公尺的基因改造農作物試驗之污染，而該試驗即為巴伐利亞政府所核准之基因改造農作物試驗(1998年EU核准的MON 801 maize)，故而對巴伐利亞政府提出求償。原德國法院在不能確定蜂蜜是否涵蓋在基因改造規範的情況下，轉而尋求歐洲法院的判決。 該判決等於是挑戰歐盟現有的對於傳統作物及基因改造作物共存的政策與法規(GMO, Co-Existence)，歐盟就該共存的門檻標準設定在0.9%，若產品含基因改造成分0.9%以上，需標示為基因改造產品，惟標示為基因改造食品對於傳統農作物之種植可能帶來銷售上的不利。而在共存門檻之下，含有基因改造成分的傳統農作物還是有可能因含有基因改造的成分而影響銷售並帶來損失；又因在共存門檻之下，作物含有基因改造成分是無法向政府或是來源求償的。另一方面，該判決亦影響出口蜂蜜至歐盟的國家，如大量生產蜂蜜且核准種植基因改造作物的阿根廷等國家。 對於基因改造食品採取保守態度的歐盟，近年來有意將是否禁止基因改造農作物以及共存門檻的比率下放給成員國自行決定，在成員國間形成兩極化的意見，而該項提案目前雖已經歐盟議會背書，但尚未由各成員國通過。這樣的判決令共存門檻的制度形同具文，且可能會使更多國家傾向禁止種植基因改造農作物，而不利於基因改造科技的研發。
美國最高法院在電影蠻牛案中釐清權利行使怠惰原則之適用美國最高法於近日判決電影編劇Frank Petrella之女得對電影公司MGM對其父親於1963年以世界中量級拳王Jake LaMotta生平創作的劇本蠻牛（Raging Bull）持續性的商業利用行為提出侵權訴訟。 本案緣起於在美國著作權法下，1978年以前發表的著作受到28年的著作權保護，並得於到期後延展保護67年，而若作者在延展之前死亡亦即本案情形，著作受讓人僅得於繼承人移轉延展權的情況下繼續使用，而著作權法507(b)規定民事賠償請求需於侵權行為發生後的三年內提出。 原告編劇Frank Petrella之女於2009年向MGM提出2006年後侵權行為之賠償，MGM則以法律不保護權利怠於行使之人（thedoctrine of laches）作為抗辯，主張原告不得起訴。地方法院及第九巡迴上訴法院皆贊同被告MGM之主張，認為原告於1991年延展著作權保護時即知悉，此舉對MGM並不合理且帶有偏見。 最高法院近日推翻下級法院的看法，認為權利行使怠惰並不阻卻權利人對請求權時效內發生的侵權行為提出訴訟，同時更進一步釐清著作權法507(b)允許權利人評估值得尋求訴訟救濟的時間點，除非權利人刻意誤導第三人不會對其起訴，而這是禁反言原則（thedoctrine of estoppel）的問題，本案下級法院顯然混淆了二者之區別，從而肯定原告有權向MGM請求著作權侵害之損害賠償。
手機軟體（APP）辨識來電號碼之法律問題手機軟體（APP）辨識來電號碼之法律問題 科技法律研究所 102年03月25日 壹、事件摘要 我國自2005年開始推展行動電話「號碼可攜」服務，允許使用者將行動電話號碼申請移轉至另一業者。當號碼進行移轉時，為降低通話路由資訊傳遞之延遲、避免業者間轉換作業之延宕，通傳會指導各業者共同建立集中式資料庫，整合業者號碼管理資源，增進號碼可攜服務之效率。 日前有某非屬電信事業之業者，設計一款應用軟體，提供智慧型手機使用者下載、安裝後，可自行上傳通訊錄內之電話號碼，並透過電信事業之「號碼可攜集中式資料庫」，確認並辨識通訊錄內電話號碼所屬電信業者，將資訊回傳於使用者之智慧型手機。由於電話號碼屬於使用者個人資料之一環，本文以下分析「非電信事業與電信事業合作，於號碼可攜目的外，對資料庫內之資料進行蒐集、處理與利用是否違反個資法」之疑義。 貳、重點說明 「號碼可攜集中式資料庫」之設立主要目的在使不同業者間能準確的完成通訊的連接。然而，通傳會於96年10月亦有要求各電信業者設置查詢系統，提供用戶查詢欲致電之受話方是否係屬同家業者，進而協助用戶瞭解可能之通訊資費計算。換言之，通傳會認為辨識電信號碼屬於網內/外，屬於消費者規劃、理解其電信資費之權益。而目前亦有手機軟體可輔助消費者查詢相關資訊。 那麼，可否允許消費者進一步查詢致電對象所屬的業者呢？是否違反個人資料保護法的規定呢？ 如前所述，通傳會認為使消費者瞭解電信號碼屬於網內/外，有助於資費理解之權益。我們更進一步說，允許查詢號碼所屬門號，不僅消費者可知悉資費之數額計算以決定是否致電，尚可決定是否使用相同電信業者之服務來打電話。我國行動電話普及率早已超過120%，有相當比例之消費者擁有二個以上之門號，若可揭露致電號碼所屬電信業者，使消費者可刻意選擇以網內門號致電，無疑具有相當實益。因此我們認為電信業者提供消費者以手機軟體查詢門號所屬業者，並不違反個資法上針對電信服務規範之「特定目的」（第133項：經營電信業務與電信加值網路業務）。一般的行動電話用戶，可透過電信業者查詢其所致電對象之門號所屬業者，則居於輔助地位的APP軟體，與用戶直接向業者查詢相比，實則無任何不同，應視為用戶之合理行為。 參、事件評析 個資法修正後，對於個人資料之保護更加的完善，但科技之發展使得個人資料之利用呈現多樣性，難以釐清某些利用行為是好是壞，然而本文基於鼓勵科技發展以及創新研發的立場，當面對某些個資利用情狀產生疑義時，應加以釐清其運用之情狀，避免在情境不明時，過度的擴張個資保護的界線，對市場發展以及消費者權益而言，並非好事。 當然另一方面而言，濫用科技便利的情形是存在的，如同2012年12月甫結束之ITU國際電信大會（WCIT2012），多國所簽署之修正電信管制規則第5B條所示，要求各國應努力採取必要措施，防止未經許可之濫發電子訊息，以減少對國際電信業務之影響。由於網路無遠弗屆，具騷擾性、浮濫發送之訊息，已從早期之垃圾電子郵件，擴及網路即時通訊軟體，不但時常造成使用者之困擾，甚至造成詐騙橫行。而這些狀況，光依靠個資法也是不足的，尚須主管機關對於濫用電信資源加以管制，從個人資料與電信資源等層面多管其下，方能維護良好之產業環境。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。