美國行動電信商Sprint 6月底通知用戶，他們的Sprint用戶帳號資訊因為三星網站遭駭客入侵而外洩。

根據Sprint的電子郵件內容，今年6月22日Sprint獲知有駭客利用Samsung.com上一個名為「add a line」的網站，而得以未授權存取用戶Sprint帳號，使帳號個資可能被看光。這些資訊包括電話號碼、裝置類型、裝置ID、每月費用、用戶ID號碼及全名、帳號號碼、帳號建立日期、升級資格、帳單地址及附加服務等。該公司說其他可能造成詐欺或身份冒用等重大風險的資訊則沒有外洩。

Sprint表示在發現問題後已經採取行動確保帳號安全，目前沒有發現任何詐欺行為發生。Sprint並在6月25日發出簡訊，通知用戶帳號PIN碼被破解，以及PIN碼已經重設一事。

Sprint的通知留下太多疑問，例如並未說明有多少用戶受害、以及駭客存取Sprint用戶帳號的確切時間點。此外歹徒如何利用三星網站來駭入帳號，Sprint也都沒有說明。這也是Sprint第二次向用戶發出被駭通知；今年5月駭客利用Sprint旗下虛擬行動網路子公司Boost Mobile PIN碼及電話號碼存取Sprint用戶帳號。而今年三月Sprint系統臭蟲，讓用戶竟然在帳號中看到其他人的姓名及電話號碼。

保加利亞的國稅局在15日坦承其電腦系統遭到駭客入侵，駭客盜走了當地數百萬納稅人的資料，還自己向當地媒體爆料，官方則說這是當地規模最大的資料外洩事件。

駭客是在6月底入侵了國稅局網路與電腦系統，初步的調查顯示駭客可能是攻陷了退稅申請系統的安全漏洞，國稅局說駭客只入侵了3%的資料庫，波及數百萬民眾的報稅紀錄，包括報稅內容、社會安全碼、姓名、地址及收入等。

駭客則在16日自行向眾多媒體爆料，還提供了逾110萬名民眾的資料予其中一家媒體以茲證明，包含這些民眾的收入及社會安全碼等。

駭客使用了俄羅斯最大搜尋引擎Yandex的電子郵件信箱，宣稱自己是俄羅斯人，但娶了保加利亞的女生，只是不滿保加利亞政府過於腐敗，要求當地政府公布腐敗的真相，否則就要把他所盜來的21GB資料公諸於世。

根據反貪腐組織Transparency International的調查，保加利亞在全球180個國家中的透明度指數排名第77名，但在28個歐盟會員國中卻是最後一名，顯示它是歐盟最貪腐的國家。相較之下，台灣政府的透明度指數排名31，中國政府則是87名。

不過，當地媒體卻猜測駭客的行為只是要展示國稅局的資安機制太過脆弱，特別是當地企業曾多次警告政府應加強官方系統的安全保障。保加利亞國稅局已邀請資安專家檢視並修補其電腦系統的安全漏洞。

IBM與美國電信業龍頭AT&T周二宣佈已在第2季簽訂涵括雲端代管、服務、共建5G邊緣運算服務平台的多年互惠合約。

在這項合作下，AT&T將藉IBM服務部門現代化其內部軟體應用Business Solutions，提供開發及支援服務，以便未來搬到IBM雲端上。IBM也將為企業服務（AT&T Business）單位的應用系統提供底層基礎架構。此外，作為Red Hat的既有客戶，AT&T內部應用及營運作業，以及新服務的開發，都會持續跑在Red Hat Enterprise Linux、OpenShift開源平台上。

作為混合雲供應商，IBM除了服務AT&T企業部門，也將代管AT&T Communications包括本地部署、私有雲、公有雲上的所有IT基礎架構。

此外，AT&T企業業務本來就是IBM全球網路設備夥伴，而在新合作下，AT&T還會成為IBM軟體定義網路的主要設備供應商，提供AT&T的5G、邊緣運算、物聯網（IoT）及多雲技術以強化IBM網路解決方案。

最後，因應5G時代到來，雙方還將合作建立邊緣運算平台，以支援零售、金融、運算、製造及醫療部署5G網路，在多雲之間及數十億個連網裝置及感測器和雲端之間，安全、穩定而高速傳送大量資料之所需。

AT&T企業部門執行長Thaddeus Arroyo指出，透過和IBM的合作，該公司將得以使用開放、彈性的雲端技術，加速服務的創新。

這項合作於第二季即簽定，但在IBM上周完成Red Hat收購後才公開。

5月IBM也宣佈拿下印度最大電信商Vodafone Idea的5年混合雲端及AI平台供應商合約。

專門經營駭客代管服務的Mikhail Rytikov本周傳出已在烏克蘭的奧德薩被逮捕了。

美國司法部在2013年同時起訴了多名駭客以及Rytikov，Rytikov所扮演的角色是替這些駭客提供匿名的網站代管服務，以協助駭客入侵企業的電腦網路並竊取資料，還會替駭客客製化平台，且Rytikov在巴拿馬及烏克蘭等地都部署了服務伺服器。

烏克蘭國家安全服務的負責人Ivan Bakanov表示，他們是在美國及英國的協助下，由當地警方出面逮捕了Rytikov。指稱Rytikov涉及經營一個擁有150台伺服器與設備的資料中心，以協助駭客執行分散式阻斷服務攻擊，或是散布垃圾郵件及色情內容，掌控了4成以俄文為主的暗網，還在俄文地下論壇兜售自己的服務。

Rytikov辯稱自己只是提供平台，並未涉及犯罪活動，對於駭客的行為亦不知情；但美國掌握了Rytikov與駭客之間往來的訊息，顯示Rytikov不僅知道自己的平台被用來執行網路攻擊，還會協助駭客躲避偵測。

其實美國追捕Rytikov已經好幾年，且Rytikov一直居住在烏克蘭，卻一直安然無恙，有媒體報導，烏克蘭政府之所以逮捕Rytikov並非著眼於美國或英國的要求，而是Rytikov與俄羅斯駭客合作，在此一烏俄關係緊張的時刻有叛國之嫌，此外，烏克蘭與美國之間並無引渡條款，Rytikov很可能會被留在烏克蘭受審。

Alphabet的無人機子公司Wing在本月釋出了無人機的空中流量控制程式OpenSky，不過該程式礙於各國無人機法令的不同，目前只在已取得官方許可的澳洲上架，尚未部署至其它市場。

OpenSky如同空中版的Google Maps，使用者可輸入所要飛行的區域，它即會標示出禁止飛行的領域、危險區域、只能在白天飛行的領域，以及飛行高度限制等，以利商家或業餘無人機愛好者操作無人機或無人機隊。

目前Wing已推出iOS版、Android版及網頁版的OpenSky。

根據彭博社的報導，先前Wing曾於三大洲以OpenSky進行8萬次的飛行測試，目前僅有澳洲政府核准該程式的上架，Wing正在爭取其它國家的同意。

有別於傳統的飛航系統多是由政府所控管，澳洲開放私人企業提供無人機的追蹤與管理系統，除了Wing之外，澳洲官方也歡迎其它業者打造類似OpenSky的程式與服務。

Google Maps使用者在應用程式中，不只可以搜尋共享自行車站的位置，現在還能直接看到剩餘可供租借數量等即時資訊，Google提到，他們與全球共享自行車資料饋送服務Ito World合作，新增24個城市的資料，其中也包括了新北市與高雄市。

共享自行車A地借B地還的方式，在全球捲起風潮，改變了人們在城市中移動的方法，Google提到，過去一年，他們看到在紐約的旅行者以及通勤者，不停地使用Google Maps地圖搜尋共享自行車站點，因此為了提供使用者更精準的共享自行車的資訊，現在Google在16個國家總共24個城市，於Google Maps上推出即時共享腳踏車的資訊。

Google Maps使用者現在可以查到位於紐約、巴塞隆納、柏林、布達佩斯、倫敦與洛杉磯等城市的共享自行車站，以及臺灣新北市Ubike與高雄市City Bike站點的即時資訊，這些即時資訊包括站點提供的自行車總數量，以及剩餘可用的數量。無論是到這些城市的旅客，抑或是通勤者，都可以方便地查到共享自行車資訊，以安排交通計畫。這項新功能已經同時在Android和iOS的Google Maps上提供。

一名獨立研究人員Laxman Muthiyah本周揭露了他如何破解了Instagram（IG）社交網站的密碼復原程序，可取得任何IG用戶的登入憑證，還得到了臉書（Facebook）所頒發的3萬美元抓漏獎金。

Muthiyah說，他一開始就想尋找IG的密碼重設漏洞，先試著在IG的網頁重設密碼，但幾分鐘之後就覺得該服務的安全機制頗為強大，於是轉向IG的行動帳號復原程序。

當使用者要求以行動裝置接受IG的密碼重設服務時，會收到IG所寄出的6位數密碼，使用者可先輸入該密碼，再變更成自己的密碼。

於是Muthiyah決定採用暴力破解法來猜測此一6位數密碼。此一6位數密碼的有效時間只有10分鐘，且Muthiyah發現該機制的兩個重要臭蟲，一是它允許單一IP連續輸入200次的錯誤密碼，二是它並無黑名單的設計，亦即不會封鎖持續輸入錯誤的IP，但若要確保成功必須在10分鐘內嘗試100萬種組合。

