能源稅課徵 經濟部爭取三年緩衝

  財政部日前對外公布「能源稅條例」修正草案,由於課徵能源稅對產業的衝擊層面甚大,行政院最近邀集財經等部會及環保署協商「能源稅條例」草案。


  經濟部認為能源稅開徵應在能源價格合理化後再實施,且需採漸進式方式開徵,並主張應仿歐盟做法,給予業者至少二至三年的緩衝期,即
98 年之後再開徵。同時經濟部也建議參照歐美國家給予差別稅率,燃料油及煤炭能源稅,應給予工業部門較低稅率或免稅,以降低對產業的衝擊,否則製造業生產流程使用到煤及天然氣的業者都將受衝擊。另外,經濟部也應主張若要課徵能源稅,應同步取消平板玻璃、橡膠輪胎、電器及飲料等四類貨物稅及汽燃費,並取消空汙費與土汙費,以避免雙重課稅。


  能源稅的直接用意應是藉由租稅手段提高能源使用效益,間接才是充實國庫。我國許多能源相對便宜,以致部分中小企業在欠缺嚴謹工程管理的情況下,石油、水電等資源的使用或有浪費情形,因此祭出能源稅,重點應擺在提高能源使用的邊際效益,同時,政府亦應提出有效配套,以兼顧產業的國際競爭力。

相關連結
※ 能源稅課徵 經濟部爭取三年緩衝, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=479&no=64&tp=1 (最後瀏覽日:2026/05/07)
引註此篇文章
你可能還會想看
歐洲個人資料保護委員會發布數位服務法與一般資料保護規則相互影響指引

「歐洲資料保護委員會」(European Data Protection Board, EDPB)於2025年9月12日發布《數位服務法》(Digital Services Act, DSA)與《一般資料保護規則》(General Data Protection Regulation, GDPR)交互影響指引(Guidelines 3/2025 on the interplay between the DSA and the GDPR)。這份指引闡明中介服務提供者(intermediary service providers)於履行DSA義務時,應如何解釋與適用GDPR。 DSA與GDPR如何交互影響? 處理個人資料的中介服務提供者,依據處理個資的目的和方式或僅代表他人處理個資,會被歸屬於GDPR框架下的控制者或處理者。此時,DSA與GDPR產生法規適用的交互重疊,服務提供者需同時符合DSA與GDPR的要求。具體而言,DSA與GDPR產生交互影響的關鍵領域為以下: 1.非法內容檢測(Illegal content detection):DSA第7條鼓勵中介服務提供者主動進行自發性調查,或採取其他旨在偵測、識別及移除非法內容或使其無法存取的措施。指引提醒,中介服務提供者為此採取的自發性行動仍須遵守GDPR要求的處理合法性,而此時最可能援引的合法性依據為GDPR第6條第1項第f款「合法利益」(legitimate interests)。 2.通知與申訴等程序:DSA所規定設通報與處置機制及內部申訴系統,於運作過程中如涉及個資之蒐集與處理,應符GDPR之規範。服務提供者僅得蒐集履行該義務所必須之個人資料,並應確保通報機制不以通報人識別為強制要件。若為確認非法內容之性質或依法須揭露通報人身分者,應事前告知通報人。同時,DSA第20條與第23條所規範之申訴及帳號停權程序,均不得損及資料主體所享有之權利與救濟可能。 3.禁止誤導性設計模式(Deceptive design patterns):DSA第25條第1項規範,線上平台服務提供者不得以欺騙或操縱其服務接收者之方式,或以其他實質扭曲或損害其服務接收者作出自由且知情決定之能力之方式,設計、組織或營運其線上介面,但DSA第25條第2項則宣示,線上平台提供者之欺瞞性設計行為若已受GDPR規範時,不在第25條第1項之禁止範圍內。指引指出,於判斷該行為是否屬 GDPR 適用範圍時,應評估其是否涉及個人資料之處理,及該設計對資料主體行為之影響是否與資料處理相關。指引並以具體案例補充,區分屬於及不屬於 GDPR 適用之欺瞞性設計模式,以利實務適用。 4.廣告透明度要求:DSA第26條為線上平台提供者制定有關廣告透明度的規範,並禁止基於GDPR第9條之特別類別資料投放廣告,導引出平台必須揭露分析之參數要求,且平台服務提供者應提供處理個資的法律依據。 5.推薦系統:線上平台提供者得於其推薦系統(recommender systems)中使用使用者之個人資料,以個人化顯示內容之順序或顯著程度。然而,推薦系統涉及對個人資料之推論及組合,其準確性與透明度均引發指引的關切,同時亦伴隨大規模及/或敏感性個人資料處理所帶來之潛在風險。指引提醒,不能排除推薦系統透過向使用者呈現特定內容之行為,構成GDPR第22條第1項的「自動化決策」(automated decision-making),提供者於提供不同推薦選項時,應平等呈現各項選擇,不得以設計或行為誘導使用者選擇基於剖析之系統。使用者選擇非剖析選項期間,提供者不得繼續蒐集或處理個人資料以進行剖析。 6.未成年人保護:指引指出,為了符合DSA第28條第1項及第2項所要求於線上平台服務中實施適當且相稱的措施,確保未成年人享有高度的隱私、安全與保障,相關的資料處理得以GDPR第6條第1項第c款「履行法定義務」作為合法依據。 7.系統性風險管理:DSA第34與35條要求超大型在線平台和在線搜索引擎的提供商管理其服務的系統性風險,包括非法內容的傳播以及隱私和個人數據保護等基本權利的風險。而指引進一步提醒,GDPR第25條所設計及預設之資料保護,可能有助於解決這些服務中發現的系統性風險,並且如果確定系統性風險,根據GDPR,應執行資料保護影響評估。 EDPB與其他監管機關的後續? EDPB的新聞稿進一步指出,EDPB正在持續與其監管關機關合作,以釐清跨法規監理體系並確保個資保護保障之一致性。後續進一步的跨法域的指引,包含《數位市場法》(Digital Markets Act, DMA)、《人工智慧法》(Artificial Intelligence Act, AIA)與GDPR的相互影響指引,正在持續制定中,值得後續持續留意。

