以往許多新創公司或行銷業者會將影片上傳YouTube後，加上連結以導引用戶到其眾籌或活動網頁。但YouTube近日新增規定，增加此類行為的限制。
 
新規定要求頻道主必須加入YouTube合作夥伴計畫，才能在資訊卡（end card）中加入相關網站、眾籌網站或電商網站，以便Google可以評估頻道的有效性，並判斷頻道是否有遵循YouTube的社群規範。
 
此舉引發使用者嘩然，因為這意謂著只有總公開閱覽次數超過1萬次，且經過YouTube同意者才可以在影片結尾加入連結。並有使用者轉貼螢幕截圖，顯示頻道主必須啟動廣告分潤，即有YouTube廣告者才能增加外部連結。
 
但YouTube方面表示此舉旨在減少資訊卡的濫用，並不會影響YouTube合作夥伴或現有資訊卡的使用，YouTube並強調頻道上任何影片都無需啟動分潤。

從近年跨國商業電子郵件詐騙案來看，冒充老闆、通知變更匯款等手法，儼然成為一種利用人性弱點的熱門騙技，只要伺機竄改、入侵電子郵件，就能夠讓企業不疑有他，並主動匯款至詐騙用帳戶。

從大多數的BEC詐騙過程來看，不少都是駭客假冒海外以要求企業付款，或假冒公司高層的郵件帳號，要求掌管財物的收信者，匯款到詐騙用帳戶。

當款項匯出國外後，卻發現供應商、執行長說不是他本人所寄的！報案後，才知道被騙。因為大部分受害者在受害過程中，並未能夠意識到發生什麼事。

攔阻遭詐騙款項的關鍵，在於企業能否及早處理

遭受商業電子郵件詐騙，有辦法追回款項嗎？許多企業都想知道答案。

內政部警政署刑事警察局國際刑警科偵查第二隊隊長林岳賢表示，他們過去已經受理不少企業報案，也提醒民眾，並不是完全沒有追回款項的機會。通常受理報案時，執法機關可協助迅速追蹤匯款流向，幫企業爭取時間，如果有管道的話，至少可以將錢先凍結下來。

雖然跨國犯罪偵查有其複雜性，但林岳賢指出，只要企業越早發現並報案，攔阻匯款的機會就越大。像是在今年6月，臺南一間傳產公司也遭遇電子郵件詐騙事件，並匯款至境外，在報案與緊急處理後，即成功攔阻匯款。

刑事警察局國際刑警科偵查員郭蒨穎也進一步說明，在這起事件中，該企業在匯出20多萬美元到美國後，幸好他們隔天就發現問題，並立即報案，國際刑警科便根據處理經驗建議該公司，首先趕快去銀行辦理退匯，同時，透過駐美警察聯絡官協助與當地銀行法務聯繫，並將案發相關資料同步發送。最終，匯入銀行方拒絕接受匯款，讓款項退回原本的匯出帳戶。

清查影響範圍，避免企業繼續處於駭客所能掌握的範圍之中

若是企業真的不幸遭遇電子郵件詐騙事件，林岳賢表示，企業可就近前往一般派出所報案，或洽詢165反詐騙諮詢中心，這類跨國詐騙案件，都會轉到國際刑警科處理，過去也有企業是直接到刑事警察局報案。

但他也提醒，不少受理案件都是事發一兩個月，才來報案，時間拖太久。例如，有不少案件一開始是懷疑有內鬼，或是想告對方廠商詐騙，兩邊爭執完才來報案。要知道，時間拖得越長，一旦匯出款項被提領，或再次被轉匯出去，警方偵辦追回機率幾乎是零。

另一方面，企業IT單位該做的就是要清查影響範圍，或是透過執法單位與資安專家進一步協助，避免企業持續暴露在駭客監控之下。

根據不少資安公司統計，一般APT攻擊，臺灣企業平均遭駭客入侵潛伏的時間長達數百天，而BEC詐騙也有同樣的跡象，從事前鎖定目標，到潛伏觀察，再到關鍵時刻假冒客戶變更匯款通知，已經滲透一段時間。因此，清查影響範圍並做出調整，也是必要的動作。

攔阻遭BEC詐騙匯款，從執法單位、銀行等雙重管道下手

國際刑警科表示，這類電子郵件詐騙案件屬跨國網路詐騙，在偵辦有兩個面向，但也各有難處。像是在網路追查上，由於駭客端使用網路跳板、虛擬IP、一次性電子信箱等因素，追查曠日廢時、難收實效。

在金流追查上，包含人頭帳戶、網路轉匯及多方貿易等狀況，還有各國法令不一的問題。如從金流動向來看又可分為兩大類，一類是金流匯至境內，另一類則是匯至境外。

前者通常是，與臺灣廠商合作的國外廠商被騙，由於電子郵件詐欺案的收款地區在臺灣，因此國內偵辦時比較容易施力；後者則大多是臺灣廠商被騙，金流匯往境外，多需當地國家法院裁定，始能凍結帳戶，且若款項已經再轉匯至其他帳戶，追查難度增加，又或涉及多方貿易，亦難舉證受款帳戶涉案情形。

不過，也有例外，我們得知有企業自行討回詐騙款項的經驗，受害企業是向當地銀行或當地金管會申訴才追回。

林岳賢表示，在他們協助的經驗中，假設這筆錢匯至美國，而報案公司在當地有分公司，他們建議企業透過在地關係來處理，因為此類案件要搶時間，所以會先建議向當局先報案，如此一來，反而比從臺灣進行的程序要快。

郭蒨穎也補充，最好方式是透過執法單位與銀行，採同步進行方式處理。可能有些廠商認為是自行向銀行申請退匯成功，誤以為警方沒有處理，事實上，刑事警察局一定會透過管道，聯繫當地警方，他們也將協助與受款銀行洽詢。

然而，企業的需求不僅止於此，也許還會希望偵辦進度更透明，或是更容易查詢處理狀況，因此，我們也期待，接下來，警民之間能有更密切的合作。

另外，刑事警察局科技研發科股長羅國良提到，過去有企業遭遇BEC詐騙，而且是與銀行、以及資安公司合作、成功通報攔阻的例子。不論如何，面對防不勝防的跨國電郵詐騙，執法單位、金融與資安業者，都在打擊網路犯罪扮演各自不同的角色，企業與民眾也期盼能發會更好的效果。當然企業也要積極預防，畢竟是公司本身疏於資安保護及交易匯款確認，事後搶救也只是權宜之計，應設法避免遭詐騙才是根本之道。

緊急處理BEC詐騙匯出款項的3大通報處理步驟

Wired本周揭露，前Google員工且正被官司纏身的Anthony Levandowski 於兩年前建立了一個非營利的宗教組織「未來之路」（Way of the Future），該組織崇拜的對象是人工智慧（Artificial Intelligence，AI）。

「未來之路」的教義是：發展與促進基於人工智慧的神祇的實現，藉由對此一神祇的理解與崇拜，為改善社會作出貢獻。

外界對此一教義的解讀是，「未來之路」所信奉的對象也許是個機器人，但此一基於人工智慧的機器人將超越人類智慧，反替人類解決各種精神上的難題。

Levandowski同時擔任「未來之路」的總裁與執行長，雖然此一教派在2015年就成立，但迄今未曾提交美國國稅局針對宗教組織所要求的文件，不確定他究竟是不是認真的。

現年37歲的Levandowski畢業於加州大學的柏克萊分校，擁有工業工程與經營研究的碩士學位，他在2007年加入Google，為Google自動駕駛車專案Waymo的創辦人之一，繼於2016年離開Google，與友人共同創立了專門開發自動駕駛卡車的Otto，同年再被Uber延攬，主導Uber的自駕車研發部門。

然而，Waymo在今年2月控告Levandowski在離職時取走了該公司的機密文件與商業秘密，涵蓋產品藍圖、設計檔案與測試文件，法官在5月判決Levandowski不得於Otto從事相關研究，也要求Uber公布與Levandowski在特定技術上的討論內容，同月Levandowski即遭Uber開除。

不管「未來之路」是否會壯大，以色列歷史學家Yuval Noah Harari認為，不同時代背景的人們所信仰的神祇或想望的天堂並不一樣，21世紀的創新技術更有可能產生前所未有的宗教運動，而非復興中世紀的信仰；宗教必須跟上技術的腳步，否則這些宗教就會變得不著邊際，無法理解或回應信徒所面臨的苦難。

iOS 開放app存取資訊的權限機制爆出隱私外洩疑慮，可以讓惡意app得以存取整個相片圖庫及照片metadata，使用戶的行蹤、工作地點等被完全掌握。
 
Google收購的Fastlane Tools創辦人Felix Krause首先發現了這個iOS app權限（permission）設計問題。他解釋，iOS的app權限設計，並未區分選擇相片以及編輯相片/圖片的app，兩者是綁在一起的。因此只要使用者同意一次後，不同app就同時取得存取權限。
 
因此只要某個惡意app以選擇相片之名，騙取使用者同意存取照片圖庫後，暗中就可存取手機內所有相片，抓取相片的EXIF metadata。而EXIF metadata包含了相當豐富的資訊，像是拍攝地點的GPS座標、速度，拍攝時間、日期及相機機型等。
 