因此，Muthiyah使用了1,000台不同的機器同時針對同一個帳號測試密碼，在10分鐘內即可測試20萬種組合，假設駭客透過各種雲端服務以5,000台機器展開攻擊，很容易就能取得任何IG用戶的密碼，花費大概是150美元。

Muthiyah並未說明該如何觸動密碼重設機制或是收到IG寄出的密碼，僅是展示如何用他的1,000台機器測試20萬組密碼，就得到了臉書的3萬美元獎勵。

IBM在OSCON 2019大會上，一口氣釋出了雲端開發相關的三項開源專案，分別是K8s應用程式開發框架Kabanero，以及用來打造雲端應用程式的堆疊與工具Appsody，另外，IBM也為熱門IDE釋出擴充套件Codewind，降低容器化應用程式的開發門檻。

IBM提到，越來越多企業的採用混合雲策略，不少工作負載都被放到Kubernetes和容器中執行，但是除了挑選適合的技術不容易外，要將工作負載搬遷到雲端，架構師、開發人員以及營運人員等不同角色，要能共同合作更是另一個挑戰。為了降低開發與部署原生雲端應用程式的困難度，IBM創建了Appsody、Kabanero與Codewind三個新的開源專案。

Appsody提供了一系列原生雲端應用程式的開發工具，包括CLI以及技術堆疊Appsody Stacks，還有可用堆疊中央儲存庫Appsody Hub。Appsody的目的是要簡化原生雲端應用程式的開發過程，要讓開發人員在數分鐘內，就能創建符合組織標準以及要求的微服務。Appsody Stacks內含熱門的開源Runtime以及開發框架的預配置樣板，像是搭配Eclipse的Java或是帶有Express的Node.js，為基於Kubernetes和Knative技術建構的應用程式提供開發基礎。

使用者可以客製化Appsody堆疊，以滿足特定開發需求，而Appsody Hub則提供了一個中央控制中心，使用者可以在Appsody Hub找到可用堆疊、創建新堆疊或是修改現有堆疊，透過修改Appsody Hub中的堆疊，只需要重新啟動應用程式，就能大規模應用更新到以該堆疊為開發基礎的應用程式。而Appsody CLI則讓開發者能夠探索新的可用堆疊，並帶入本地端環境，進行建構、執行、測試與部署工作。

而原生雲端Kubernetes應用程式開發框架Kabanero的目標，就是要讓開發者能以現有的技能開發Kubernetes應用程式，Kabanero整合了不少開源專案，包括Knative、Istio與Tekton，還有Appsody、Codewind和Razee，建構起整體的開發框架，為用戶提供端到端解決方案，可用來建置、部署和管理Kubernetes應用程式生命周期。

Kabanero將基礎開源技術整合到了一個基於現代微服務的框架中，使得架構師、開發人員以及營運人員能夠良好的協作，IBM提到，使用Kabanero讓用戶不需要額外花時間，掌握DevOps最佳實踐或是Kubernetes基礎設施等技能，Kabanero已經將Node.js、Java和Swift等Runtime和框架，與原生Kubernetes的DevOps工具鍊整合在一起。

IBM提到，目前市面上沒有Kabanero相似的專案，雖然有一些開源專案能夠解決Kabanero所處理的部分問題，但皆無法在Kubernetes上，為容器化應用程式從創建到整個生命周期，提供整合的開發方法，而且組織不需具備容器和Kubernetes專業知識，也能將原本在傳統基礎設施運作的工作負載，轉移到更現代的雲端架構上。

IBM同時也推出了由Eclipse基金會管理的新專案Codewind，Codewind提供像是VS Code、Eclipse和Eclipse Che等熱門IDE的擴充套件，讓開發者可以在熟悉的工作環境建置容器應用程式，IBM強調，Codewind減少了容器化應用程式開發的困難，開發者也可以在容器中快速迭代，進行除錯與效能測試，就如同是在正式生產環境中執行一樣。Kabanero和Appsody將透過Codewind提供整合的IDE開發體驗。

電子支付、行動支付蔚為潮流，現已成為政府推動數位經濟發展，重要焦點之一，而在感應支付方式外，QR Code掃碼支付也將是助長普及的關鍵，值得注意的是，對於共通QR Code規格的應用，近期在臺正式上路。

這項標準源自於2017年，是由國際支付產業標準組織EMVCo.制定全球共通規範EMV QR Code。到了2018年，Visa與Master國際發卡組織，與聯合信用卡中心（NCCC），開始在臺推動這項共通規格，並與財金資訊公司，以及多家國內發卡金融機構合作。

今年下半，應用EMV QR Code的多項服務，宣布正式上線，例如，7月初Visa與財金公司推動，信用卡帳單掃碼繳款服務；對於實體小型零售商家的掃碼支付，他們也積極拓展，在中旬，Visa更是宣布新的成果，目前已經串聯9大銀行的行動支付錢包，以及行動支付「台灣Pay」，並有1萬家的通路能接受使用，包括臺北魚市、臺北花市，以及西門商圈、永康商圈的店家，還有鳳凰旅行社、志英計程車隊。

對於小型商家而言，像是微型商店、傳統市場與路邊商家等，QR Code掃碼支付的方便性，已經不言而喻。這不僅是取代現金交易，同時也比建置傳統感應式POS機、刷卡機的成本更低，只要張貼一張QR Code貼紙即可。而EMV共通QR Code的應用優勢，是提供了統一規格的二維條碼，讓消費者使用不同的App支付，都能掃描相同的QR Code貼紙，打破隔閡。而不像許多支付業者，提供了規格相異的QR Code，彼此並不互通，使得許多零售店家收銀臺上，擺放了各種規格的QR Code。未來，此共通標準的發展，還將朝向跨境支付的情境。

現有10家金融服務業者加入應用行列

目前，應用EMV國際通用掃碼支付的金融服務業者，已經包括行動支付「台灣Pay」，以及9家銀行的App，分別是台新銀行的卡得利、永豐銀行的豐錢包，以及渣打行動銀行、華銀行動網、兆豐Pay、彰銀行動網、第一銀行第e行動、合庫E Pay與台灣企銀行動銀行。

而在掃描方式上，現行支援主掃模式（Merchant Presented Mode），也就是只要店家擺放「EMV國際通用掃碼支付」的QR Code貼紙，消費者用上述App，都能掃描該條碼去支付。對於店家而言，能支援更多支付App，但無須擺放不同QR Code貼紙。

這項共通標準，還將有更多金融業者加入。至於像是LINE Pay、街口支付，因為已有自身的QR Code規格，未來是否會採用，仍是未知數。

至於民眾關注的安全方面問題，除了支付交易流程，是發卡行收到消費者掃碼訊息，款項才會撥給收單行並通知店家，確保商家的收款，銀行公會也制定了相關的規範，完成「金融機構提供QR Code掃描支付應用安全控管規範」，以確保能有一致的安全控管作業。

隨著EMV QR Code規格的在臺推動，在與政府與金融業者的陸續合作之下，首波已有10家金融服務業者加入應用行列，不僅行動支付「台灣Pay」整合這項規格，目前還有9家銀行的電子錢包參與，例如兆豐銀行的兆豐Pay、永豐銀行的豐錢包，彰化銀行的彰銀行動網、台灣企銀的行動銀行、華南銀行的華銀行動網，以及合作金庫的合庫E Pay、渣打銀行的渣打行動銀行、台新銀行的卡得利與第一銀行的第e行動等。

聯想於本周警告，Iomega與LenovoEMC品牌的網路附加儲存（NAS）設備含有安全漏洞，將允許未經授權的使用者透過API存取NAS上的共享檔案，呼籲用戶應儘快升級韌體。

率先發現相關漏洞的是Vertical Structure，該公司有名員工去年秋天在Shodan.io上監控網路的安全性時，看到一些古怪的檔案，細究後發現只要透過一個API並傳送特製的請求，就能存取外接硬體上的資料，而不必藉由這些硬碟的網路介面存取。

Vertical Structure總計找到了多達36TB的資料，大約是300萬個檔案，有些檔案含有諸如信用卡號或金融紀錄等機密資訊，追查來源為Iomega儲存裝置。

1980年成立的Iomega為一儲存設備製造商，在2008年被EMC併購，EMC在2013年與聯想共組LenovoEMC，並由新公司接管了Iomega業務，隨後將Iomega產品線更名為LenovoEMC。

Vertical Structure先聯繫了WhiteHat Security以協助驗證該漏洞，確認漏洞的真實性之後才通報聯想。

根據聯想的說明，該漏洞同時存在於Iomega與LenovoEMC的NAS產品上，總計波及8款產品，聯想已更新相關產品的韌體，並建議若無法立即升級韌體，應先移除任何公開共享資源，並只在可靠的網路上使用相關設備。

Go團隊在6月的時候，提出了一個名為try的新內建函數提案，要簡化錯誤處理的語法，消除Go中常被用來進行錯誤處理的樣板if陳述式，不過這項提案受到社群大量的成員反對，而現在提案審核委員Robert Griesemer宣布，提前否決這項提案。

Go核心團隊中的Google工程師Russ Cox從去年8月的時候，開始跟社群溝通錯誤處理的想法，而也這是Go 2草案的一部分，Go 2出現的目的，是要解決Go無法用在大型程式碼庫和開發工作的問題，Russ Cox提到，Go程式之所以沒辦法良好的擴展規模，正是因為錯誤檢查以及錯誤處理的程式碼寫法，一般來說，Go應用程式存在太多的程式碼檢查錯誤，卻沒有足夠的程式碼來處理錯誤。