英國新聞申訴委員會首度網路影片違反隱私權爭議作成裁定

  英國新聞申訴委員會(The Press Complaints Commission,簡稱PCC)日前針對某報業網路上發布之影片寄出違反隱私權之處罰裁定,該影片為一位16歲之高中學生利用行動電話所拍攝,內容紀錄該學生就讀之班級學生於教室內脫序的上課狀況,該學生錄下脫序現象之目的在向自己父母解釋其數學成績不佳之原因,此一事件被英國報紙The Sun, The Daily Mirror and The Hamilton Advertiser報導出來並將該影片公布於網路。   該校「家長、老師會」(Parent Teacher Association)為此向英國新聞申訴委員會提出申訴,主張報社報導並於網路上公布該影片之行為,構成對於影片中學生之隱私權侵害,因為包括校方、學生以及學生家長皆未對影片播放表示同意。   PCC表示,學校的風紀問題已被認定與公共利益相關,而本案影片學校對於學生鬆散管理導致之脫序行為已經影響學生學習之表現,明顯屬於重要之公共利益事項。然而,該報社於報導此事件時,無論於報紙上之圖片以及網路上之影片皆未加以處理,尤其,網路上之影片有部分學生之身分可被明顯辨識,而新聞媒體具有確保學生隱私權不致於因出現鏡頭前而受到侵害之責,雖然依據該報社表示若將學生影像模糊處理將降低事件可能造成之影響,但學生隱私之保護將比新聞媒體呈現事件之利益更為重要,故裁定該報社違反新聞媒體工作規範中之隱私權保護規定。   PCC從今年(2007年)2月已開始對於報社所擁有之多媒體網路內容規範管理,而該規範並未排除大眾提出之資料,只要該資料為該報社可編輯掌控之範圍內,皆受到規範。

何謂「監理沙盒」?

  沙盒(Sandbox)是一個讓小孩可以安全遊玩與發揮創意的場所,在電腦科學領域,沙盒則是用來代稱一個封閉而安全的軟體測試環境。而監理沙盒(Regulatory Sandbox),則是在數位經濟時代,為因應各種新興科技與新商業模式的出現,解決現行法規與新興科技的落差,故透過設計一個風險可控管的實驗場域,提供給各種新興科技的新創業者測試其產品、服務以及商業模式的環境。   在監理沙盒當中,業者將暫時享有法規與相關責任的豁免,減低法規遵循風險,以使業者能夠盡可能地測試其技術、服務或商業模式。透過在測試過程中與監管者(通常為政府主管機關)的密切互動合作,針對在測試過程中所發現或產生的技術、監管或法規問題,一同找出可行的解決方案,並作為未來主管機關與立法者,修改或制定新興科技監管法規的方向跟參考。   監理沙盒一詞源自英國在2014年因應Fintech浪潮所推動的金融科技創新計畫,而類似的概念也出現在日本2014年修正產業競爭力強化法當中的灰色地帶消除制度與企業實證特例制度。我國則於2017年通過金融科技發展與創新實驗條例,為我國監理沙盒的首例,2018年我國持續推動世界首創的無人載具科技創新實驗條例立法,為我國建構更有利於產業創新的法制環境。

美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。

TOP