這麼一來，攻擊者可以把使用者的身家背景完全看透，像是他旅行的地方、工作地點、使用的裝置、通勤路徑、甚至經由他出入地點判斷他的社交或婚姻狀態等。研究人員已將該問題通報蘋果。
 
Krause寫了一個概念驗證的iOS app DetectLocations，號稱可蒐集使用者相片metadata，並可將相片記錄在地圖上，沒想到竟然還通過App Store的審核而上架。

根據外電報導，俄羅斯首都莫斯科最近開始於城市中的16萬台監視器上部署人臉辨識系統，且迄今已根據該系統逮捕6名在逃嫌犯。

莫斯科市的監視器部署頗為密集，這16萬台監視器覆蓋了該市95%的大樓入口，然而，這些監視器一次可儲存5天的監控影片，執法機構根本無從消化大量的監視內容，因而決定求助於人工智慧。

莫斯科所採用的是當地新創業者NTechLab所開發的人臉辨識系統，NTechLab曾於去年發表一FindFace行動程式，只要拍下街上的陌生人，就能將照片與俄國最大社交網站VKontakte上的個人檔案比對。

由於部署成本的原故，迄今莫斯科一次只會在數千台監視器上啟用人臉辨識機制，但隨時可切換啟用範圍，例如鎖定犯罪頻繁的區域，或是監控特定嫌犯經常出入的場合，還能追蹤嫌犯的路徑。

儘管充斥著監視器的城市讓人們感到毫無隱私，但莫斯科資訊科技部門的資訊長Artem Ermolaev表示，該系統並不會追蹤每一個人，如果你的照片沒有在警方的資料庫裡，那麼監視器只會帶來好處，讓這個城市更加安全。

Google與蘋果本周相繼公布了今年上半年的透明度報告，揭露全球政府向業者調閱民眾資料的現況，其中，Google的數據顯示，該公司收到了48941筆的政府調閱請求，涉及83345名Google用戶，在政府調閱筆數上再度刷新了紀錄，政府的調閱請求比去年同期多出了4000筆，也比去年下半年多出3400筆。

Google的透明度報告揭露了來自131個國家的政府調閱資料請求，可能是來自政府機關、法院，或是訴訟案的關係人，當Google收到調閱請求時，會先判斷這些調閱是否合法或合理，今年上半年Google同意提供資料的比例為65%。

從全球平均來看，台灣政府向Google調閱個人資料的筆數並不多，今年上半年台灣政府向Google提出190筆的調閱申請，查看261名Google用戶資料，Google遵循的比例為51%。雖然調閱筆數高於2015與2016年，但低於2011至2014年。

至於蘋果則將全球政府的資料調閱分成十多種類別，包含調閱裝置與調閱帳號等。其中，調閱裝置通常是需要蘋果協助定位遺失或遭竊的裝置，或是確定裝置的主人，以及使用某些蘋果服務的裝置；帳號部份則多半是執法機構正在調查非法使用的蘋果帳號，要求蘋果提供用戶的個人資訊，有時還會索取用戶的iCloud內容。

今年上半年，全球政府向蘋果調閱裝置資訊的筆數為30814筆，涉及233052個裝置，蘋果遵循政府調閱裝置資訊的比例為77%。

蘋果揭露亞洲地區政府要求調閱資料的統計，其中，台灣的調閱筆數為59筆，涉及130個裝置。(下圖為部份截圖，來源：Apple)

而全球政府向蘋果調閱帳號資訊的筆數則是3020筆，涉及43836個帳號，蘋果的平均遵循比例為80%。其中，台灣政府的調閱數為98筆，涉及278個蘋果帳號。有趣的是，中國雖然只提出24筆的調閱請求，但所調閱的帳號卻多達35491個，佔全球帳號調閱總數的81%，蘋果的遵循比例則為96%。

Google網域名稱註冊服務Google Domains本周宣布，將漸次把手上的45個頂級網域名稱加入HSTS（HTTP Strict Transport Security）預載名單，未來造訪這些網域的瀏覽器都會自動選擇HTTPS傳輸。

HSTS為一HTTP的強制安全技術，可強制瀏覽器透過HTTPS加密連線與網站進行通訊，預防中間人攻擊，而Google打造了HSTS Preload List開源專案，這是一份供瀏覽器使用的HSTS預載名單，舉凡瀏覽器造訪名單上的網址都會優先選用HTTPS連結，例如當使用者輸入http://gmail.com時，瀏覽器會將它改成https://gmail.com。包括Chrome、Firefox、Safari、IE或Microsoft Edge或Opera都內建了該名單。

不過，該名單最初是由不同的網址所組成，Google先是在2015年把.google預級網域名稱（ top-level domains，TLDs）納入該名單，只要是造訪.google的任何網站，瀏覽器都會優先選擇HTTPS連線，現在Google決定新的TLDs也將比照辦理。

目前Google Domains負責經營45個頂級網域名稱，包含.eat、.dad、.how、.mov、.new、.app、.zip、.foo及.dev等，Google打算先將.foo及.dev納入HSTS Preload List中。

Google軟體工程師Ben McIlwain解釋，使用TLD等級的HSTS將替這些網域名稱帶來基本的安全保障，申請人只要選用安全的TLDs再加上SSL憑證的配置就能確保連線安全，不必自行將網址提交至HSTS Preload List，此外，提交申請到觸及大多數使用者通常需要好幾個月的時間，Google的作法將更有效率。

McIlwain表示，除了把TLDs加進HSTS Preload List之外，Google Domains也將陸續開放使用者註冊這些更為安全的頂級網域名稱。雖然Google Domains網域名稱註冊服務於2014年便已發表，但迄今仍為測試版狀態。

麻省理工學院（MIT）的CSAIL實驗室在今年9月舉行的計算機協會研討會中發表了 CodeCarbonCopy系統，它能夠協助軟體開發人員將軟體中的一段程式碼自動移植到另一個軟體，將可大幅簡化程式撰寫流程。

透過CodeCarbonCopy，開發人員可先選擇A軟體的一段程式碼，再選擇B軟體的插入點，系統就能自動進行必要的變更，如改變參數名稱，以把程式碼妥善地植入B軟體中。此外，CodeCarbonCopy還能夠轉換A軟體與B軟體的資料表現方法，以讓程式碼得以無縫轉移。

該研究的第一作者Stelios Sidiroglou-Douskos表示，CodeCarbonCopy可說是軟體工程的聖杯之一，這是讓人類遠離開發周期，邁入自動化的另一步，他們的想法是，也許大家早就寫好了軟體所需要的大部份程式，現在只需要再利用。

在移植程式碼時，CodeCarbonCopy還能執行靜態分析，移除在A軟體中必要但在B軟體中毫無作用的功能。

研究人員已於6款開放源碼影像處理軟體中進行8次的程式碼轉移測試，其中有7次是成功的。這些軟體為MPlayer、VLC、mtPaint、cwebp、bmp2tiff與ViewNIOR。

Cornell Tech電腦科學教授Vitaly Shmatikov指出，程式碼移植可能是許多軟體出現問題的根源，也許只是一個小差錯就會造成臭蟲或安全漏洞，因此能有自動化的移植工具是非常值得期待的。

不過，CSAIL實驗室目前仍在優化CodeCarbonCopy，尚未公開釋出該系統。

Google本周四（9/28）發布Google Compute Engine開始支援巢狀虛擬化應用（Nested Virtualization），允許用戶能夠在一個或多個虛擬化環境中，再建立一層虛擬化環境。目前，巢狀虛擬化功能在測試階段（Beta）。

巢狀虛擬化應用能讓使用者在Linux虛擬機器（VM）中再執行一個或多個虛擬機器，且支援Intel硬體虛擬化技術Intel VT-x，以加強VM的效能。

巢狀虛擬化應用架構圖：

（圖片來源／Google）

根據Google的說明，巢狀虛擬化功能讓企業用戶能夠更容易搬遷本地端（On-Premises）和虛擬環境的工作量至雲端，且不需要匯入和轉換VM的映像檔。

Google表示，若需要在多重環境中驗證軟體的開發/測試和持續整合/持續部署（CI/ CD）工作，都適合使用巢狀虛擬化功能。

另外，巢狀虛擬化功能支援各種類型的Compute Engine VM，包含預先設定的VM、客製化VM和先佔式VM（Preemptible VM），只要是支援Intel Haswell版本以上CPU架構的VM，皆能使用巢狀虛擬化功能。

除此之外，目前Compute Engine的巢狀虛擬化功能僅支援KVM Hypervisor平臺。

美國串流裝置製造商龍頭Roku於本周四（9/28）以每股14美元的發行價正式登上那斯達克（Nasdaq）股市，上市首日即上漲了67.86%，以23.5美元作收，享受蜜月行情。

Roku主要生產各種規格不一的媒體串流裝置，從最低階的Roku Express（24.99美元），到最高階、支援4K與HDR的Roku Ultra（99.99美元），還有自24吋到65吋不等的智慧電視Roku TV，硬體銷售約佔Roku總營收的6成，其它營收則來自於廣告、訂閱與平台授權。

儘管身為美國市場最大的串流裝置製造商，擊敗Google的Chromcast、Amazon的Fire TV與蘋果的Apple TV，但目前Roku仍是虧損的。