Russ Cox希望引入更輕量的語法，來取代現在慣用的賦值與if陳述式組和寫法，讓編寫錯誤處理更加簡單，也使得開發者能花更多的時間撰寫真正有生產力的程式碼。錯誤檢查提案建議不更改語言本身，而是使用現有的延遲（Defer）陳述式以及標準函式庫函式來打包錯誤，以最簡單的方法解決大多數常見的問題，而內建try函式是易於實作且直覺的方式，並且完全向後相容，也為擴展機制預留了擴充空間。

有部分人同意Go核心團隊的提案，但更多數的人認為，這項提案在解決一個不是問題的問題。Robert Griesemer提到，在這個提案的討論中，社群成員提到了許多Go核心團隊忽略的重點，包括除錯列印以及分析程式碼覆蓋等功能，而且更重要的是，他們聽到許多人認為，這個提案並非針對一個價值的問題提出解法，雖然核心團隊覺得應該改善Go中的錯誤處理，但是整體社群的意思，反而更傾向於多討論錯誤處理具體需要解決的問題。

由於社群壓倒性的反對聲量，Go核心團隊也就提前否決了這項提案，並承諾在未來，會注重問題的陳述，並且確保在需要解決的問題上，與社群達成共識。

IBM在OSCON 2019大會上推出了線上資料交換中心DAX（Data Asset eXchange），供開發者和資料科學家可以免費使用，具有明確開放資料授權的資料集，以訓練機器學習模型。IBM在2018年的時候，也推出了線上模型交換中心MAX（Model Asset eXchange），提供開發者免費開箱即用的開源機器學習與深度學習模型。

IBM提到，在DAX上發布的資料集，盡可能都會採用Linux基金會社群資料授權協議（CDLA）的開放資料授權框架，讓資料能夠共享與協作，另外，DAX還提供使用者存取IBM和IBM Research資料集。IBM會定期更新DAX上的資料集，而且IBM Cloud和AI服務也會整合DAX，讓用戶使用DAX上的資料集。

雖然線上已經存在各式各樣的資料集，但IBM強調，DAX提供高品質的資料集，資料經過整理並標準化資料的格式和元資料，而多數其他的資料集往往缺少品質與授權的檢查，因此DAX更適合企業使用，以創建端到端深度學習工作負載。

對於電子設備的安全問題，在系統與對接設備相互之間的安全認證上，過去，普遍採用演算法加密的密鑰機制，來維護資訊安全，最近，富士通推出全新認證技術，相當特別，是利用元件的物理特性，為主機系統與連接配件的真偽進行驗證，進一步提升設備安全性。

這種作法稱為鐵電記憶體（Ferroelectric RAM）認證的技術，由於不是用演算法，因此不會有演算法被破解的問題，他們利用了FRAM啟動時，所產生的獨特類比脈衝訊號，在特定頻率上，以其振幅與相位來驗證是否相符。對於企業而言，將能夠避免企業設備誤用未經授權元件，而可能導致的安全與故障問題。

基本上，關於鐵電記憶體技術的應用，已經長達數十年，它是一種非揮發性記憶體，可在沒有電源的情況下保存資料，並具有快速寫入、高耐寫性等優點，目前多應用在工業控制相關產品，例如智慧電表，需要頻繁紀錄用戶用電的資料，或是伺服器的旋轉編碼（Rotary encoder），需要記錄馬達旋轉圈數等。

不過，將FRAM的物理特性用於身分驗證面向，目前只有富士通，該公司指出，每家公司生產的鐵電記憶體，其脈衝電流特徵，都有不同的差異。因此，改用其他品牌FRAM，將無法通過設備驗證，他們並強調，即使透過模擬晶片改變脈衝電流，也無法破解。

已有印表機業者有意採用此新技術，替代之前使用的演算法加密方式

這項技術已經獲得實際應用，富士通透露，日本已有印表機大廠有意正式採用，目前正在導入設計中，並指出與該業者現正採用的加密算法解決方案，兩者成本相差不大。

在應用場景上，以印表機設備與墨水匣而言，雖然現在多已採用配對的加密演算法，來防範未經授權的耗材，然而，隨著駭客技術的精進，其安全機制仍有被破解的狀況。這只是應用實例之一，至於其他可用的場景，他們表示，像是手工具機的電池，以及任何需要耗材的裝置，都可適用此方案來驗證是否為假冒。

對於系統與元件的驗證過程，富士通也有進一步說明。簡單來說，在印表機端裝設嵌入式認證IC元件MB94R340，並與內建的MCU或SoC元件相連接，而在墨水匣端則裝設MB94R350，透過測量電流、數位化與轉換的過程，前者將根據專屬於FRAM的特徵值，在特定頻率上的分量大小，以及相位，來判定對接設備為是否可能為假冒品。

關於電子設備的安全，這也讓我們聯想到，近年資安產業的發展趨勢上，在晶片層級安全，也有名為物理不可仿製功能（Physically Unclonable Function，PUF）的安全技術，也是用於設備身分驗證，可以不像傳統方法，將私鑰存於硬體之中，因此不會有金鑰遺失的風險，在臺灣已有像是旺宏、力旺等業者發展這一領域。

關於FRAM認證與PUF技術的差異，我們也進一步詢問富士通，他們表示，一般PUF是每個同型號元件的特徵皆不同的狀況，而FRAM的特徵在所有同型號元件上，其實都一樣，因此，應用在真偽認證情境上，比對方式可以不用需要建立資料庫。

隨著駭客技術的不斷精進，電子設備安全的認證方式也推陳出新，最近富士推宣布推出無加密演算法的FRAM類比脈衝訊號認證方案，並已有日本印表機大廠有意採用。

過去富士通在2010年也曾提出MB94R330的認證IC方案，對於與新一代技術的差異，富士通表示，MB94R330比起一般以加密技術為基礎的認證IC，優勢在於，Key是儲存在無法被電子顯微鏡讀取的FRAM上，但還是採傳統加密技術（AES）來達到認證目的，與這次新推的MB94R340/MB94R350所使用的原理不同。

去年，澳洲雪梨一場突如其來的冰雹，網球般大小的冰塊從天而降，是當地20年來最嚴重的一場，保險公司收到超過2萬筆理賠申請，其中四分之一是房屋毀損，預估賠償規模達到臺幣數十億元。美國同樣也常發生冰雹災情，一家美國保險公司想到了用AI影像技術，來處理房屋冰雹損傷的檢查，尤其是新舊冰雹損傷的辨識，作為理賠範圍的認定參考。

為了訓練這樣的AI模型，保險公司蒐集了大量受災房屋外觀的高解析度照片，分割成大批小型影像來分析，最後成功訓練出一個來分辨損傷新舊程度的深度學習模型，但是，保險公司卻遇到了一個新挑戰。他們得向保戶解釋，AI如何判斷這個撞痕是「舊傷」，所以，無法理賠。

IBM Watson解決方案亞太區技術長Dev Mookerjee用這個真實例子，來反應AI可解釋性的困難和重要性。法規要求業者必須解釋理賠與否的原因，不能模糊帶過，但Dev Mookerjee坦言，雖然，保險公司已經可以得知，AI透過哪些影像特徵來推論傷痕新舊，「他們仍難以解釋，為什麼這張影像是新損傷的信心值是70%？」這就是AI進入實際生活時遇到的「可解釋性」（AI Explainability）考驗。

隨著AI技術走向應用場景，人們開始參考AI的意見來做決策，例如，銀行用AI來評估借貸人的信用、保險公司用來判讀理賠風險、醫院做為用藥依據等。然而，AI的不可解釋性越來越成為進入實際場域應用的挑戰，可能導致模型判讀受偏誤資料影響卻無從得知，或者因缺乏解釋而難以取信於人。

歐盟去年五月祭出的資料保護規範GDPR（General Data Protection Regulation），其中的「透明處理原則」，就是針對「個人化自動決策」(Automated Individual Decision-Making) ，賦予用戶請求解釋、拒絕適用的權利，更讓AI可解釋性成為所有AI應用都必須解決的課題。

歐盟先將可解釋性AI（Explainable AI，XAI）提升到法律層面來探討後，也讓他國政府開始重新思考AI的應用。例如美國在今年草擬「演算法問責法案」(Algorithmic Accountability Act of 2019)，除了規範個資運用原則，也賦權用戶更正或拒絕個人化自動決策；而亞洲，則有新加坡個人資料保護委員會，今年1月頒布「人工智慧監管模式框架」，規範AI的決策過程必須盡可能的達到可被解釋、透明且公正的目的。

「可解釋性AI無疑是重要的。」IBM Watson解決方案亞太區技術長Dev Mookerjee表示，如果銀行用AI來評估授信放款的風險，那銀行就必須要能解釋，AI決定不借貸給某個客戶的原因，以及決策本身的正確性。

發展可解釋性AI面臨的挑戰

Dev Mookerjee指出，AI可解釋性挑戰主要發生在2大類型的AI模型上，包括深度學習模型，以及用非結構化資料訓練的模型。

近年再次帶起AI應用浪潮的深度學習，最大強項就是，不需要像過去那樣提供規則或特徵，只要準備大量訓練資料，深度學習模型就會自己找出具有預測推論能力的模型，但這也是其缺點，因為「說不出來」為何如此。

