日本內閣官房所屬之健康‧醫療戰略室於2017年3月, 向國會提出《有助醫療領域研究開發之匿名加工醫療資訊法律案》(医療分野の研究開発に資するための匿名加工医療資訊に関する法律案)。「健康‧醫療戰略室」係於2013年2月成立,並於同年8月根據《健康‧醫療推進法》設置「健康‧醫療戰略推進本部」。該部於2017年3月10日提出《有助醫療領域研究開發之匿名加工醫療資訊法律案》,針對醫療資訊匿名加工業者進行規制,使他人可安心利用經過去識別化處理之資訊,以便促進健康、醫療方面之研究及產業發展,形成健康長壽社會。上開法案主要可分為兩個部份︰ 國家責任與義務︰政府應提出必要政策與制定基本方針。 匿名加工醫療資訊業者之認定︰該部份又可分為匿名加工醫療資訊業者(以下簡稱業者)之認定與醫療資訊處理。 針對上述第2點之認定,為確保資訊安全,政府應設置認定機構,以便確認業者符合一定基準,並具備足夠之匿名加工技術,可為醫療個資去識別化。此外,在醫療資訊處理方面,該法案則規定醫療機關可在事先告知本人,且本人未拒絕提供時,將醫療資訊提供給業者。
英國Ofcom公佈光纖網路備援電池之管制指引因預期超高速網路在英國將被廣泛佈建,Ofcom於2011年6月啟動諮詢程序,徵詢各界光纖網路備援電池的管制指引,以確保消費者的緊急電話服務;並於同年12月公佈諮詢結果與更新管制指引。 英國境內光纖到終端(FTTP)服務的覆蓋率已達到58%,雖得以提供消費者更高速的上網與影音內容,但卻有停電時無法運作的先天缺陷。由於傳統電話運作所需的電力係經由業者機房透過銅絞線供應,故即便消費者終端停電,仍能緊急電話。因此Ofcom曾於2009年要求公眾電話業者(PATS)確保消費者終端有維持供電4小時以上的備援電池,以保障民眾的身家安全。而此項管制則是納入ECN/ECS業者之第3項一般條件的管制中,業者有因而有遵守的義務。 此次徵詢結果,Ofcom確立了以下兩點管制指引: 1. PATS必須確保提供備援電池:PATS若由消費者選擇是否安裝備援電池,將被認為不符義務。若PATS選擇由消費者負擔更換電池之責任,應提供適切指引並確保易於取得電池;若責任由PATS承擔,則應建立適切處理程序。 2. 備援電池最低供電時數降為1小時:主要理由為英國大部分的斷電事件都不超過1小時;且行動電話相當普及,增加了安全保障。而備援電力降為1小時後,將使其電池更輕便和更易分離,因而更易於產製購買、取得與安裝。不過對於歷史上曾發生斷電超過1小時的家戶,PATS仍有義務確保較長時間的備援電力。
歐盟2019電子政府基準報告歐盟執委會(European Commission, EC)於2019年10月18日發布電子政府基準報告(eGovernment Benchmark 2019: trust in government is increasingly important for people)。電子政府基準是歐盟的年度檢測工具,用以確認公部門中資通訊技術使用狀況,亦是歐盟2016-2020年的重點政策之一:2016年4月,歐盟執委會發布「歐盟e政府四年行動計畫」(EU eGovernment Action Plan 2016-2020),歐盟應致力落實「公共行政現代化」、「跨境數位行動服務」和「加強公部門與公民和企業的數位互動」等三面向。電子政府基準報告即因應此一政策方向而生。 電子政府基準的評測指標有四:以使用者為中心(User centricity)、透明度(Transparency)、跨境移動(Cross-border mobility)、其他關鍵促成因素(Key enablers)。報告中評估2019年總體表現最佳的國家是馬爾他、奧地利等;立陶宛和芬蘭等國則為其次;表現低於平均者則多為東南歐國家。報告中亦提到,現階段公民已十分容易在機關官網上取得所需資訊,但相較於提供給一般公民的服務,機關官網對企業提供之服務通常更加完整及清楚。另外,在推行各項電子政府措施時,公民對政府的信任益發重要。唯有公民信任該機關,包含對機關安全在線服務、個人資料透明度、公共網路安全等的信賴,機關數位化改革才能常態運作。因此,電子政府的發展是建立在人們信任相關數位服務,並與政府交流時更容易知悉並利用該服務。 再觀我國電子化政府之發展,自民國87年至今已進入第五階段。初期致力建設政府骨幹網路和電子認證、90年代持續深化及擴大政府網路應用,並推動10大旗艦計畫實現網路政府主動、分眾、持續及紮根之服務。101年後建構電子化政府之設備、網路和應用服務,發展資訊服務系統整合、全程服務及跨部門協調。近期分別有「第五階段電子化政府計畫-數位政府」和「服務型政府推動計畫」,以資料驅動、公私協力、以民為本之核心理念,透過巨量資料、開放資料和服務個人化等工具,發展跨機關一站式整合服務及打造多元協作環境,落實數位政府服務。
開放原始碼撤出蘋果Safari?兩年前蘋果選擇開放原始碼成像引擎( rendering engine ) KHTML 做為 Safari 瀏覽器的基礎;兩年後,蘋果則打算以自己的程式碼取代該引擎,藉以解決相容性的問題。 KHTML 成像引擎──也是其瀏覽器的核心,考慮在其架構上放棄 KHTML 的程式庫( code base ),或者所謂的「樹狀圖」( tree ),改用蘋果自己的版本,也就是所謂的 WebCore (網頁核心)。 KHTML 原本是為了要在 KDE ( K Desktop Environment )上執行而撰寫的──這是 Linux 和 Unix 作業系統的介面。 Safari 並不是蘋果唯一以開放原始碼為基礎的軟體,其麥金塔( Macintosh )作業系統就是以達爾文( Darwin )開放原始碼計畫為基礎。 企業在某些方面受到限制,而開放原始碼社群以不受限制為傲。蘋果自己內部有些問題搞不定,以致銜接不上 KDE 開發 KHTML 的模式,導致 KHTML 與 Safari 逐漸產生分歧,後來情況則越來越嚴重。