Roku在去年創下3.98億美元的營收，虧損4280萬美元，今年上半年的營收為1.99億美元，亦有2420萬美元的赤字。

根據外電報導，Roku高層與華爾街分析師已取得共識，認為Roku的未來無法光靠硬體支撐，將會大力拓展軟體服務以創造獲利。

根據Gartner近日公布一項報告中預測，2018年全球超過20億的人，會經常用對話的方式，與AI語音個人助理互動，到了2020年則是有40%的使用者，是用對話介面的App為主，25%的家庭擁有一個語音助理裝置後，後持續購入2個以上的語音助理裝置。

「對話的互動模式變得越來越重要！」Gartner個人技術研究部研究總監Adrian Lee表示，使用者的習慣已經逐漸改變，在今年更是可以看到明顯的轉變，去年Google、臉書的Chatbot，以及Amazon Alexa的興起，促成使用者大量由App，轉而使用Chatbot。

以Amazon Echo為例，根據市場研究機構Statista調查，美國32%的Amazon Echo使用者已經有透過Alexa購買商品，且使用者購入Amazon Echo後，在Amazon上的消費增加了大約10%，Adrian Lee認為，開發Chatbot對電商業者已經是不容忽視的任務。

不過，Chatbot是否只有像是Amazon或是阿里巴巴等電商龍頭才能開發？Adrian Lee認為，現在市面上有許多Chatbot平臺供應商，提供相關的平臺和工具，給企業自行開發，將開發Chatbot入門門檻降低了，Chatbot不再是大型電商業者的專利，就連小型電商也能做。

現在，電商業者面臨的問題，並非要不要開發自家的Chatbot，而是什麼時候要開發，他甚至大膽地說，「現在再不做就太遲了！」由於使用者的習慣已經轉變，若是電商業者沒有提供Chatbot的通道，將會逐漸失去競爭力。

他指出，電子商務產業的營收是由流量（Traffic）、轉換（Conversion）和平均售價（ASP）組成，流量就是指電商業者在數位行銷的策略上，如何將使擁者吸引到自家平臺消費，他認為，目前的電商業者，在流量方面的策略都算成熟，並不是太大的問題。

但是電商業者在轉換層面，就有明顯的差距，轉換即是電商與消費者的互動介面，他認為，使用者介面和使用者體驗的設計，相當重要，將會成為消費者最後願意消費的關鍵，而對話互動就是新興的趨勢。

「與客戶互動的第一時間是關鍵！」Adrian Lee表示，客戶體驗對企業來說是最重要的，尤其是與客戶互動的第一時間，如果第一次的互動體驗，給予客戶不好的印象，客戶就再也不會回來消費，電商業者將會永遠失去這位客戶。

他舉例，Amazon剛在新加坡推出2小時內送貨服務Prime Now時造成轟動，他也興奮地到網站上要訂貨，沒想到能夠預定商品的時間卻至少要4天後，於是，他轉而到其他電商平臺購買，後來也因此很少再回去該平臺消費。

對話的互動模式，對消費者而言，使用上更加方便，傳統的網頁訂購模式，使用者在不同的電商平臺都需要重新學習如何操作，但是對話的方式則打破了這樣的限制，此外，對話的模式，還增加了電商業者的銷售機會，舉例來說，若是使用者在家說「電池又沒電了」，Alexa則會詢問使用者，是否需要訂購電池，Chatbot提供更多的銷售場景，也更直接、更貼近使用者的需求。

最後，平均售價（ASP）則是電商業者制定商品的定價、與其他廠商合作策略等，電商業者要成功地創造營收，流量、轉換和平均售價的策略，都必須面面俱到，而Chatbot正是可以創造出差異，提升競爭力的重要策略，他也提醒，電商業者開發Chatbot，要對自家的消費者非常了解，才能提供客戶更好的使用者體驗。

Chatbot除了提供電商額外的銷售管道，也更貼近使用者的行為之外，Chatbot內的AI技術，也能夠提供電商業者額外的價值，Adrian Lee指出，AI技術需要具備自學能力、有預測性，以及提供出其不意的分析結果3大功能，有了AI技術的輔助，電商收集到的數據，能夠自動分析預測消費者喜好，甚至，提供非典型的分析結論，創造更多商機。

Gartner指出，未來電商業者將會轉型成以客戶對話體驗為主，來設計購物體驗，由系統主動詢問消費者要購買的商品，甚至還會推薦其他類似商品選項，提供消費者多種選擇，大幅減少訂購商品的流程。

（圖片來源／Gartner）

電商產業轉型，AI不可或缺

以往，電商業者是以客戶生命周期為主，客戶在未購買商品的階段，只能自行透過查詢來訂購，訂購的過程也需要填寫繁複的寄送資訊、付費方式等欄位，最後才能完成訂購，追蹤貨物的寄送狀況也要消費者自行查詢，最後消費者收到商品，電商業者只能透過滿意度調查或是消費者的再回購率，來了解消費者的下一次消費傾向。

現在電商業者則是以使用者體驗為導向來設計整套購物流程，使用者可以用關鍵字搜尋商品，系統也會呈現建相關的議購買商品，訂購商品所需要填寫的資訊，也有清單或是既定的項目提供選擇，省去大半自己撰寫的時間，系統還會自動記錄資訊，使用者下一次購物就不需要重新填寫，最後，訂購完成會透過簡訊或是電子郵件，通知使用者商品的寄送進度，填寫商品的評價，也是變得更加方便。

未來，Adrian Lee表示，電商業者將會轉型成以客戶對話體驗為主，來設計購物流程，除了從電腦、智慧型手機裝置與消費者互動，還加入IoT裝置，像是Amazon Echo或是Google Home，消費者購買商品前，從過去要自己查詢，轉為由系統主動發問，消費者要購買的商品，還會推薦其他類似的商品，提供消費多種選擇，訂購的過程所需的資訊，也會用對話的方式詢問，不需要消費者一一填寫，大幅減少訂購商品的流程，消費者也不需要學習每個電商平臺的操作方式，直接用自己的表達方式，就能完成訂購。

電商業者開發對話式AI平臺的4個策略

Gartner從電商的業務成熟度和創新程度，將電商業者可以導入對話式AI平臺的策略，分為4種，第一種適合剛起步的電商業者，商業模式以穩定為主，Adrian Lee建議，企業能在現有的商品和商業模式下，加入AI技術，像是加入預測建議和通知等功能；第二種則是在既有的商品中，加入新的商業模式，例如，創造虛擬客服助理增加商機，或是與AI相關的企業合作，推出個人化的購物服務，他認為，這種策略較適合開始拓展新商業模式的企業，能夠承擔較多的風險。

營運成熟且商業模式穩定的電商業者則是可以採取第三種策略，借助既有的商業模式推出新產品，像是在家庭智慧設備或是個人裝置中，加入有AI技術的App或是服務。最後則是商業模式成熟且力求創新的企業，就能大膽推出新的產品，創造新的商業模式，舉例來說，可以用B2B的模式，開發新的解決方案提供給其他廠商，或是更進一步成為新技術的供應商。

對話式AI平臺架構和功能

對於對話式AI平臺的架構，Gartner畫分為必備和選擇性的功能元件，基本的必備功能，包含使用者的介面、處理（Processing）、分析（Handling）和生成結果，可選擇性加入的功能，包含理解對話內容、例外處理、整合、分析和管理。

使用者介面是收集語音和對話的資料通道，原始資料經由處理後再分析，最後產生回覆，回傳給使用者。進階的對話式AI平臺則可以辨識使用者對話的內文，若有不在規則內的問題，也有設計相對應的解決方案，甚至能夠管理對話。

接著，Gartner將上述的每個功能，再細分成不同的元件，使用者介面可分為客戶的使用介面、對話平臺（Messaging Platform）、語音和多種模式，理解語意的部分包含使用者喜好、對話記錄、對話上下文等，甚至，還要整合第三方資料，處理階段則是需要自然語言處理和分析使用者意圖。

分析則需要決策樹、知識萃取等功能，而整合的部分包含與其他平臺的介接，例外的處理則是在系統無法處理時，自動轉接不同模式，像是直接轉到真人服務，最後分析與管理則是要透過分析結果，提供建議的改善方向。

大學為歷史系背景的勞動部勞工保險局（簡稱勞保局）資訊室主任梁海珠，畢業後隨即加入了勞保局，從事應用程式的開發、維護等基層工作。或許是受歷史學科的薰陶，在她談及勞保局資訊室過往各項IT專案的導入、建置過程，就像對歷史事件般瞭若指掌，往往可以清楚點出該項計畫推動的年分，甚至細至月分。勞保局在1974年導入電子化作業後的3年隨即加入資訊室，深耕於此40年的梁海珠，可說她幾乎完整見證勞保局資訊化的演進史。

勞保局的資訊化可以追溯至1974年，當年成立的電子處理資料工作小組。早期是由臺灣電腦、IBM等廠商委外建置維護、建置系統，直到1985年初，才開始採買硬體設備自建機房。勞保局跟健保署兩大單位就掌管臺灣民眾絕大多數相關的保險業務，除了健保外，其他保險，像是勞工保險（勞保）、就業保險（就保）、勞退（勞工退休保金）、國民年金保險（國保）、農保（農民保險）等全部都集中在勞保局。