Dev Mookerjee表示，儘管結合深度學習與知識圖譜（knowledge Graph）的技術，可以建構出資料之間的關聯，例如透過解析句子與句子之間的語意關係，來優化聊天機器人語意理解模型，但是，知識圖譜仍然只是一種特徵提取的技術，要瞭解聊天機器人如何決策，還是需要其他技術來輔助解釋。

此外，結構化訓練資料又比非結構化的訓練資料更容易被解釋，他以最近正在訓練的一個法律AI模型為例，「這個模型的目的是，在合併和收購討論期間，檢查供應商合約中的智慧財產權重疊部分。」Dev Mookerjee表示，當一個AI模型設定的目標越明確，訓練資料越收斂、不可控的變因越少，模型也就更容易被解釋。這個法律AI模型因為目標明確，也就利用了許多結構化資料。

但是，「加入非結構化資料後，AI解釋的過程就會變困難。」Dev Mookerjee用另一個澳洲政府個人居住補助金發放評估模型為例。澳洲政府綜合了個人資料，加上申請者對於自己處境的描述，去設計一個模型來評估個人居住補助金的發放。這兩種資料的差異是，個資是屬於結構化資料，如性別、年齡、居住地、收入等，用來訓練模型較容易解釋預測結果。而申請者自己的描述性文字，則是一種非結構化資料，可能會包含申請者的家庭關係、工作場景、醫療狀況、心情等複雜因素，並無固定的格式，「往往，1,500字的描述中，約有20%的資料完全用不上。」他坦言。

Dev Mookerjee表示，非結構化的資料除了常見的文字，還包括了圖片、音樂、影片、PDF、網頁，以及網頁上的用戶行為等。儘管非結構資料會影響模型被解釋的程度，但在特定領域，或不需要解釋的應用上，非結構化資料已經被廣泛應用。

反而是，他提醒，還有許多新型態的資料形式，將是可解釋性AI的大挑戰。例如透過聲音發出的頻率去訓練模型，來判斷機器是否有故障風險，又或者無線電波、地質資料的應用，「我們還有很多新形態的資料沒有接觸過。」Dev Mookerjee表示。

LIME可找出影響AI的關鍵特徵

企業應用AI必須有全面性考量，從個人化體驗、資安結構、隱私監管、AI信任和透明度問題等。──IBM Watson解決方案亞太區技術長Dev Mookerjee　（攝影／洪政偉）

難道，可解釋性AI真的無法可解？不，現在有一些作法試圖解釋AI，但還不夠好。

Dev Mookerjee指出，早在2016年，學術圈就提出一個提高AI解釋力的模型設計概念，稱為LIME（Local interpretable model-agnostic explanations）。LIME透過針對一筆訓練資料中的局部特徵（features）進行干擾，來觀察是否會影響預測結果，藉此判斷訓練資料中的哪些特徵，對於模型決策有更關鍵的作用，藉此來找出偏誤（bias）的資料。

例如，用LIME去檢測某客戶申請保險索賠、模型卻判斷有90%不合適的原因，得出「未達年齡限制」影響力佔45%、「索賠頻率過高」佔32%、「女性」占8%，這時候，就能發現性別可能為偏誤的資料，必須重新調整模型；相同的，也能找出另外10%通過的原因，例如「擁有個人帳戶」影響力佔6%等。

雖然LIME可以用來找出偏誤資料，但Dev Mookerjee也強調，並非所有偏誤資料都必須去除，在特定情境下，反而必須維持資料偏誤，才取得相對應的結果，例如，某一類藥物專治女性的某種症狀，儘管這種症狀男女都會有，但在訓練資料中還是必須去除男性的考量。

然而，Dev Mookerjee坦言，即使用了LIME，深度學習模型在信心值的解釋上仍然是挑戰，就像是用影像辨識模型分辨哈士奇和狼時，雖然能夠利用LIME的技術，來找出哪些特徵點是分辨的關鍵，例如眼睛、耳朵比其他特徵更容易影響預測結果，但卻很難解釋，為什麼模型認為這張圖有80%的信心值是狼？而不是90%？這是尚未克服的難題。

對比是提高AI解釋性的另一個作法

針對AI可解釋性難題，Dev Mookerjee表示，IBM還有一項自行研發的技術，稱為「對比解釋方法（Contrastive Explanations Method，CEM）」。

這套方法是透過對比出訓練資料缺少的特徵，對模型表現形成更完整的解釋。舉例來說，流行感冒和肺炎都會有發燒、咳嗽、感冒的症狀，但讓AI模型判斷是流行感冒而非肺炎的原因，是因為病人「沒有」多痰或畏寒的症狀，才做此解釋，這是從對比的方式來解釋模型的預測。

後來，IBM結合LIME和對比解釋方法，發展出了一套試圖用來解釋AI的工具Watson OpenScale，透過輸入資料與預測結果的關聯，找出影響模型決策的因素（factors），進而檢測出偏誤的資料，並自動修正來優化模型。Dev Mookerjee解釋，這就像要了解人類的決定，必須去探討他的出生背景、教育程度、生活經驗，同理，這套方法也適用於AI。

不過，Dev Mookerjee沒有透露，這套工具的AI解釋能力可以做到多好。他僅坦言，目前OpenScale主要用於機器學習模型，由於深度學習又比機器學習更難解釋，是未來要優先發展的重點。除了支援IBM Watson之外，OpenScale也支援Amazon ML和Azure ML等其他雲端業者的AI產品，可用於TensorFlow、Keras、Scikit-Learn，SparkML、PMML等框架建立的模型。

資料隱私必須納入AI應用的框架

除了可解釋性AI是現今AI應用的挑戰，Dev Mookerjee指出，歐盟GDPR嚴格的個資運用規範，同樣帶來了訓練AI模型的資料隱私問題。

Dev Mookerjee表示，由於AI框架並非與隱私直接相關，所以許多人僅將AI視為一種技術，沒有把隱私的框架納入考量，「但當隱私成為特定AI應用的重要考量時，在設計AI框架時就必須納入隱私概念，這是不能妥協的。」這也正是近1年來新興的Privacy by design概念。

舉例來說，近來銀行流行打造Chatbot服務，若要讓用戶可以直接查詢帳戶餘額，得先提供姓名、帳戶、電子郵件等KYC資訊，才能取得對應的結果。此時，若Chatbot部署在公有雲上，「這個看似協助回覆問題的Chatbot，光是傳送個資與資料庫比對、搜尋的過程，就有曝光個資的風險。」Dev Mookerjee表示，在Chatbot服務設計之初，就要考量到與後臺的串接、資料傳送加密，或在架構上將Chatbot部署於私有雲環境。

另外，他提醒，還要將資安與隱私分別處理。保護隱私是因應監管機關要求，以符合法遵要求為主。但「資安防護，則是不論建立基礎設施或chatbot都必須用高標準。」Dev Mookerjee建議企業，開發AI應用時，也可以引進DevSecOps概念，也就是在程式編寫過程就做好資安防範，而非開發人員和資安人員各作各的無交集，「DevSecOps雖是用於開發流程的安全性，但AI開發上也適用。」

在Dev Mookerjee參與的專案中，澳洲有家銀行建置AI環境時，也採用了DevSecOps的概念，在開發每個程式之前，所有參與專案的負責高層、技術人員共24個人，花了6、7個星期一起開會，從底層的基礎設施、資料庫、網路系統、閘道器到網站，將資安與隱私納入考量，「他們不是從法規面來討論，而是從銀行需求面討論如何將資安防護做到最好。」

未來，AI要協助企業做到的，是串接起各式各樣的服務且走向自動化。Dev Mookerjee舉例，當客戶透過chatbot申請失業、要求延遲支付債款時，內部機制將自動對該客戶做標記，一旦付款通知的Email將被發送，系統會因標記而將信件攔下、從名單上移除，讓顧客體驗更即時、私密。

因此，Dev Mookerjee表示，為了提升客戶體驗，企業應用AI時，必須更全面性的考量到許多因素，「從個人化體驗、資安結構、隱私監管到AI的信任和透明度，都必須被重視。」

  CTO小檔案  

IBM Watson解決方案亞太區技術長Dev Mookerjee

學歷：澳洲坎培拉大學資訊碩士、澳洲Macquarie管理研究所商業管理碩士

經歷：2018年開始擔任IBM Watson解決方案亞太區CTO，在加入Watson團隊之前，曾任職IBM全球技術大使，領導亞太區技術團隊發展數據分析、機器學習、AI，擁有近20年社群媒體分析的經驗。

  公司檔案  

IBM

● 網址：www.ibm.com

● 成立時間：1911年

● 總部地址：總部位於美國紐約市，全球177國皆有據點

● 執行長：Virginia Rometty

● 年營收： 2017年791億美元

● 全球員工人數：約36.6萬人（2017年）

  公司大事記 

● 2004年：出售個人電腦事業部門，更聚焦企業市場

● 2009年：買下統計軟體SPSS，強化資料分析技術

● 2011年：IBM 新一代超級電腦 Watson20誕生，也展開了Watson認知服務的品牌和產品線

● 2012年：買下SoftLayer展開雲端布局

● 2014年：出售x86伺服器業務，更聚焦AI和雲端業務

● 2015年：併購兩大產業數據巨頭Merge Healthcare和The WeatherCompany

● 2018年12月：出售Notes/Domino等產品

● 2019年7月：正式以340億美元併購紅帽，大力揮軍AI及混合雲

「小明有20元，小明有5顆蘋果，小華有10顆蘋果，一顆蘋果2元，小明買給小華4顆蘋果，小華吃了一顆，小華剩下幾顆蘋果？」這道小學數學題，你能馬上回答的出來嗎？但是中研院的中文AI對話引擎可以。

臺灣自然輸入法發明人許聞廉表示，因為中文特性，使得語意分析的重要性比國外更重要，這也是以中文為母語的臺灣在地的競爭優勢。。 攝影／洪政偉

去年，中研院智慧型代理人系統實驗室著手打造一套了具有深度理解能力的對談系統，不只能理解中文，還能解答中文描述的小學數學題，正確解出這道數學題的答案是「13顆蘋果」，甚至還可以在答案欄上完整推導運算過程求得答案，就像人類在試卷紙上作答那樣。就算將題目臨時改成「小華蘋果不是10顆，而是8顆，答案是多少？」也都難不倒它，而背後一手打造這套系統的關鍵人物，正是中文自然輸入法發明人，也是現任中央研究院資訊科學研究所特聘研究員許聞廉。

長年在臺從事中文自然語言研究多年的許聞廉，不只是臺灣最早開發出具備中文語意分析能力的自然輸入法的發明者，更是帶動臺灣電腦中文化普及的重要推手。

不同於倉頡等其他中文輸入法，許聞廉開發出的自然輸入法，因為能依照上下文選取同音字，大幅改善了過往以來的中文輸入句子的重音字或搶字難題，所以，1992年一推出就獲得熱烈回響，短短數年內就衝破百萬次下載，即使如今已快屆滿30年，很多企業或個人用戶都仍是它的愛用者，將它當作是辦公室或家中電腦常用的鍵盤打字輸入工具。

但為何會想打造一套臺灣在地的中文注音輸入法？許聞廉回答也很簡單，「就是因為自己需要用到。」他表示，1980年代當時IBM的電腦一推出，顛覆整個文書處理作業方式，從傳統打字機，轉變成以PC為主的鍵盤輸入，但是一直缺乏一個好用的中文輸入法，可以讓他在電腦上流暢打字。於是當時還在國外大學教書的許聞廉，便決定在1989年回臺進到中研院，負責中文輸入法的開發，甚至連鍵盤都自己從頭設計一個專用中文輸入鍵盤，更花了4年時間開發推出首版自然輸入法。

早在10多年前，許聞廉在開發中文自然輸入法時，就已開始結合中文語意分析技術，用於自動選字，讓使用者打字時，只要輸入音節、聲調，由機器依據前後句子，來自動幫你選出適當的用字。

早期中文自然輸入系統，多採用預先寫好的規則腳本來選字

不過，許聞廉表示，早期的中文輸入系統，需透過預先寫好的規則腳本，來判斷前後句子的常用字來自動選字，雖然並未結合機器學習，但也開始採用統計分析方式，來計算出一句話裡的每個字詞組成的出現機率，這也是後來自然語言機器學習技術的發展基礎。

以中文自然輸入法來說，一開始語料庫的建立，是來自紙本新聞，總共蒐集了超過700萬個中文字詞，轉換成電腦可讀的形式，來建立中文語意規則，再套用到注音輸入法的選字規則上。例如，皮膚「科」與「柯」醫師，注音同樣都是念ㄎㄜ，但句子左邊銜接的名詞輸入是皮膚時，經由統計機率的分布，得出指的是看診分類的「科」，就會寫成一種規則，以後當出現類似的前後句子，就會選出這個字；反之，醫師在句子右邊，則是指人名的「柯」，以此類推。

他表示，第一版中文自然輸入法推出時，大約設計了數千到近萬個規則排列，已經可以做到中文自動選字、自動校正。只不過，他坦言，當時的中文輸入系統，在語意分析處理上，還無法像現在的處理量這麼龐大，反應速度也不夠快，常常輸入一個字，就要等待許久，以注音輸入常用的「是」為例，光是同義字就有100多個字，但一開始這套輸入法系統全部安裝完也只才700KB，因此，輸入完常常得等待數秒，經過數十個判斷規則，才能找到正確的用字。或是也無法做到需要更複雜的前後語句判斷來選字。

1992年自然輸入法推出後，至今歷經20多年演進，經過10多次大小改版，除了原有的語意核心之外，也不斷地修正、改進輸入法的中文語意分析能力，來提升選字正確率，甚至也改安裝在運算力更強的硬體上執行，而且還能跨不同作業環境，除了微軟Windows，也支援了蘋果Mac OS。

不只是中文輸入，許聞廉後來也將中文語意分析技術，用來建立一套自動問答系統。雖然一開始功能還很陽春，只能回答基本題，但已跨出臺灣中文自然語言技術發展的一大步，除了先在中研院內部使用，來回答有關中研院生活資訊相關事項，2000年時，他更與寶來證券合作，讓這套問答系統能以網路客服形式來回答用戶提問，也是當時最早推出自動問答服務的企業網站。後來還採更進階統計分析的機器學習方法，來協助語意規則的建立，以提升中文問答能力。

大約2010年以後，類神經深度學習技術的出現，則是更進一步了帶動自然語言處理技術的更大突破，從大量語料學習不同詞彙所要表達的語義，來達到語意的理解，也是當前自然語言處理最熱門的研究。

雖然深度學習技術有其發展優勢，不過，許聞廉表示，不像影像辨識，不需要用到理解，所以深度學習可以發揮出很好的效果，「但換成是辨識中文語意，要做到自然語言理解需要的語意分析，達到中文理解面，深度學習就不太行，特別是在處理需要包含推論的多輪式對談上。」他說。

他進一步說明，因為深度學習是以數學函數來表達學習到的建構模式，缺乏對於文字本身語法、語義分析，還有背景知識的理解，僅通過從大量中文語料學習，而沒有經過任何複雜的語法拆解、語義分析等語意理解過程，一旦遇到需要理解力的問題時，機器就很容易看不懂。

以一個簡單數學題為例，「當你身上有100元，父親再給了你20元，就能買一輛腳踏車，所以腳踏車多少錢？」，因為敘述中出現「再給」的用語，代表「金額增加20元」的概念，所以答案是介於100元到120元之間，一般人理解上很容易，但是機器要回答就不是容易的事，「而只有當機器給出了正確答案，才代表它看懂這句話的意思，也就達到了理解。」他說。

中研院研發國產AI問答引擎，連數學題也能作答

為了讓AI做到理解面，許聞廉與實驗室團隊自去年起也採用了新的語意理解技術，來設計出新一代問答系統，來打造出一套具備深度中文理解能力的全新問答系統。

有別於傳統問答系統，他表示，這代問答系統採用了準則式（Principle-based）語意理解技術，這是一個全新的機器學習語言模型，尤其適合用在語意相似的描述，可以有更清楚的分辨力，結合了傳統規則式（Rule-based）與統計（Statistical）兩類作法的優點，不只能對於題目進行分析，能看懂每一個句子給出的假設條件，還能理解句子背後隱藏的意圖，才能在看完一連串敘述後，由已知條件推導正確回答出「小華剩下13顆蘋果」的答案，即使換個問法也難不倒它。「這也是機器要學習最困難的地方，」他表示，截至目前，這套系統已經能夠自動解答小學三年級的數學應用題，可以扮演起教學助理的角色，來幫助小學生更容易學習。未來還有英文版本。

除了自動問答以外，近年來，語意分析技術也被用在具備有對話式、自動化的Chatbot（聊天機器人），或是會講話的智慧喇叭。這些輸入介面或操作方式的不同，也帶來中文自然語言處理上的一大挑戰。

以中文語音輸入為例，許聞廉認為，就比注音輸入在語意分析處理上，更容易造成混淆，而影響了辨識的正確率。例如注音輸入，是以音節、聲調的抑揚頓挫來在鍵盤上選字，但改用語音輸入後，以口說的方式將聲音轉成文字，很容易會受到外在環境的影響，例如說出一個音節，機器可能聽錯成3個不同高低聲調，混淆度就增加為原本的3倍，如此一來，辨識的準確度就可能會受影響。

尤其，中文的語法結構鬆散，以達到雙方溝通為目的，一句話有時可以出現複數動詞、倒裝語序，或是省略用法，但英文就不行，這些語言上的用法差異，造成中文比英文更難理解，人類學習是如此，機器當然也是。

「這也是以中文為母語的臺灣的競爭優勢，」許聞廉指出，要做到中文的理解面，語意分析能力就十分重要，必須是要對於中文句子背後的語法、語義分析，還有背景知識結構有清楚透徹地了解，才可以把中文自然語言系統做得更好。也正是因為中文特性，使得中文語意分析的重要性比國外更重要，不像英文語句有很多剖析方式，可以提升它的正確率，但中文就不行，他強調：「中文自然語言技術是臺灣在地AI很重要的基礎力。」

對於近兩年，語音辨識、語音互動等語音應用在全球迅速竄紅，也吹進臺灣，甚至不少專家都預言，語音輸入將會是未來各種應用程式或裝置的下一代互動介面，甚至可能會取代鍵盤，但許聞廉則持不同看法，他反倒認為，兩者將會併存，並不會因為有了語音輸入，以後就不需要鍵盤。

他解釋，語音輸入有其便利性，尤其是在不適合攜帶或放置鍵盤的地方，就很適合用它來操作，例如家中廚房、汽車等，但如果是需要大量文字輸入為主的中文輸入作業，未來仍需鍵盤輔助。整理⊙李岷錡、文⊙余至浩

專家小檔案

許聞廉

● 職稱：中央研究院資訊科學所特聘研究員

● 研究團隊: 智慧型代理人系統實驗室