梁海珠表示，目前勞保局服務的被保險人數高達1,500萬人，每月發放之各項年金或津貼也多達300萬人，服務範疇除軍公教人員外，與每個人的工作及生活都息息相關，「無論是否為勞工身分，都是勞保局服務的對象，提供民眾從出生到死亡的保障。」

「雖然都是保險，但每個業務性質又都不一」，梁海珠表示，每個保險中的條文、施行細則都不一樣，但是彼此間又有所關聯。例如，勞保會根據被險人的投保年資，計算所得替代率後以年金給付。而以日計算的勞保除了要以書面形式申請外，透過網路申報的單位，也允許追溯申請。

而相比勞保、農保、就保這些需要申請加保的業務，只要年齡超過25歲，未滿65歲的民眾，只要曾經領過勞保老年給付、公保養老給付或軍保退伍給付，在沒有參加勞保、農保、公保或軍保的期間，都要參加國保。

而勞保局資訊室的挑戰，除了這些複雜的保險條文外，「新法律、政令一旦通過，就會對資訊室產生非常大的影響」，梁海珠舉例，像是國保在2007年經立法院三讀通過之後，1年之內就必須實施。而資訊單位必須在1年內，完成編制預算、採購機器以及系統建置的任務。因應這樣的壓力，勞保局資訊室可不能在法案確定通過後，才開始著手開發。梁海珠表示，當法案還位在草案階段時，資訊室就得開始準備系統分析、設計工作，「當確定法案不會有大幅度的更動，我們就會著手開發。」

她表示，如果該修法會導致系統架構的變革，資訊單位也會強力爭取實施的緩衝期，「不可能公告實施後，系統隨即就上線」，像是國保在立法後到正式實施間，原先預計農保也要納入國保中，但是後來立法單位決議取消。但一波未平，一波又起，後來國保更從以月計費，改成以日計費，「甚至得額外採購設備才能應付。」

勞動部勞工保險局資訊室主任梁海珠表示，資安永遠與便利性存在衝突，推行GCB資安設定雖會增加IT管理工作，但得徹底落實。（攝影／洪政偉）

開發通用元件IT才會快

目前，勞保局所維護的核心系統就有40個，像是勞保、國保、承保及欠費等系統，「每個系統都是環環相扣的」，梁海珠舉例，像是每個月都會執行開單作業的保費系統，結算保費之後，會將資料傳送至財務系統沖銷。如果該員不繳費的話，欠費系統也會發出通知，寄送欠繳通知要求補齊。或是給付國保年金時，同時會需要比對勞保系統的資料，而這兩個年金不能重複請領，因此雙方系統的資料也必須同步。

而除了舊有系統外，因應現代政府推出更多e化服務的要求，現在也開發許多網頁應用程式，導致IT環境變得愈加複雜。面對這樣的挑戰，勞保局資訊室的解法除了利用模組化開發、物件導向的方法解決外，還要跟業務單位合作，建立統一開發標準，減輕溝通的阻礙。

首先是仰賴模組化開發。梁海珠解釋，勞保局每個業務單位都有帳務出納需求，因此，資訊單位將這些需求整併，打造出一套獨立的帳務系統，「讓它變得適用農保、勞保或各類保險」，來介接各業務單位的其他保險給付系統，讓帳務系統成為一套共用元件。

雖然每個保險的計算、給付方式都不一樣，「所以勞保局不可能只有一個給付系統」，但是把帳務出納系統整併後，各單位皆都用同一套規範，進行帳務出納流程。梁海珠表示，過去這些出納流程往往仰賴人工作業，但在整併帳務系統後，「資料輸入系統，相關金額匯給出納單位，再由銀行進行支付，全程都是電腦化作業。」她表示。

使用物件導向概念，開發才有彈性

再者是使用物件導向的方式開發。目前勞保局的核心程式語言是選用Java，而物件導向本來就為該程式語言的特性。「早期各系統間的相依性很強」，梁海珠舉例，一個津貼項目給付數字的改變，就會影響整套系統架構，得花上1至2個月修改。例如，每月固定發放8千元的老農津貼，最初只有3千元，一開始系統設計是固定該撥繳額參數為3,000。但是經過多次調漲後，資訊單位也開始了解部分法規較有修改彈性，「因此我們把系統設計得更有彈性，當調撥金額改變時，只要更改參數內容即可。」

與業務單位合作建統一開發標準

最後則是與業務單位合作，建立統一開發標準。過去，業務單位往往只是配合新資訊系統的更新，改變作業流程。但梁海珠笑著說，經過長時間的磨合，「現在業務單位的資訊化程度也很深，變得非常會開需求」，現在資訊單位反得要配合一線單位。

面臨業務單位複雜的需求，梁海珠表示，假如每個業務系統負責人，在維護、開發上的方法都不一時，未來其他承辦人就不容易接手，「所以一定要建立統一的開發規範。」

因此，資訊室就訂定了系統介面、頁籤的輸出形式、介面排版、字體以及程式命名等原則，「萬一系統出現問題，資訊單位比較容易跟業務單位溝通，點出該系統畫面編號為何，即可著手維修」，梁海珠表示，建立這樣的溝通標準比較方便溝通外，業務單位也可依循該標準，提出開發需求。

給付作業不延遲靠穩健IT

除了服務內部業務單位外，走進勞保局各地辦事處，就可知道民眾對其服務的仰賴程度，「勞保、農保、敬老津貼等給付絕對不可能延遲發放」，此外，梁海珠表示，勞保局也要提供民眾快速、穩定的線上查詢資料服務，因此勞保局的IT架構必須相當穩健。

目前勞保局核心業務所累積的數據已經多達22TB，而考量穩定性，目前是選用外部廠商甲骨文的資料庫解決方案。梁海珠表示，雖然部分開源專案確實有其功能亮點，「但如果運轉出現異常狀況，也沒有廠商支援。」即便是商用資料庫，在更新版本時也要審慎評估，「現場民眾都在排隊等待辦理業務，系統不能承受停機半小時以上的風險。」

外部服務不停機靠雙資料中心

由於勞保局的業務與民眾關係甚深，「如果停機過久，會引起很大關注」，梁海珠表示，勞保局核心系統共有4個節點，單一節點故障時，也不會影響至其他節點運作，網路流量也會先導入至正常節點上運作。而系統也都導入高可用性架構，除了主資料中心外，另外還有備援資料中心。一旦系統故障，也可先切換至備援中心運作。

由於對外民眾服務品質要求更高，因應24小時服務不能停機要求，勞保局分別在新莊、桃園架設了同步運作（Active-Active，AA）模式的雙資料中心，搭配外部的負載平衡設計，系統會將外部流量引入不同的資料中心。例如，當桃園機房正處於維護、停機階段時，新莊機房就得撐住全部的工作負載。

資安與便利性永遠存在衝突

當勞保局在2015年升級A級單位之後，資安要求也變得更高，必須將全部核心資訊系統導入資安管理制度（ISMS）。不過勞保局做的還不只如此，除了在2016年時取得ISO 27001認證，在今年也配合行政院的資安政策要求，導入政府組態基準（GCB）設定，於規範資通訊終端設備的一致性安全設定，像是密碼長度、更新期限等，降低該單位成為駭客入侵管道的可能性。

「資安永遠跟便利性永遠存在衝突」，梁海珠笑說，光是為了導入ISO認證，不僅業務單位，資訊單位的作業程序也得有所改變。而為了加強資安防護，除了稽核自家單位外，資訊室也會稽核其他的業務單位。

梁海珠舉例，在兩年前，行政院資安辦公室就建議勞保局，考量資安管理，「應該要取消各PC裝置上的本機管理員權限。」為了落實GCB規定，在2016年，資訊室首先自主落實，將單位內各PC的本機管理員權限移除，直到今年初，才將該政策一併落實至其他業務單位。梁海珠表示，雖然這項措施會對一線人員產生不便，但這也增加許多IT管理工作，對資訊室衝擊更甚，而站在資安立場考量，仍得要徹底落實，「雖然使用者不免會抗拒，但我們還是要讓資安習慣變得更加普遍。」

CIO小檔案

梁海珠

勞動部勞工保險局資訊室主任

學歷：臺灣大學歷史學系

經歷：畢業後即進入勞保局，從應用系統之開發與維護等基層工作做起。在2016年7月因應政府組改，從高級分析師接任資訊室主任，今年也配合行政院國家資通安全會報技術服務中心資安政策要求，導入政府組態基準（GCB）設定

資訊部門檔案

勞動部勞工保險局

● 地址：臺北市中正區羅斯福路1段4號

● 成立時間：1950年

● 主要業務：承辦全國性勞工保險業務外，歷年來也陸續接受委託或委任辦理多項業務，例如農民健康保險、老年農民福利津貼等

● 員工數：1,900人

● 首長：石發基

● 資訊部門主管職稱：資訊室主任

● 資訊部門主管姓名：梁海珠

● 直屬主管：石發基

● 資訊部門人數：99人

IT大事記

● 2014年：完成設備安裝與管理機制建置及應用系統移轉

● 2015年：完成設備安裝與管理機制建置及國民年金資訊系統

● 2015年：介接教育部學籍查驗系統，以電子查驗取代紙本查驗

● 2016年：取得ISO 27001:2013認證

● 2017年：符合資訊安全軟體安全特性發展策略，導入Fortify源碼檢測作業