● 代表成果：1992年發明自然語言輸入法

● 最新進展：2018年新一代問答系統，能理解和解答中文描述的小學數學題

07/06~07/19精選AR‧VR新聞

 沃爾瑪   AR  

美國沃爾瑪開始將VR培訓評估成果，列入全美5千家店管理者的績效考核指標

美國實體零售巨頭沃爾瑪（Wal-Mart）從去年開始在店內導入VR技術培訓新進員工，日前，該公司更進一步以VR培訓來做為中階管理者未來工作績效與升遷的考核依據，將VR視為是推動核心零售業務的關鍵指標，來提供顧客一致體驗。沃爾瑪也再次與VR培訓新創Strivr合作，將這項VR技能評估計畫推向中階管理者，用以測試這些管理者如何妥善應對VR模擬各種購物狀況，例如不理性消費者或表現不佳的員工，來決定誰該加薪或減薪。如今沃爾瑪在全美5千家店已配置了至少17,000個臉書Oculus Go裝置，今年2月為止，全美120萬名員工裡已有1萬人接受過這項VR培訓。

建築AR    日本BPM  

建築物維護管理也導入AR，日本建築SaaS服務商BPM試用AR來簡化建物維護流程

以提供建築SaaS維護服務為主的日本BPM公司，最近利用AR技術開發出了一款AR應用程式Qosmos AR，可以用來記錄和保存建築物或施工現場的所有照片與訊息，該App使用AR技術識別坐標，可以數據方式再現建築物裡的空間訊息，並建立出一個3D立體模型，可以根據這個3D模型檢查照片，或是在上面加註標記。通過虛實整合的方式，讓維護或建築人員，即使人還沒進到現場，也能夠提前掌握該建築的空間配置，知道目前各樓層的設施分布狀況，也能調出過往維修記錄等，以簡化維護或檢修流程。目前該App已在iOS平臺上架推出。

機器人協同    VR  

克服遠距通訊延遲的挑戰，日本機器人協同新創展示VR遠端遙控新技術

日本機器人協同新創SE4，日前在SIGGRAPH技術會議上展示一項機器人VR遠端遙控新技術，可以在遠距或通訊延遲的場所，也能夠使用VR來控制遠處的機器手臂，完成精確且快速地操作，靠的是不以手動完成所有操作，而是以模擬方式來傳達想執行的動作，機器手臂就可以依據少量指令來執行任務，不需要一個動作一個指令。使用者只要戴上VR頭戴設備，就可以機器手臂的視角來進行操作，並在VR環境裡模擬出真實世界的物件位置，只要透過手上的控制器，傳達想要執行的動作，就可以控制手臂上下移動、搬運物件，例如可以將這些散落物件排列組合或重新堆疊成為成品，SE4表示，透過這種方式，未來將可用於高危險性的現場施工作業，以減少施工的風險。

Gucci   AR  

Gucci推出潮鞋AR虛擬試穿服務，讓消費者能先試穿滿意再購買

義大利時裝品牌Gucci日前也替自家Gucci App加入擴增實境（AR）功能，用來展示與銷售自家品牌的最新鞋款。Gucci採用了俄羅斯AR新創Wannaby的AR技術，用於提高自家網購體驗，讓消費者在購買之前，能先以AR方式試穿看看鞋子尺寸合不合腳，再決定要不要購買，只要打開手機App，開啟AR功能，對準自己的雙腳，就能將這雙虛擬鞋子套用在自己的腳上，還能改變鞋子款式、顏色，找出適合自己的穿搭風格，也能夠將試穿照片上傳與朋友分享。不過目前只有Ace系列運動鞋有提供AR試穿功能，且僅適用於iOS平臺。

VR    行動處理器  

鎖定混合實境需求，高通新一代行動處理器Snapdragon 855 Plus，提升15%繪圖效能

高通（Qualcomm）近日發表了新一代的行動處理器Snapdragon 855 Plus，鎖定未來的混合實境或遊戲的應用需求，特別強化了GPU繪圖效能，使得GPU效能比上一代的Snapdragon 855提升了15%。雖然同樣採用的是Adreno 640 GPU，不過新一代GPU的核心時脈達到672MHz，相較之下，前代GPU時脈則是585MHz。另外，新款CPU的時脈也提高為2.96GHz，也獲得4%的效能提升。Snapdragon 855 Plus與上一代同樣都支援5G、遊戲、人工智慧及混合實境，只是效能更上一層，高通表示，今年下半年就會見到採用Snapdragon 855 Plus的行動裝置。

藥物開發   VR  

英生技藥物研發商開發一套VR藥物開發平臺，能以VR將複雜分子視覺化協助新藥開發

英國生技藥物研發公司4X Discovery近日展示了一套VR藥物治療開發軟體平臺4Sight，結合VR技術，用來協助開發新藥，用以對抗如阿茲海默症、帕金森氏症等不治之症。這套軟體採用了Unreal Engine遊戲引擎為核心，並透過VR立體呈現技術，將複雜分子的結構視覺化，方便研究人員觀察，以更近距離方式進行研究並與其互動。 該公司表示，傳統上，科學家使用實體模型來呈現藥物分子結構，但是透過這個VR工具，則可讓藥物開發者以徒手方式，抓取這些虛擬藥物分子，來觀察它們如何作用與反應，只要戴上VR頭戴裝置就能進行操作，4X Discovery指出，這項技術將有助於縮短藥物開發流程，來應對各種新型疾病。4X Discovery近日也與英國生物製藥PhoreMost合作，計畫將自有技術用於開發新藥物治療帕金森氏症。

三星   AR眼鏡  

三星提交新專利申請，暗示正在研發可摺疊收納的AR眼鏡

前不久，就有傳言三星將於未來數個月內發表多款AR/VR頭戴裝置產品，近日也被人發現，三星在最新提交美國專利商標局的一分專利文件中，揭露其正在開發一款AR眼鏡頭戴設備。 根據這分文件的披露，這副AR眼鏡外型看起來就像太陽眼鏡，不只具有簡約的造型，甚至可以摺疊收納，而與Oakley、Bose等公司的藍牙眼鏡很大不同，三星在這個AR眼鏡上面特別設計一個迷你方型顯示螢幕，以便於可以透過這個螢幕將虛擬物件疊加在真實世界，讓使用者觀看並可與其互動。甚至在眼鏡上沒有加裝電源鍵，只要打開眼鏡就能自動供電，將眼鏡折疊就能關上，從而節省電源。不過，三星對此並未進一步回應。責任編輯／余至浩

圖片來源／沃爾瑪、Strivr、BPM、SE4、Gucci、C4X Discovery、三星

 更多AR‧VR動態 

1.傳蘋果已中止AR眼鏡的開發工作，原AR開發團隊已解散

2.不再出貨？微軟悄悄將戴爾、華碩等多款Windows MR頭戴設備從自家商店下架

3.AR預測：全球AR零售市場自今年將逐年看漲，6年後將突破170億美元大關

4.Valve推出開放實驗計畫Steam Labs，供玩家測試實驗性功能

資料來源：iThome整理，2019年07月

在錯誤處理方面，JavaScript一開始只有try/catch/finally，以及幾個內建的錯誤類型，簡單到令人訝異，隨著應用層面增多與規範的發展，在錯誤處理這方面，應是值得重視的一環。

有限的標準錯誤類型

雖然JavaScript有try/catch/finally/throw等錯誤處理相關語法，也有Error等錯誤類型，然而，相對於其他程式語言的錯誤處理機制來說，似乎過於精簡，原因之一在於，JavaScript最初執行於瀏覽器，可用的資源相對有限，若有錯誤發生，通常就是難以處理或不該處理的情況，內建標準錯誤類型都有個Error字眼（而不是Exception），也反映這個事實。

另一方面，只能有一個catch區塊，由於catch的語法本身無法區別型態，若要判定錯誤類型，必須自行使用if結合instanceof判斷，ES10甚至還有個〈Optional catch binding〉（https://bit.ly/2McB9ui），若catch後不需要錯誤實例，可以不用直接寫catch就好了，不需要括號與參考錯誤實例的名稱。

在類型的數量上，通用的Error加上其子類型，總共才7個錯誤類型（其中SyntaxError其實無法catch處理），但這並不是表示錯誤處理在JavaScript中不重要，而是因為ECMAScript僅規範語言本身，標準錯誤類型如SyntaxError、ReferenceError、TypeError等，多半也是跟語言本身相關的錯誤，至於不同環境或程式庫的錯誤類型，是由各個環境自行實作。

例如，在XMLHttpRequest的規範中，就有DOMException、SecurityError等例外類型，而在Node.js將JavaScript帶出瀏覽器之後，環境不再受限，但情況也變得複雜許多。例如，Node.js定義了自己的一套錯誤類型，像是AssertionError、SystemError等，基本上，Node.js是JavaScript後端的產業標準，對於Error本身，也不客氣地擴充了一些特性，這可以在Node.js官方的〈Errors〉中查詢。

自訂錯誤類型

雖然撰寫程式時若要拋出錯誤，使用ES標準本身的7個錯誤類型也可以，不過，建議還是為應用程式或程式庫自訂錯誤類型。

JavaScript的錯誤處理語法，基本上借鏡Java，而Java對例外的區分方式就像〈Error Handling in Node.js〉（https://bit.ly/2ek7IAd），將錯誤分為操作錯誤（Operational errors），以及程式設計者錯誤（Programmer errors），就有異曲同工之處。

關於程式設計者錯誤，顧名思義，導因於開發者撰寫的程式本身有臭蟲，無論是邏輯、流程或是類型上的錯誤，這類錯誤最好的處理方式就是不處理（令程式中止），並透過瀏覽器中的開發者工具，例如除錯器（Debugger）來糾出、修正這類臭蟲，要類比的話，就像是Java裡頭的執行時期錯誤。

而操作錯誤，並非程式臭蟲引發，而是來自系統環境，像是錯誤的使用者輸入、無法獲取網路連線或其他環境資源的問題，必要時，須用try/catch/finally等語法來處理。這就像Java裡頭的受檢例外，當然，JavaScript並沒有強制處理錯誤的機制，但概念是相同的。因此，根據不同狀況，可以繼承Error來自訂操作錯誤類型，以及程式設計者錯誤類型。

在自訂錯誤時，要注意Error的標準特性只有message與name──message為實例擁有，是建立實例時指定的錯誤訊息，name則是定義在原型物件上代表錯誤類型的名稱。它們的writable與configurable為true，enumerable為false，在繼承Error定義子類型時，最好遵照這些屬性的設定，透過Object.defineProperty設定，至於相關程式範例，我們可參考〈Subclassing `Error` in modern JavaScript〉。

錯誤處理時重要的訊息是堆疊追蹤，但大部份瀏覽器或Node.js僅支援非標準的stack特性。也因為非標準，建議僅在開發階段使用，倒是TC39有個階段一的〈Error Stacks〉提案，打算將stack標準化；在Node.js，我們還能用Error.captureStackTrace來處理堆疊追蹤，可參考〈Extending Error in Javascript〉。

非同步與錯誤處理

JavaScript雖然提供try/catch/finally語法來處理錯誤，然而，這些語法是同步情境，若在try區塊進行非同步操作，錯誤發生時，是不會對應的catch區塊捕捉的（因執行流程早已離開try區塊）。為處理這類問題，早期非同步操作在接受回呼函式時，回呼函式本身須有個參數接受錯誤實例，並在回呼函式檢查是否傳入錯誤實例，藉此處理相對應的錯誤。

這類回呼模式易引發回呼地獄（callback hell），ES6為此規範了Promise，在建立Promise實例時，指定的回呼中可以拋出錯誤，此時，會隱含地使用錯誤物件作為引數來駁回（reject）約定，如果想要處理例外，我們可以在Promise實例的then方法第二個參數指定函式，或者使用catch方法來處理──差別在於，前者處理後例外還會傳播，而後者不會。

在建立Promise的回呼中拋出錯誤，其實是不建議的，明確地建立錯誤實例作為引數，並呼叫駁回函式是更好的做法。如果Prmise被駁回、又沒有在then或catch中處理，最後是由不同環境實作自行決定處理方式，在瀏覽器中，我們可以透過註冊unhandledrejection事件來處理，若沒有阻止事件傳播，錯誤訊息最後會輸出至主控臺。

在Node.js中，Prmise被駁回若沒有處理，可以透過process.on來註冊unhandledRejection事件處理，若沒有處理會產生UnhandledPromiseRejectionWarning，然而，這個行為已棄用，未來會採中斷程式的作法；對於最後一定得進行的資源收尾動作，ES9為Promise增加了finally方法。

Promise雖然解決回呼地獄的問題，但回呼函式的形式，可讀性並不是很好，為此，ES8增加async語法，我們可以使用同步風格的程式碼來構築非同步流程──async函式執行完，會傳回Promise實例；函式流程中若以return結束，相當於解析（resolve），return的值會是解析時傳給解析函式的值；函式中若拋出錯誤，相當於以錯誤實例作為引數進行駁回。

如果函式傳回Promise，ES8提供了await語法與之搭配；若Promise尚未解析或駁回，執行流程會轉移，若流程又回到await而Promise已經解析，await會取得解析的結果值。因此，就程式碼的閱讀上，await就像是等待Promise的執行結果，取得結果後流程才繼續往下運行，若Promise實際上被駁回，那麼，駁回時指定的錯誤實例，會在await處拋出。

也就是說，async/await的情況下，若要處理例外，就可以使用傳統的try/catch/finally語法，例如，若thisThrows為async函式，本體內容為throw new Error("Shit happens!!")，那麼，底下的程式可以捕捉例外，並顯示Error的訊息：

try {await thisThrows();} catch(e) {console.log(e.message);}

這只是個簡單示範，實際上，要考慮的情況還有更多，有興趣的話，我們可以進一步參考〈Error handling with Async/Await in JS〉。

簡單只是表象

在JavaScript的書籍中，很少探討錯誤處理，有的話也只是極少的篇幅，但千萬別被騙了，由於有著不同的環境實作，加上非同步的天性，JavaScript的錯誤處理，其實是比不少語言來得複雜。

或者應該說，錯誤處理從來就不是簡單的事，無論是在哪種語言或環境中，都應思考錯誤處理的差異性，而不單止於語言本身提供的錯誤處理機制是否簡單這件事上。

重點新聞(0712～0718)

  阿里巴巴   開源       小米  

阿里巴巴、百度、小米開源自家SOTA等級的研究

近日3家中國科技龍頭開源自家SOTA等級的研究，包括阿里巴巴、百度和小米。其中，阿里巴巴達摩院開源新一代人機對話模型ESIM，曾在由微軟和卡內基美隆大學舉辦的國際對話系統挑戰賽中拿下雙冠軍，將人機對話準確度的世界紀錄提高至94.1％，也已應用於中國地鐵訂票系統。百度則開源自駕車系統Apollo 5.0，提供進階的深度學習感知模型和360度可視性，來因應複雜的道路狀況。

小米AI實驗室則開源公平神經架構搜尋（FairNAS）方法，該方法在訓練和繼承過程中給予嚴格的公平性，主張公平的採樣方式和訓練可發揮各模組優勢。結果顯示，FairNAS的超網（Superweb）展現良好的收斂性和極高的準確度，其中，FairNAS-A在ImageNet上Top-1驗證準確度為75.34％，FairNAS-B則是75.10％。

Google     資料回音     模型訓練  

Google Brain發表新技術「資料回音」要加速AI模型訓練時間

Google Brain提出一套資料回音（Data Echoing）新方法，要來加速I/O和資料前處理等AI加速器無法派上用場的初期工作流程，讓整體AI模型訓練更快速。

在典型的訓練流程中，AI系統會先讀取輸入的資料並解碼，再將資料交錯運算、採用資料增強（Data augmentation），接著將樣本集合批次處理，並迭代更新參數以減少錯誤。研究團隊的資料回音方法，就是在這個流程中新增一個階段，也就是在參數更新前，重複輸出前一階段的資料，來善用閒置的運算能力。實驗時，團隊用資料回音演算法來評估以開源資料集訓練AI模型的時間，包括2個語言建模任務、2個影像分類任務和1個物體偵測任務，結果發現，資料回音可減少訓練AI模型所需的樣本，而且在工作流程中越早進行資料回音，所減少的樣本也就越多，來優化整個流程。（詳全文）

  DeepMind     BigBiGAN    影像生成  

DeepMind打造超強影像生成模型BigBiGAN

DeepMind近日發表了一款非監督特徵學習新模型BigBiGAN，也就是一款雙向GAN模型，結合了時下最先進的2種GAN模型：BigGAN和BiGAN，並以BigGAN為生成器，透過新增編碼器和修改鑑別器，來提高其特徵學習的表現，同時改善了BiGAN的DCGAN架構無法對高解析度影像建模的問題。

在實驗中，研究員利用ImageNet上未標註的影像資料來預訓練BigBiGAN，並利用標註的資料來訓練一層線性分類器。實驗結果發現，BigBiGAN可以提高非監督學習，將top-1準確度從55.4％拉升至60.8％。（詳全文）

  Google     Nvidia     MLPerf  

Google和Nvidia打破ML基準測試MLPerf紀錄

Google和Nvidia贏過40多家科技界和學術界龍頭，創下MLPerf競賽最新紀錄，在6項ML模型基準測試中拿下最快訓練時間紀錄。MLPerf是一項業界用來衡量ML模型性能的基準測試，測量類別包括影像分類、物體偵測、翻譯、下圍棋等。這次競賽吸引40多家科技龍頭和頂尖大學的AI研究員參加，像是Google、Nvidia、AMD、臉書、英特爾、阿里巴巴、百度等。

其中，在輕量物體偵測和非迴歸翻譯任務中，Google Cloud TPU v3 Pod訓練Transformer和物體偵測SSD模型的時間，比起時下最快的on premise系統，還要快上84％。而Nvidia Tesla V100 Tensor Core GPU表現也十分出色，搭配自家DGX SuperPOD，將ResNet-50影像分類的訓練時間縮短至80秒；2年前，Nvidia用DGX-1系統和V100 GPU，也要花8個小時才能完成。（詳全文）

  臉書   CMU     撲克牌 

心理戰沒在怕！臉書與CMU共同打造的AI機器人擊敗5名德州撲克專家

臉書近日與卡內基美隆大學（CMU）共同開發的AI機器人Pluribus，已在無限注的賽局中打敗5名德州撲克專家，立下新的AI里程碑。在德州撲克中，較勁的不只是牌運，還有牌值的機率與下注時的心理戰，過去已有AI能夠在德州撲克中擊敗單一對手，而Pluribus則是一次擊敗牌桌上5名專家，其中兩名還是世界撲克大賽冠軍。