● 2017年：加強資訊安全管理，確保運用電腦系統及內部網路資訊安全。配合政府網際網路通訊協定升級推動方案，進行IPv6網路升級作業

● 2017年：配合行政院國家資通安全會報技術服務中心資安政策要求，導入無線網路政府組態基準（GCB）設定

● 2017年：配合電子化政府法制作業（個人資料保護），強化使用者網路安全管控

● 2017年：規畫建置雲端文件共享服務平臺及雲端運算資料交換管理系統

經營企業最主要的目的就是「創造利潤」，說白一點就是要賺錢，雖然過程中可能面對市場變化與經營不善，但如果是因為詐騙而造成損失，應該很不甘心。

面對商業電子郵件詐騙（BEC）這樣的威脅，由於是企業本身疏於資安保護，如何「預防」交易匯款被騙走，就是企業最關心的事情。

因為BEC詐騙已經為企業帶來鉅額損失，我們需要有更多的警惕，至於該如何預防，如何強化電子郵件安全，就是一大議題。這次，我們也詢問了多家郵件安全與資安廠商，並整理出現有應對BEC詐騙各環節的作法，以及能利用的防護技術，讓企業能夠多些因應之道。

養成安全的郵件使用習慣

電子郵件已經是普遍企業傳遞訊息不可或缺的工具，尤其是與海外業者交易聯繫的重要管道。

而BEC詐騙的最大特點是，都是利用普遍人們對於電子郵件太過信任的習慣，沒有想到要去進一步確認寄件者，是否就是當事人，而誤信更改匯款帳號與緊急電匯的內容。

一般企業該如何防範呢？由於公司本身疏於資安防護，我們先從基本的資安防護面向來看，供企業作為因應參考。

 不要用免費信箱與共用帳號 

盡量不要使用免費網路信件空間，也千萬不要共用郵件帳號。要知道，這容易成為網路犯罪分子鎖定的目標。

有企業可能認為，他們連公司網站都沒有，怎麼會成為目標，其實在參展的各式交際與交換名片過程中，就有機會被駭客蒐集到資料而鎖定，特別是當他們發現，有使用免費信箱與共用信箱的情形時，很有可能判斷該公司是容易下手的目標，因為資安防護薄弱。

對於一些傳統的中小企業而言，老闆、會計與業務人員，可能都沒有這方面的概念，也欠缺專業IT人員，即便生意規模可能已經作的很大。也許，當大家在接觸到這樣的企業時，可以適時做出一些提醒，共同提升防護意識。

 做好基本密碼安全與端點防護 

由於BEC詐騙在早期發生階段，駭客也會監看電子郵件中的財務往來細節。因此在郵件帳號與登入方面，像是密碼設定不能太過簡單，避免輕易遭到暴力破解，同時也要做好基本端點防護，減少駭客入侵、木馬程式植入的機會，防止電郵詐騙案的發生。

 培養員工資訊安全意識 

面對各式釣魚信件、詐騙信件，企業員工只要稍不注意，就可能一次造成鉅額的損失。因此，企業平時就需要培養員工正確的資訊安全觀念，尤其是交易負責人與財務相關經辦人員，他們是BEC詐騙的主要收件者對象。

特別是在回覆電子郵件時，也應留意收件者的E-mail 是否正確，像是來自甲的電子郵件，回覆時寄件者卻是乙，就是問題，但一般使用者可能並不知道會有這樣的情形。同時，使用者也應對竄改電子郵件帳號的假冒與混淆手法，有些概念，才比較容易發現異常。

透過郵件安全產品的進階防護功能，加強企業本身的資安保護

不過，對於一般使用者來說，要識破這類假冒的電子郵件，純粹用人眼來看出也很難，也還是會有疏忽，因此通常也會建議，強化強化電子郵件系統的使用安全性，搭配一些郵件安全防護產品或輔助功能，來避免這樣的狀況發生，或是幫助使用者過濾。

 應用郵件加密方式確保內容安全 

企業可要求員工對重要信件進行附檔加密，或是透過具有自動加密的郵件防護產品，將整封重要信件加密成ZIP、PDF，而收到信件的用戶，需搭配事前透過電話約定之密碼才能開啟。而若要運用這樣的功能，已經有一些郵件安全產品可以提供這樣的功能，例如臺灣本土廠商網擎。

 發送BEC測試信，提升員工資安意識 

當然，如果想要強化人員對於BEC詐騙的資安意識，也有對應的作法。像是臺灣本土郵件安全廠商基點表示，他們提供的郵件滲透測試服務，也可與企業承辦人員探討客製化、針對式攻擊的BEC模擬樣本。

例如：寄件人偽冒為該公司的總經理，收件人為該公司的財務人員，也就是測試信的受測對象。至於郵件主旨，可以是「歐盟新開帳戶及信用額度」，郵件本文則是「歐盟ＸＸ廠商要新開帳戶及信用額度，此事很急，今天下午2點前要辦妥，並署名總經理。」這種寄發測試信的方式，也能達到提升警覺性的效果，針對上當的使用者。

 可啟用專屬的BEC防護功能 

此外，近年不少郵件安全廠商，也很關注BEC詐騙的猖獗，開始在郵件防護相關產品中，加入BEC相關的防護功能。舉例來說，像是趨勢與Cisco的產品中就有相關設定選項，一旦系統偵測到有問題，系統預設動作會在郵件內文或標提前面加上警示字樣，能夠幫助使用者察覺到郵件異常，提醒使用者要進一步去確認。

臺灣郵件安全廠商中華數位同樣表示，現在他們的郵件過濾產品也加入智慧型詐騙郵件行為特徵檢測，並可針對匯款詐騙、冒名偽造網域社交郵件防禦等，同時不會因為白名單設定不正確而影響判別結果。同樣，也會有做出警示，企業管理者管理者只需要宣導收到類似信件警示，需做第二管道的確認，即可降低詐騙郵件入侵的風險。

而趨勢科技也提到一些他們在BEC防護的技術原理，針對BEC詐騙社交工程手法，可透過機器學習來做到更精準的判斷，從郵件行為與意圖來偵測與交叉分析，分析郵件標頭，還有像是這類社交工程信件內容有太多種寫法，透過龐大的樣本來學習分析，提升準確性。

 自行設定郵件管控原則 

一些郵件安全防護產品也有內寄外送的管控機制，使用者也能簡單設定一些條件，像是將取名與CEO名字相同的信，如果不是內部傳送的話，都要做一些特殊的處理，放到隔離區或警示。

 強化郵件帳號登入安全 

避免郵件帳密被盜遭入侵，也是避免身分遭冒用，以及郵件內容被監看的防護重點。

因此，在郵件帳號與登入安全上，企業也能強化相關防護的機制，特別像是一些企業內部如有開放員工，透過網頁郵件服務、行動郵件App來收發信，應考慮是否強化相關的身分驗證機制，像是搭配雙因素認證，例如，以個人智慧型手機作為驗證裝置，確保登入郵件服務的使用者是否為本人，多一道驗證程序。又或者是要有異地登入警示的機制，才不至於讓企業帳號被盜，卻無法立即察覺。

 採用郵件身分驗證等機制 

若企業對於郵件安全有更高的條件需求，也可以注意郵件產品能夠提供的SPF、DKIM與DMARC等郵件身分驗證機制，或是S/MIME、PKI等加密以及簽章技術，從而降低釣魚郵件及偽造郵件的發生，甚至防護郵件傳送過程中不會遭到竄改，只是，這類方法通常也要寄收件雙方都能配合，施行難度較高。

至於針對假冒網域的情況，除了使用者最好要認識竄改E-Mail的混淆手法，過去有些公司在註冊網域名稱時，為了怕有被冒用的可能性，其實就會將這些看起來很像的網域，預先註冊以防範，也是一種方法。

強化企業匯款確認流程，也是預防BEC詐騙的關鍵方法

從BEC詐騙事件來看，都是對於電子郵件太過信任，誤信更改匯款帳號與緊急電匯的內容，匯款方不察或基於信任未再向請款方求證，導致匯款至詐騙帳號，使企業可能蒙受財務損失，且雙方也容易衍生交易糾紛。

若從商業流程的角度來看，由於公司本身可能疏於匯款確認，應加強公司內部商業流程的內控機制。

如以近期的BEC詐騙情境來看，簡單的作法就是，看到「客戶變更匯款帳戶」、「CEO通知緊急電匯」的郵件內容，一定要以第二管道聯繫，像是立即電話確認，增加交易的安全性。

或是請執行長與財務主管能提供一些匯款帳號清單，並建立確認帳號的標準流程。讓不在清單內的帳號，以及變更匯款與緊急電匯，都能有多一道審核程序。

對於靜態定型語言來說，泛型為必要之惡，編譯器必須獲得足夠的資訊，才能行使執行時期型態檢查，甚至是自動型態推斷（Type inference）的職責。

當提供給編譯器的資訊涉及物件導向之時，型態變異（Variance）的問題，會使得泛型語法可讀性迅速降低，不易令人理解與應用，這時，掌握PECS原則會是一個釐清各自應用場合的方式。

共變性、逆變性

我先前的專欄〈參數多型用於減輕型態負擔〉曾經談過型態變異，簡單來說，在Haskell這種非物件導向為典範的語言，可以從泛型（型態參數化）得到極大的益處，甚至反過來地，許多場合下編譯器雖然可自行推斷出型態，但Haskell的程式碼慣例中，建議可適當寫出型態，因為這有助於開發者掌握型態資訊。而在Java這類物件導向語言，由於型態系統上有繼承的問題，隨之演變而來的，就是支援泛型的同時，必須考慮型態變異的複雜問題。

如〈參數多型用於減輕型態負擔〉談過的，Java目前在定義支援泛型的型態時，沒有方式可以進行共變性（Covariance）或逆變性（Contravariance）的定義，也就是說，如果Banana繼承了Fruit，現階段的Java開發者並無法定義一個List，使之具有以下的行為：

List<Fruit> fruits = new ArrayList<Banana>();
List<Banana> basket = new ArrayList<Fruit>();

目前最新的JDK版本下，上面兩行都會引發編譯錯誤！話雖如此，為了能在一定程度上支援共變性與逆變性，Java使用了「?」通配字元（Wild card），搭配extends及super關鍵字，令以下行為可以通過編譯：

List<? extends Fruit> fruits = new ArrayList<Banana>();
List<? super Banana> basket = new ArrayList<Fruit>();

泛型的可讀性低，而從這邊可以看出，泛型的資訊，多半設定為給編譯器，而不是給開發者閱讀；為了簡化泛型，避免其語法冗長，更是充斥著各式符號。往往地，若離開語言一段時間後回頭來看泛型語法，第一時間往往是腦袋一片空白，「? extends」、「? super」？這什麼鬼東西？重點是哪些場合用前者？哪些場合又是後者呢？

Producer extends, Consumer super

因此，開發者必須先瞭解為什麼需要去支援共變性？假設有個fruits變數，實際上，可能接受ArrayList等Fruit子型態的清單，現在想要寫個forEach方法取得各個Fruit的資訊時，在參數或變數型態上，就會需要共變性的支援，例如，就方才的List<? extends Fruit> fruits來說，才可以撰寫fruits.forEach(out::println)，在這個情況下，fruits相當於水果供應商，只負責提供水果給out.println。>，或者是arraylist

而且，fruits也只能當個供應商，它不能收水果，也就是fruits.add(banana)這類的動作，會引發編譯錯誤，因為Java的泛型語法只用在編譯時期檢查，編譯器就只能就編譯時期看到的型態來檢查，因而造成以上限制。

那麼，我們為什麼需要支援逆變性？如果有個FruitSeller;，有個可以賣香蕉的sell(basket)方法，內部實作必須將Banana實例放入basket清單，那basket的型態是什麼呢？List不可行，如果傳入了一個專門來買香蕉的List<Banana>實例，就會因為Java不支援共變性而編譯失敗，List<? extends Fruit>也不行，因為這型態會限定傳入的必須是Fruit的生產者，因而不能有basket.add(banana)的動作。

此時，就需要使用List<? super Banana>的逆變性支援了。這麼一來，basket就可以接受List<Banana>或List<Fruit>，而且可以呼叫它們的add()來新增香蕉或水果了。那麼，這個basket可以提供水果嗎？像是呼叫basket.get()方法？問題就在於，怎麼知道basket裏裝的是什麼？隨意亂搞（轉型）的話，很容易就會發生ClassCastException了，因此，basket這時就單純只能當個消費者。

也就是說，「? extends」用於只供讀取的「生產者」，而「? super」用於只供寫入的「消費者」，而這些就是Joshua Bloch在《Effective Java》裡面，所提到的Producer extends, Consumer super，簡寫為PECS原則。

Kotlin的out與in

Kotlin是個靜態定型語言，具有物件導向典範，面對泛型，同樣也必須處理型態變異問題。Kotlin可以在定義型態時，決定其是否支援共變性，例如，若想要有個PList支援共變性，可以宣告class PList<out T>，如此fruits: PList<Fruit>就可以接受PList<Banana>的實作物件，而且還多了個限制，T就只能作為傳回值型態，不能作為參數型態，簡單來說，PList不能有接受T作為參數的方法定義了。

從PECS原則來看這限制，就容易理解為什麼有此限制，而且，這使得一個型態何時該支援共變性的考量，變得清晰，因為支援共變性的型態必須擔任生產者的職責，而out這個標註名稱也清楚地說明了，PList型態只產出T。

類似地，如果要Kotlin在定義型態時支援逆變性，可以使用in來標註，例如class CList(in T)，如此basket: CList<Banana>就可以接受CList<Fruit>的實作物件，對應的限制就是，T只能作為方法的參數型態，這意謂著CList只會消費T而不供應T，也就是一個型態是否支援逆變性，就在於考量該型態是否要作為消費者。

對於一個既有不支援共變性或逆變性的型態，Kotlin也有著對應「? extends」與「? super」的方案，例如，Array類別同時具有get與set方法，就不能定義其支援共變性或逆變性，然後，在必要的場合，可以使用fruits: Array<out Fruit>來達到「? extends」的效果，使用basket: Array<in Banana>來達到「? super」的效果。

從職責來理解變異性

共變性或逆變性這樣的名詞，只是單純地就型態系統上的繼承關係來區分，名詞本身就有著一層神祕感了，Scala支援在定義型態時，可標註支援共變性或逆變性，然而使用了+與-符號，對於既有不支援共變性或逆變性的型態，也使用了「_ <: Fruit」或「_ >: Banana」，與Java的「? extends」與「? super」相比，語法上的魔幻不遑多讓。

泛型的本意是為了簡化開發者的程式撰寫，而不是使之複雜，面對Java這類語言，從職責來理解變異性及各自的應用場合，會是比較好的作法；Kotlin的out與in（據稱這字眼學自C#），進一步讓泛型語法不單只是提供給編譯器的一堆符號，因此不要將它當成是單純地變異性標註，在使用時，應清楚out與in各代表著生產者與消費者的職責。

根據新的JDK改進提案（JDK Enhancement Proposals）——JEP 300（https://goo.gl/G31iAi），未來Java可能支援共變性與逆變性的宣告，例如<covariant R>或<contravariant T>，不過，covariant或contravariant關鍵字都太冗長了，提案中也談到，可能考慮+、-，或者是out、in，目標可能放在Java 10中推出（https://goo.gl/S7bBvV）。

無論如何，未來Java開發者又多了一個必須理解的語法與概念了（就算是Kotlin，官方文件在提及泛型時，也得先從Java的泛型開始，重頭解釋變異性），無論屆時語法為何，或者是現階段的「? extends」與「? super」方案，從職責來思考與理解變異性都是必要的，謹記得，Producer extends, Consumer super！

臺灣雲端郵件安全業者網擎資訊（Openfind）執行長廖長健在29日宣佈，為了進軍國際協同作業企業市場的布局，網擎將改用翟本喬所創的和沛科技旗下私有儲存雲ArkEase Pro（AEP）產品，來取代網擎自有的SecuShare檔案分享管理系統，而AEP研發團隊也將整併到網擎研發團隊中，網擎原有的企業用戶，也將逐步轉換成AEP產品。不同於Google買下HTC手機團隊的作法，臺灣軟體老將網擎以及和沛科技這家軟體新創，則是採取了不一樣的團隊整併式結盟。

和沛科技總經理翟本喬表示，透過網擎董事長高志明的牽線下，開啟兩家公司的合作之路，因為雙方評估在產品的互補下，決定由網擎整併和沛這套企業級檔案同步分享服務產品線AEP，包括6名AEP研發人力也將轉而併入網擎研發團隊，來負責該產品的後續開發與技術支援。翟本喬更以「費用分攤、利潤分享」來詮釋這個合作模式，他強調，未來AEP產品與研發都全面整併到網擎的產品線，並由網擎資訊負責相關的業務與行銷事宜。

網擎整併和沛私有儲存雲，驚艷AEP防勒索軟體功能

廖長健指出，和沛科技的AEP企業私有儲存雲產品具有三大特色，包括：跨裝置無縫同步和備份功能，可以做到快速和安全分享並有利協同作業，以及可以完整消除勒索軟體的損害。

網擎資訊行銷副總李孟秋則對AEP如何對抗勒索軟體印象深刻。她表示，這類私有儲存雲軟體都有一個桌面端可以和雲端同步的資料夾，先前勒索軟體橫行時，一旦使用者電腦這個同步雲端的資料夾也被加密，被加密的檔案也會同步到雲端資料夾，一旦超過儲存版本限制，幾乎無從還原檔案。

為了克服這個風險，李孟秋表示，AEP產品預設有5個可以同步雲端的資料夾，這個資料夾中都有隱藏誘餌檔案，例如，之前勒索蠕蟲Wannacry就是利用SMB漏洞迅速在企業內網蔓延，當Wannacry觸發這5個同步資料夾的誘餌檔案時，AEP就會知道這是勒索軟體，而不會將該次變動的檔案上傳雲端。因此，她說，使用者只需要從雲端將先前同步到雲端的檔案版本，透過一鍵還原的方式，就可以將文件順利恢復。

李孟秋指出，網擎原有SecuShare公有雲維運經驗，和稽核、歸檔、個資偵測和日誌留存等企業功能，未來也都會陸續整合到AEP產品上，「最遲年底前，可以完成相關功能的整合。」她說。