Pluribus除了利用新的網路搜尋演算法來評估可能的選項外，也採用新的自我對奕演算法來應付隱藏資訊，這些技術讓Pluribus的訓練更有效率，只使用少量記憶體資源，換算成雲端運算資源支出才150美元。Pluribus的特別之處在於它捨棄了雙人對奕所使用的零和博弈政策，而是建立一個憑經驗持續擊敗眾多高手的AI；也創造出一個可察覺隱藏資訊的AI機器人。（詳全文）

Hadoop    Cloudera     大數據  

Cloudera宣布商業授權將完全採用訂閱制

Cloudera發布新的開源授權模式，將在接下來幾個月內推出。該公司目前正在進行更新授權的前置工作，在未來6個月內，Cloudera會將少量閉源授權的專案，如Cloudera Manager、Cloudera Navigator和Cloudera Data Science Workbench等轉換成開源授權，用戶需要訂閱才能獲得專業支援。而Cloudera所使用的開源授權，將採由OSI認證的授權模式，包括Apache License v2與AGPL v3兩種。

雖然Cloudera是開源專案的主要貢獻者，但是過去其商業模式仍主要是銷售授權軟體，而今年1月整併Hortonworks之後，Cloudera打算採用Hortonworks的開源商業模式，並宣布將使用類似紅帽等企業的開源戰略，提供訂閱制。Cloudera會為開發人員和試用提供無支援的免費版本，並向商業用戶提供訂閱付費的版本，訂閱協議涵蓋了支援以及維護，用戶將能存取最新的更新以及安全補丁。（詳全文）

CES    科技部     新創 

前進CES 2020！科技部號召80組新創團隊，要打響臺灣新創名聲

科技部宣布明年要三度帶領臺灣新創團隊赴美參加世界科技廠商盛會CES，即日起開放新創團隊徵案，也號召地方政府新創育成計畫中的新創加入，報名截止日為8月15日，獲選結果將於9月16日公告。科技部次長許有進表示，自2018年來，科技部開始帶領臺灣新創團隊赴CES參展，更設置臺灣館來吸引國際目光；前年，臺灣參展團隊為32組，今年則是44組，範圍涵蓋車聯網、智慧零售、智慧醫療、智慧寵物等領域，其中更有8組獲得新創大獎，獲獎數全球第二，也拿下55億新臺幣訂單，科技部更決定明年要帶80組新創團隊進駐CES臺灣館。

如同以往，今年徵選結果公布後，科技部將於10月進行Boot Camp，請來矽谷業師1對1輔導新創團隊簡報技巧，以及如何將商業模式調整為符合美國市場所需。CES結束後，科技部也將帶領臺灣新創制矽谷參加臺灣Demo Day，讓團隊直接與國外創投、加速器和TA等面對面交流。（詳全文）

神經機器翻譯     Googl      即時翻譯  

納入神經機器翻譯技術，Google翻譯App再升級！

Google翻譯App中的即時鏡頭翻譯功能再升級，除了將支援語言新增至100多種，還納入了神經機器翻譯技術（NMT），讓即時翻譯更精準。Google表示，Google翻譯App中的即時鏡頭翻譯，可將畫面中的文字翻譯為另一種語言，也支援離線使用。而這次功能更新，則將原本支援的88種語言新增至100種以上，包括了阿拉伯文、印度文、馬來文、泰文和越南文等，而且還可選擇英文以外的翻譯，比如將阿拉伯文譯為法文，這是舊版所沒有的。

此外，Google還在這次更新加入了NMT，提高譯文的準確性和自然性。因為，相較於傳統的片語機器翻譯（PBMT），NMT將整個句子視為1個翻譯單位，而非將句子分解為片語和單字，降低了逐字翻譯的錯誤。而Google開發的GNMT利用零點翻譯（Zero-shot），使兩種語言可直接互譯，不需要透過英語作為中介語。（詳全文）

圖片來源／小米、Google、臉書、科技部

 AI趨勢近期新聞 

1. 亞洲生技大會首次登臺！聚焦精準醫療、AI應用和細胞與基因治療，7/24開跑

2. 微軟發起AI救文化遺產計畫

3. 卡內基美隆大學發表Language2Pose模型，可將文字轉換為動畫

資料來源：iThome整理，2019年7月

研究人員發現藍牙協定漏洞，可讓攻擊者追蹤iOS、Mac、Windows 10裝置，甚至包括Fitbit及智慧筆的位置。

波士頓大學工程學院電子電機系教授David Starobinski及研究生Johannes Becker近日發現這項漏洞，並在瑞典斯德哥爾摩一場研討會公佈其研究。

這項漏洞出在藍牙裝置彼此建立通訊連線過程中。當兩個裝置建立連線時會形成主從位階，例如iPhone和藍牙耳機連線時，iPhone為中心裝置，掃瞄周邊裝置如藍牙耳機廣播出的訊號。這類訊號包含獨特裝置地址及與連線相關資訊（稱為辨識代碼）。而為防追蹤，大部份裝置會另外隨機產生一組地址，而非獨特的永久地址以用於連線時廣播，這組地址也會自動更新。

但是研究人員發現這類設計有個瑕疵而使得裝置地址即使不斷改變也可以追蹤。他們發現辨識代碼更新率和隨機地址更新並不同步，這使得藍牙裝置之間的通信訊號點出現了可辨識的固定分佈區。發現這個漏洞後，研究人員利用現有開源的sniffer演算法改造成他們稱為「位置持有（address-carryover）」的演算法，來追蹤藍牙裝置並針對Android、iOS、Mac、Windows 10及一些可藍牙連線的裝置如Fitbit進行測試。

測試結果顯示，Android裝置不會產生可被辨識出的通信訊號點，即不會洩露其位置。但Windwows 10、macOS和iOS裝置全都會現形。不但如此，研究人員還發現Fitbit等穿戴裝置、智慧筆甚至不會隨機產生地址，成為風險最高的族群。

研究人員強調，這個過程完全不需任何駭客技巧，因為辨識代碼及裝置位址都是以明碼傳輸，演算法只是聽取公開傳輸的訊息。雖然這類安全漏洞不會洩露個資，但是駭客可用它來建立殭屍網路以追蹤個別一台裝置，或結合Wi-Fi連線的IoT裝置蒐集到更個人化的資訊，以建構出特定用戶更詳細的生活樣態。

還好Windows 10、iOS、macOS裝置只要關閉再重開藍牙連線，就能「關閉」安全漏洞。至於Fitbit和智慧筆等產品，研究人員表示用戶幾乎無能為力。

安全研究人員發現包括宏碁、技嘉、聯想等8家伺服器業者特定產品使用第三方的韌體產品有漏洞，可能導致伺服器遭駭客執行任意程式碼攻擊。

安全廠商Eclypsium在檢視企業產品的韌體安全時，發現聯想2014年推出搭載Intel Ivy Bridge晶片的1U伺服器ThinkServer RD340有二項重大漏洞。仔細追蹤發現出在其採用的ASPEED AST2300主機板管理控制器（Baseboard Management controller，BMC）第三方韌體名為MergePoint EMC，這款產品是由Avocent提供，後者現為Vertiv旗下子公司。

除了ThinkServer RD340外，聯想其他新款System x 及ThinkSystem 伺服器也使用此款BMC韌體，包括ThinkSystem SR630 G6。

研究人員發現這款BMC韌體有不少客戶，包括主機板大廠技嘉旗下多款搭載Vertiv/Avocent BMC的商用伺服器（Enterprise Server）產品線。技嘉主機板也賣給其他廠商組裝成自有伺服器。研究人員指出，技嘉產品使用有問題的BMC為ASPEED AST2400及ASPEED AST2500。

其他使用MergePoint EMC韌體的伺服器廠商，還有宏碁、大兆（Bigtera）、AMAX、Ciara、Penguin Computing、sysGen等6家。

研究人員在MergePoint EMC上發現到的二個漏洞中，其一是在BMC韌體接收更新並寫入SPI快閃記憶體前未做加密簽章驗證。第二項漏洞則是韌體更新行程本身有指令注入漏洞。兩項漏洞都能讓攻擊者利用主機管理員權限在韌體執行任意程式碼，並對BMC中的SPI快閃記憶體內容進行永久變更。這使攻擊程式得以長期潛伏於系統中而無法為普通的安全措施，像是重灌作業系統消滅。攻擊者也能變更BMC環境，來防止未來透過軟體機制更新韌體，達到讓BMC永久當掉的目的。上述二種情形唯一解法，是以Dediprog或其他程式重刷SPI晶片。

此外，由於可在BMC LAN介面上建立IPMI（Intelligent Platform Management Interface）通訊，因此如果攻擊者能取得BMC的管理員密碼，則還能遠端開採這些漏洞，這在IPMI群組環境下尤其容易，因為所有成員可共用管理員憑證。

研究人員分別在去年7月及今年5月通知聯想和技嘉，也在今年4月通知了Vertiv公司。聯想證實ThinkServer RD340有此問題，並於去年11月發佈安全公告以及修補程式解決指令注入漏洞。

技嘉則在今年5月8日修補了AST2500平台韌體中的指令注入漏洞，但截至6月21日，AST2400平台仍未更新。

研究人員指出，這突顯資訊產業的重大問題，大部份硬體廠商仰賴第三方韌體，使得同樣漏洞可能波及眾多品牌。為防安全威脅蔓延，硬體廠商使用前必須徹底檢查授權使用的第三方韌體。