整併後的產品，瞄準企業檔案伺服器和網芳需求市場

廖長健表示，SecuShare和AEP產品的整併，短期目標就是希望取代企業內常用的檔案伺服器或者是網路芳鄰，透過企業級的資安功能，落實資料備份、稽核、個資偵測、歸檔、全文檢索和防勒索軟體等資安功能，協助企業可以達成數位轉型的目標。

但中期而言，他認為，這類EFSS產品也將轉型成內容協作平臺（Content Collaboration Platforms），也會加上電子郵件和即時通訊（IM）的功能，可以打造一個線上編輯與多人協作的生產力平臺。

「長期目標則是要打造一個以整合雲端郵件功能的One Platform，」廖長健認為，不論是將郵件附檔直接存放在儲存雲中，可以更安全快速的存取檔案，或者是可以透過MailCloud Messenger線上即時通訊軟體，在協作平臺彼此溝通，就可以直接在線上編輯或修改，達到商務雲端辦公室的願景。

對於靜態定型語言來說，泛型為必要之惡，編譯器必須獲得足夠的資訊，才能行使執行時期型態檢查，甚至是自動型態推斷（Type inference）的職責。

當提供給編譯器的資訊涉及物件導向之時，型態變異（Variance）的問題，會使得泛型語法可讀性迅速降低，不易令人理解與應用，這時，掌握PECS原則會是一個釐清各自應用場合的方式。

共變性、逆變性

我先前的專欄〈參數多型用於減輕型態負擔〉曾經談過型態變異，簡單來說，在Haskell這種非物件導向為典範的語言，可以從泛型（型態參數化）得到極大的益處，甚至反過來地，許多場合下編譯器雖然可自行推斷出型態，但Haskell的程式碼慣例中，建議可適當寫出型態，因為這有助於開發者掌握型態資訊。而在Java這類物件導向語言，由於型態系統上有繼承的問題，隨之演變而來的，就是支援泛型的同時，必須考慮型態變異的複雜問題。

如〈參數多型用於減輕型態負擔〉談過的，Java目前在定義支援泛型的型態時，沒有方式可以進行共變性（Covariance）或逆變性（Contravariance）的定義，也就是說，如果Banana繼承了Fruit，現階段的Java開發者並無法定義一個List，使之具有以下的行為：

List<Fruit> fruits = new ArrayList<Banana>();

List<Banana> basket = new ArrayList<Fruit>();
目前最新的JDK版本下，上面兩行都會引發編譯錯誤！話雖如此，為了能在一定程度上支援共變性與逆變性，Java使用了「?」通配字元（Wild card），搭配extends及super關鍵字，令以下行為可以通過編譯：
List<? extends Fruit> fruits = new ArrayList<Banana>();

List<? super Banana> basket = new ArrayList<Fruit>();
泛型的可讀性低，而從這邊可以看出，泛型的資訊，多半設定為給編譯器，而不是給開發者閱讀；為了簡化泛型，避免其語法冗長，更是充斥著各式符號。往往地，若離開語言一段時間後回頭來看泛型語法，第一時間往往是腦袋一片空白，「? extends」、「? super」？這什麼鬼東西？重點是哪些場合用前者？哪些場合又是後者呢？
Producer extends, Consumer super
因此，開發者必須先瞭解為什麼需要去支援共變性？假設有個fruits變數，實際上，可能接受ArrayList等Fruit子型態的清單，現在想要寫個forEach方法取得各個Fruit的資訊時，在參數或變數型態上，就會需要共變性的支援，例如，就方才的List<? extends Fruit> fruits來說，才可以撰寫fruits.forEach(out::println)，在這個情況下，fruits相當於水果供應商，只負責提供水果給out.println。>，或者是arraylist
而且，fruits也只能當個供應商，它不能收水果，也就是fruits.add(banana)這類的動作，會引發編譯錯誤，因為Java的泛型語法只用在編譯時期檢查，編譯器就只能就編譯時期看到的型態來檢查，因而造成以上限制。
那麼，我們為什麼需要支援逆變性？如果有個FruitSeller;，有個可以賣香蕉的sell(basket)方法，內部實作必須將Banana實例放入basket清單，那basket的型態是什麼呢？List不可行，如果傳入了一個專門來買香蕉的List<Banana>實例，就會因為Java不支援共變性而編譯失敗，List<? extends Fruit>也不行，因為這型態會限定傳入的必須是Fruit的生產者，因而不能有basket.add(banana)的動作。
此時，就需要使用List<? super Banana>的逆變性支援了。這麼一來，basket就可以接受List<Banana>或List<Fruit>，而且可以呼叫它們的add()來新增香蕉或水果了。那麼，這個basket可以提供水果嗎？像是呼叫basket.get()方法？問題就在於，怎麼知道basket裏裝的是什麼？隨意亂搞（轉型）的話，很容易就會發生ClassCastException了，因此，basket這時就單純只能當個消費者。
也就是說，「? extends」用於只供讀取的「生產者」，而「? super」用於只供寫入的「消費者」，而這些就是Joshua Bloch在《Effective Java》裡面，所提到的Producer extends, Consumer super，簡寫為PECS原則。
Kotlin的out與in
Kotlin是個靜態定型語言，具有物件導向典範，面對泛型，同樣也必須處理型態變異問題。Kotlin可以在定義型態時，決定其是否支援共變性，例如，若想要有個PList支援共變性，可以宣告class PList<out T>，如此fruits: PList<Fruit>就可以接受PList<Banana>的實作物件，而且還多了個限制，T就只能作為傳回值型態，不能作為參數型態，簡單來說，PList不能有接受T作為參數的方法定義了。
從PECS原則來看這限制，就容易理解為什麼有此限制，而且，這使得一個型態何時該支援共變性的考量，變得清晰，因為支援共變性的型態必須擔任生產者的職責，而out這個標註名稱也清楚地說明了，PList型態只產出T。
類似地，如果要Kotlin在定義型態時支援逆變性，可以使用in來標註，例如class CList(in T)，如此basket: CList<Banana>就可以接受CList<Fruit>的實作物件，對應的限制就是，T只能作為方法的參數型態，這意謂著CList只會消費T而不供應T，也就是一個型態是否支援逆變性，就在於考量該型態是否要作為消費者。
對於一個既有不支援共變性或逆變性的型態，Kotlin也有著對應「? extends」與「? super」的方案，例如，Array類別同時具有get與set方法，就不能定義其支援共變性或逆變性，然後，在必要的場合，可以使用fruits: Array<out Fruit>來達到「? extends」的效果，使用basket: Array<in Banana>來達到「? super」的效果。
從職責來理解變異性
共變性或逆變性這樣的名詞，只是單純地就型態系統上的繼承關係來區分，名詞本身就有著一層神祕感了，Scala支援在定義型態時，可標註支援共變性或逆變性，然而使用了+與-符號，對於既有不支援共變性或逆變性的型態，也使用了「_ <: Fruit」或「_ >: Banana」，與Java的「? extends」與「? super」相比，語法上的魔幻不遑多讓。
泛型的本意是為了簡化開發者的程式撰寫，而不是使之複雜，面對Java這類語言，從職責來理解變異性及各自的應用場合，會是比較好的作法；Kotlin的out與in（據稱這字眼學自C#），進一步讓泛型語法不單只是提供給編譯器的一堆符號，因此不要將它當成是單純地變異性標註，在使用時，應清楚out與in各代表著生產者與消費者的職責。
根據新的JDK改進提案（JDK Enhancement Proposals）——JEP 300（https://goo.gl/G31iAi），未來Java可能支援共變性與逆變性的宣告，例如<covariant R>或<contravariant T>，不過，covariant或contravariant關鍵字都太冗長了，提案中也談到，可能考慮+、-，或者是out、in，目標可能放在Java 10中推出（https://goo.gl/S7bBvV）。
無論如何，未來Java開發者又多了一個必須理解的語法與概念了（就算是Kotlin，官方文件在提及泛型時，也得先從Java的泛型開始，重頭解釋變異性），無論屆時語法為何，或者是現階段的「? extends」與「? super」方案，從職責來思考與理解變異性都是必要的，謹記得，Producer extends, Consumer super！

因應天災人禍，美國聯邦通訊委員會（FCC）呼籲包括蘋果開啟手機FM廣播功能。不過蘋果表示最新的iPhone並沒有這項功能。 

北美地區近日接連受到哈維、厄瑪及瑪莉亞三個颶風侵襲，電信基礎建設嚴重毁損及通訊中斷。為了災民獲得和外界基本溝通能力，日前美國廣播協會（NAB）呼籲蘋果啟動iPhone內的FM晶片，讓使用者必要時能聽取廣播。FCC主席Ajit Pai於周三加入呼籲。

他表示，近年已多次呼籲美國境內銷售的所有智慧型手機開啟FM晶片，首先讚許已經開啟這功能的業者，然後話鋒一轉點名蘋果是少數抗拒的主要手機業者。基於三個颶風造成重創，他再度要求蘋果開啟iPhone內的FM晶片，「現在是蘋果起而行之，以美國人民安全為優先的時候。」

蘋果周五發表回應聲明，表示蘋果深度關切用戶安全，尤其是在緊急狀態時，因此蘋果產品已加入現代安全方案，如iOS 11加入了可直接在鎖定螢幕，連按5次電源鍵直接撥打緊急求救電話，或是手機醫療卡（Medical Card）內建的醫療資訊，並支援天氣警報及安珀警報（Amber Alert）等政府通知。

但蘋果指出，iPhone 7及iPhone 8（包括iPhone X）並未內建FM廣播晶片，也沒有支援FM訊號的天線，因此不可能開啟FM廣播。

MacRumor報導，每代iPhone中的Qualcomm及英特爾都有Wi-Fi及行動通訊能力，其內建的FM調諧器讓使用者可以收聽FM廣播，但蘋果早在iPhone7以前，就一直沒有開啟這項功能，迫使用戶只能連網收聽網路廣播。而科技部落格Techcrunch則指出，事實上，沒有法律規定手機一定要有廣播功能。

 穿戴裝置   Apple Watch  

蘋果Apple Watch 3全球上市，內建LTE可獨立通話及行動上網

蘋果新一代Apple Watch 3已正式在9月22日全球開賣，首次內建LTE通訊功能，可以獨立通話及行動上網，且每個Apple Watch手錶也和iPhone共享同一個手機號碼；另外，新版Apple Watch也特別採用更小尺寸的eSIM卡設計，這是一個新型的嵌入式SIM卡設計，因為是直接將SIM嵌入裝置內，體積上較不占空間，大小只有原來SIM 卡的百分之一，還搭配新的天線設計，才得以在不增加硬體空間的前提下，來提供LTE功能。Apple Watch 3也內建watchOS 4新版本，並也針對健康和健身功能提供多項改善和優化。另外電池續航也達到18小時，並推出兩種版本，LTE 版售價為 399 美元和無 LTE 版本售價為329美元起。（詳全文）

 IoT殭屍網路    Linux.ProxyM  

Dr.Web揭露專門感染Linux裝置的新型IoT殭屍網路，超過10萬臺裝置受感染

俄國資安業者Dr.Web最近揭露一個專門感染Linux裝置散布大量垃圾郵件的新型IoT殭屍網路Linux.ProxyM。Dr.Web是在今年2月首次發現Linux.ProxyM殭屍病毒的出現，並且觀察到有持續擴大感染的跡象，到今年6月為止，至少超過10萬臺Linux裝置受感染，包括像是路由器、數位機上盒或其他Linux設備等。根據Dr.Web的統計，受感染過的裝置，平均每天會寄出400封的垃圾郵件，若以10萬臺裝置來計算，代表一天可以發送4,000萬封郵件，目前受Linux.ProxyM影響的國家，主要分布在美國、印度及歐洲等地區。Dr.Web也提出警告，這類型IoT殭屍網路未來將可能會越來越加猖獗。（詳全文）

 區塊鏈   物聯網聯盟  

思科、Bosh及大型金融業聯手成立信任物聯網聯盟，將用區塊鏈確保物聯網安全

近日，由思科、Bosh及大型金融業者與區塊鏈服務商共同組成新的信任物聯網聯盟（Trusted IoT Alliance），旨在建立一個開源的區塊鏈協定標準，讓企業可以利用區塊鏈的分散式帳本追蹤及驗證機制，來打造更具安全的IoT網路架構，以建立一個安全、可擴展、互通以及值得信任的IoT生態系。聯盟初期成員包括有美國銀行、美國合眾銀行、紐約梅隆銀行等金融業者，以及區塊鏈服務公司如ConsenSys、Skuchain等，還有Gemalto等安全業者及物聯網公司加入。信任物聯網聯盟也表示，未來將著手進行試驗專案，並釋出開源碼。（詳全文）

 藍牙    IoT安全 

藍牙漏洞恐讓上億手機門戶大開，不用配對就能駭入裝置

安全公司Armis Labs研究人員最近揭露一項針對藍牙漏洞的攻擊手法，並稱呼它為BlueBorne，只要使用者裝置有開啟了藍牙通訊功能，攻擊者就能夠利用取得藍牙裝置的MAC位置，來入侵該裝置，全程不需與裝置配對或設定。研究人員也公布8個BlueBorne使用的藍牙零時攻擊漏洞，其中有4個被列為重大風險。這些漏洞已被證實可被入侵用戶連網裝置，並可被用來發動各種型態攻擊，包括遠端控制，或是進行中間人攻擊等。目前受影響作業系統包括Android、Linux、Windows及iOS 10以前的系統。 儘管微軟、蘋果、Google已陸續釋出更新修補漏洞，但至今仍有將近上億個舊版Android以及iOS裝置還未修補，仍存有被駭的風險。（詳全文）

大數據   Eclipse基金會  

商用大數據服務商Cloudera加入Eclipse開源IoT專案，將貢獻數據管理平臺

全球大型商用Hadoop版本發行商Cloudera日前正式加入Eclipse基金會，負責協助Eclipse IoT專案的推動，來加速發展IoT解決方案，Cloudera也將貢獻一個IoT數據管理平臺，可以更容易幫助企業將從設備蒐集到的IoT資料，加快用來進行機器學習和進階分析，來挖掘出新的商用價值。未來Cloudera將與該專案主要成員包括Bosch、Eurotech 及Red Hat等共同合作，來開發一個全面的IoT框架，以便將IoT裝置、閘道器及雲端的軟體堆疊整合，同時還可以提供做為永遠性儲存和機器學習分析使用。（詳全文）

IoT市場調查    IoT安全  

IoT 調查：2022年全球IoT安全市場商機將上看44億美元

隨著IoT安全重要性日益增長，越來越多的企業也開始加強和提高對IoT安全的投資。市研機構IoT Analytics近日也在最新發布的2017～2022物聯網安全市場報告中指出，全球的IoT安全市場規模，未來5年內將會大幅成長。這份IoT安全市場報告主要針對了包括工業、零售、醫療等12個行業及超過21項IoT安全相關技術的投資規模進行調查。根據IoT Analytics的預估，2017年全球物聯網安全市場將可達到7.03億美元，未來5年的年複合成長率則可來到44%，並可望於2022年達到44億美元的市場規模。（詳全文）

自駕車   百度  

百度重砸百億人民幣成立Apollo基金會，未來3年將投資百項自駕車專案

中國搜尋引擎龍頭百度為了布局自駕車近來動作頻頻，前不久才剛與微軟、Nvidia、福特等50多家業者合作，打造開源自駕車平臺Apollo，最近更進一步宣布將重砸100億人民幣（約新臺幣457億元）成立Apollo基金會，未來3年計畫投資超過100個自駕車研發專案，希望吸引更多的開發者加入自駕車應用的開發行列。百度同時還在新釋出的Apollo 1.5版中新增5個核心功能，包括障礙感知、路線規畫、雲端模擬系統、HD高畫質地圖，以及端到端深度學習技術，提供開發者能加速自駕車研發。（詳全文）

自駕車   特斯拉  

傳特斯拉也將和AMD合作開發自駕車晶片

不只與Nvidia合作開發自駕車硬體，近來特斯拉也傳出同時還找上了另一家GPU廠商AMD合作，打算研發自己的自駕車晶片。特斯拉去年底終止與MobileEye的合作關係後，之後在Autopilot自駕系統開發上，就積極尋找非MobileEye的解決方案，包括採用Nvidia的自駕車晶片等。不過對此，AMD及特斯拉都拒絕做出評論。整理⊙余至浩（詳全文）

圖片來源／Apple、Armis Labs、百度、特斯拉

 IoT近期新聞 

1.英特爾也決定聯手Waymo打造全自動駕駛車

2.Google旗下Nest也跨入家庭安全市場，推出Nest Secure產品

3.微軟與Amazon結盟要讓Cortana向Alexa說嗨！

4.自駕車市場正夯！三星砸3億美元設立汽車新創基金

資料來源：iThome整理，2017年9月

科技部落格Techcrunch引述消息來源報導，Google正在研發一個類似Amazon Echo Show的7吋螢幕智慧桌上型視訊裝置。

消息人士指出，新產品在Google內部專案代號為Manhattan，它和Echo Show同樣採用7吋螢幕，內建Youtube、Google Assistant、Google Photos及視訊通話功能，可能也會跑第三方App，如Netflix。此外也能當成智慧家庭中樞（smart hub），可控制Nest及其他智慧連網裝置。

今年5月推出、售價230美元（約台幣7,000元）的Amazon Echo Show內建Alexa語音助理、高音質的麥克風、杜比音效喇叭之外，最大特色是搭載7吋觸控螢幕及相機，除了可聲控由Echo報氣象、放音樂、開啟家中照明或冷氣外，還可以播放相片、上Youtube看影片、顯示氣象、購物清單或是播放保全攝影機的影像。

據傳之前Google也有其他更大尺寸螢幕產品的規劃，但現在把重點放在Manhattan上。而原本Manhattan預計的時程為2018年，自從Amazon Echo Show宣佈後，Google被迫提前到2017年，只是相關零組件供貨及可能的通路動員不及，因此仍然會延到2018年。

巧合的是，就在本周Google無預警將Youtube從Echo Show拉下，讓後者用戶無法存取Youtube服務，讓用戶及Amazon感到錯愕。事後Google解釋是「Amazon實作Youtube方法違反Google規定，破壞用戶體驗」。

臉書稍早也傳有一個正在開發代號為Aloha，類似Echo Show的視訊通話裝置。