從產品型號看起來，FlashSystem 7200、9200與9200R這幾款產品，只是IBM FlashSystem儲存陣列家族的新一代機型，但實際上，上述產品的推出，是IBM將FlashSystem與Storwize兩條歷史悠久的儲存產品線，整併為一的成果。

原本FlashSystem與Storwize兩條產品線各有專攻領域，前者針對全固態儲存應用的高階市場；後者透過儲存虛擬化與軟體定義儲存架構，主打中低階市場。但隨著市場競爭帶來的用戶需求變化，讓兩條產品線出現了交集。

為解決FlashSystem系列缺乏資料服務功能的問題，IBM在2014年下半年時，推出SVC控制器結合FlashSystem組成的FlashSystem V系列。接著在2018年中時，又推出基於SVC/Storwize軟體核心，但掛著FlashSystem品牌的FlashSystem 9100。

而FlashSystem 9100的推出，也預示了FlashSystem與Storwize兩條產品線未來的發展方向。很快的，IBM便在2020年初推動了進一步的整併，將FlashSystem與Storwize正式合而為一，留下來的品牌雖然是FlashSystem，但系統核心軟體則是Storwize，加上源自FlashSystem的Flash Core儲存模組技術。所以，新一代FlashSystem，算是披著FlashSystem品牌外皮，但核心是SVC/Storwize的產品。

原有FlashSystem與Storwize產品線中，IBM只保留Storwize系列的V5000與V5100，分別更名為FlashSystem 5000與5100繼續銷售。至於其餘產品，都將由FlashSystem 7200、9200與9200R這3款新一代FlashSystem取代。

當中的7200為混合陣列，可取代舊的FlashSystem 900與Stowize V7000，9200則取代原有的V9000與9100，9200R則是9200的4路叢集組態產品，用於接替原有的A9000R。這3款新機型都擁有相當高的硬體規格，控制器搭載了32核～256核的Intel Xeon Cascade Lake處理器、硬體壓縮卡，以及最大1.5TB（7200與9200）到6TB（9200R）的快取記憶體。儲存裝置能支援IBM自身的NVMe介面Flash Core儲存模組、標準的2.5吋NVMe SSD，或是Intel與三星的儲存級記憶體模組（SCM）。

主機端介面則支援10/25GbE、16/32Gb FC，以及架構在25GbE與32Gb FC上的NVMe-oF，未來還預定支援50/100GbE。至於軟體核心，則是延續自SVC/Storwize平臺的Spectrum Virtualize 8.3.1版。

而憑藉著高規格的控制器核心，與NVMe傳輸架構，新一代的FlashSystem效能有顯著的提升，如7200擁有230萬IOPS效能，9200則達到450萬IOPS，都超出以往的中階儲存產品層次，後者已達到高階儲存的入門等級。而結合4座9200而成的9200R，更可提供高達1,800萬IOPS的效能，單就效能而言，實際上已達到頂尖的高階儲存等級。

新世代FlashSystem儲存陣列家族｜IBM將原本的Storwize與FlashSystem產品線，整併為新的FlashSystem家族，目前分為5000/5100、7200與9200/9200R等3個產品位階。其中，7200屬於中階，9200的效能則介於傳統中階與高階之間，叢集式的9200R則擁有頂級效能。圖片來源／IBM

 相關報導  企業級中階儲存陣列新紀元

歷史悠久的NetApp ONTAP平臺儲存陣列產品線，可說是這一波中階儲存陣列更新潮的先聲，率先在2019年底推出了新款中階產品，包含AFF全快閃儲存陣列系列的A400，以及FAS混合陣列家族的FAS8300與8700，均引進了基於Intel新一代Cascade Lake處理器的控制器核心，以及NVMe、25GbE、100GbE等新一代I/O介面。

A400與FAS8300、8700這3款機型，取代了2016年底推出的上一代中階產品，A400是A300後繼者，FAS8300與FAS8700則取代了FAS8200。

相較於上一代的A300，A400從機箱、硬體核心到I/O介面都有所更新，其中控制器機箱從3U改為4U規格，並以新的Cascade Lake架構處理器，取代了A300的Broadwell架構處理器，不僅架構較新，處理器核心數從42核提高到40核，記憶體同樣是256GB，但NVRAM記憶體從16GB提高為32GB，控制器主機板的PCIe插槽也從4個增加為10個。

A400還引進了硬體加速功能，控制器預載了基於ASIC的卸載引擎卡，可減輕即時壓縮與重複資料刪除運算負擔。

在I/O介面方面，A400則引進了基於FC的NVMe-oF，以及25GbE、100GbE等新一代乙太網路，雙控組態下的最大儲存容量，也從A300的384臺SSD提高為480臺SSD。

至於FAS8300與FAS8700，同樣也以4U控制器機箱，取代上一代FAS8200的3U機箱，並引進Cascade Lake處理器，雙控組態下的最大儲存容量，也從FAS8200的480臺磁碟，分別提高到720臺與1440臺磁碟，並支援25GbE、100GbE等新一代I/O介面。

在當前的全快閃儲存陣列領域中，Pure Storage的FlashArray//X算是一個相當具有開創性的產品，2017年4月推出的第一代FlashArray//X，是首波採用全NVMe架構的儲存產品。接著在2018年5月推出的第2代機型FlashArray//X R2，則擴展了機型款式，並支援32Gb FC、25/50GbE等更多的新一代I/O傳輸介面規格。

稍後，在2019年9月，該公司又為FlashArray//X R2部分機型，支援基於儲存級記憶體（SCM）的DirectMemory模組（DMM），而成為首波支援SCM的儲存產品，可搭配Purity//FA作業系統新增的DirectMemory Cache功能，將這樣的儲存級記憶體模組設為讀取快取，原廠宣稱，可藉此改善50%的讀取延遲。

到了2020年2月推出的FlashArray//X R3，又有重要規格更新。

首先，擴大支援DirectMemory模組，搭配NVMe-oF傳輸架構，能將存取延遲降低到150μs等級。

其次，控制器核心升級為Intel最新的Cascade Lake架構處理器，取代了上一代機型採用的Broadwell架構處理器，原廠宣稱，FlashArray//X R3的整體效能，可較上一代機型提升25%。

第3，新增1TB容量的入門級NVMe儲存模組（DirectFlash模組）選項，能夠降低用戶的導入門檻。

第4，搭配升級到5.3版的Purity//FA作業系統，支援EncryptReducer加密，DirectMemory Cache，以及利用雲端儲存快照複本的CloudSnap等功能。

總而言之，Pure Stroage在儲存陣列的整體架構上，也為升級到新的Purity//FA 6.0作業系統，做好準備。

 相關報導 企業級中階儲存陣列新紀元

今年指標性的一線大廠的中階產品線，紛紛更新與整併，不僅普遍導入NVMe、儲存級記憶體（SCM）等新技術，也引進多樣的產品部署形式，包括虛擬化、軟體定義與超融合，讓中階儲存陣列的應用型態有了全新的面貌

使用現代UI框架，最終目的雖然是要組建畫面，然而不要一開始就把頭埋入成千上萬的UI元件中，因為在摸索幾個基本UI元件之後，我們可以發現，框架如何管理狀態，才是最需要先行探索的重點之一！

下一步，狀態管理！

談到UI框架，往往會令我想起自己初學程式設計的年代。

相較於撰寫文字模式下的程式，具有圖形介面的程式很吸引人，就算在什麼都不懂的初學階段，用個VB拉個畫面，跑出個視窗程式，就令人興奮不已。後來有段時期我也著迷於GTK/Qt，以至於Java的AWT/Swing等，可以說我早期的程式設計基礎，都是在視窗程式的撰寫中奠定下來的。

然而隨著Web的興盛，越來越多的使用者介面搬到瀏覽器上，視窗程式的探討、文件、書籍漸漸少了，有一段時間我還覺得可惜，明明視窗程式中可以學到許多設計的概念，像是UI元件間的設計模式、職責分配方面的MVC等，我甚至覺得身為開發者，至少都該學點視窗程式設計呢！

不過，漸漸地，前端開發興起，我發現視窗程式的設計概念開始換了樣貌。

雖然早期也有ExtJS這類，在瀏覽器中模擬傳統視窗元件的框架，不過，視窗程式本質上就是使用者介面設計之一，瀏覽器中的使用者介面，並不止於模擬傳統視窗元件，因而瀏覽器開始也發展出屬於自己的一套設計哲學，從單純的DOM程式庫（jQuery）、後來的MVC、MVVM框架，仍至於虛擬DOM等，支援瀏覽器中實現使用者介面的相關技術，所涵蓋的概念也越來越多了。

這也就是我先前專欄〈漫談Flutter UI〉中談過的：面對UI框架時，若只關注於大量UI元件怎麼使用，就容易迷失於一個又一個範例。至少你必須先摸清楚UI元件的繼承架構等API設計，而這個建議之所以提出，其實也是來自於我過去研究視窗程式的心得。

那麼下一步呢？一起來研究UI框架如何支援狀態管理吧！

在先前專欄〈有限狀態機與前端〉我就談過，在Flux、Redux等架構提出後，狀態管理這件事在前端領域，成了熱門議題之一，有好的狀態管理，才容易控制狀態的轉移，也就易於推導應用程式目前處於何種狀態。

Widget=build(state)

重視狀態管理的這股風潮，不單只發生於瀏覽器中的使用者介面，如今也吹到了手機／平板的App開發領域。

姑且不論React在App這方面就有React Native這門技術，我近來在研究Flutter時發現：是否掌握狀態管理，對於能否善用Flutter，往往扮演很重要的角色。

在〈漫談Flutter UI〉中談到，開發者使用Flutter撰寫程式建構畫面時，幾乎都是跟Widget打交道，在組建畫面時，最常關心的是build方法怎麼寫，對於StatelessWidget，它的狀態不會改變，想改變StatelessWidget的屬性，就是指定新屬性「重新建立」Widget。

那麼StatefulWidget呢？嚴格來說，StatefulWidget實例本身狀態也是不會改變的，狀態會變化的其實是createState傳回的State實例，而State的build方法，會根據State當前的狀態「重新建立」Widget。

StatelessWidget的屬性也是一種狀態，就這點來看，無論是StatelessWidget或StatefulWidget，都是根據目前狀態重新建立Widget，Widget=build(state)，你改變了狀態，對應的UI就會重建，Widget就是UI，build就是函式，也就是UI=f(state)，狀態是輸入，UI是結果－宣告式的UI風格。

因為StatelessWidget狀態不會改變，新Widget的產生來源，主要就是StatefulWidget了，對應的State若以setState通知框架狀態發生變化，框架就會呼叫build建立新Widget，Widget樹就會變化，然而Element不見得！

雖然開發者多半與Widget打交道，不過，在Widget的API文件上的第一句話，就說明它是用來「描述Element的組態」，Element會由Flutter管理，開發者幾乎不會去干涉Element，然而在Flutter中想掌握狀態，就一定要認識Element。

Widget樹與Element樹

簡單來說，Widget與Element是一對多的關係。Widget只是組態，可以放到Widget樹的多個位置，也可以從Widget取下；每次Widget被放到Widget樹上，就會生成一個Element，因此，如果一個Widget被用於Widget樹多個位置，就會生成多個Element；而Element也會組成一棵樹，Element類別的定義，主要都是與Element樹的維護相關。

Widget樹與Element樹有結構上的對應，Element會參考當初建立它的Widget。如果Widget樹有了變化，Element會對持有的Widget與新的Widget，進行比較。

具體來說，這是透過由Widget的canUpdate靜態方法決定，如果canUpdate傳回true，既有的Element實例會參考至新的Widget，而不是建立新的Element實例，因此build建立了新Widget，Element樹不見得會改變。

StatelessElement所對應的是StatelessWidget，StatelessWidget實例本身就有建立畫面的相關屬性（狀態），而StatelessElement單純更新參考的Widget，基本上沒有問題（而且經濟），但是，面對StatefulWidget就要小心了，因為，StatefulElement才會持有State物件（也就是擁有狀態），StatefulElement若單純更新參考的Widget，原本持有的State物件會維持不變。

在〈Keys! What are they good for?〉就舉了個實際案例。兩個StatefulWidget的位置交換了，卻沒有產生對應的顏色變化，而解決的方式，是透過key特性的設置，令canUpdate傳回false，不讓Element單純更新Widget，而是令Element樹也做出位置上的調整。

所以，我們要注意的，不單只是Element是否會更新Widget的問題。因為，每次Widget被放到Widget樹上，就會生成一個Element。而這也意味著，對於StatefulWidget來說，createState會被多次呼叫，表示狀態會被重新建立，例如，如果把同一StatefulWidget實例從Widget樹拿掉後又放上，就會失去先前的狀態。

若要解決這樣的問題，處理的方式視需求而定，基本上，我們可考量狀態管理由哪個元件來做：子元件？父元件？或是兩者之混合？對此，在〈Managing state〉中，有些範例可以參考。

框架如何管理狀態？

在各式的狀態管理討論上，Flutter的官方文件也花了不少篇幅說明，例如〈State management〉就提供了不少文件資源，其中，對於短時（ephemeral）狀態與App狀態的區分，也值得思考。

不只是Flutter，對於現代UI框架來說，講再多的狀態管理也不為過，開發者應該將UI框架對狀態管理的設計與支援方式，列為接觸UI框架時的首要課題之一，甚至去試著認識支援UI框架的第三方狀態管理程式庫，從中知道UI框架本身可能有哪些不足之處，以及其他可行的方案。

關於臉書粉絲專頁遭盜的方式，不只有用戶的臉書帳號被盜，還有一種詐騙類型，即使用戶已經注意不會亂點非來自臉書的連結，也沒有任意提供自己的臉書帳密，但是，用戶粉專卻還是會遭到盜用。

前陣子，在5月初，歐買尬集團創辦人林一泓的「林一泓」粉絲專頁遭盜，就是這樣的情形。關於這起事件的不同之處，是因為他的粉絲專頁被盜，但個人的臉書帳號仍正常使用，而且，用戶本身也沒有亂點可疑的外部連結。

後續，我們詢問林一泓當時的狀況，並根據案情，找到國外在前兩年，已有這類型的案例，而在今年2月，國內其實也有網紅遭受此類手法，導致粉專詐騙被盜。因此，從這些事件，也讓我們得到更多資訊，瞭解這類型詐騙的不同。

點擊臉書企業管理平臺連結就上當，國內已有遇害案例

在5月20日，歐買尬集團創辦人林一泓在自己的臉書上表示，自己的同名粉專遭盜，希望避免其他人受騙。

林一泓表示，他所建立的臉書粉專名稱，與他個人臉書名稱相同，都是使用「林一泓」，而該粉專的管理者，其實就只有他一個人，而且，粉專是有藍底白勾的官方認證。

在遇害過程方面，他表示，一開始有自稱臉書廣告部門的外國人，透過臉書Message傳訊，要教他設定企業帳號，原本他並未搭理，但在對方不斷請求下，過了兩週，他在5月11日配合做了一些廣告設定。

然而，在設定完當下，對方就不再回應，直到兩日後，林一泓發現，他的粉專管理權限已被刪除。

從上述過程，我們也找到前兩年國外就有類似的案例，是假借廣告商名義來詐騙，林一泓表示，看起來手法稍有不同，但邏輯上應是大同小異。

對於粉專遭盜的關鍵，林一泓指出，是因為臉書有一個企業管理平臺（Facebook Business Manager）的功能，可管控公司旗下不同產品的粉絲團，先前之所以遇害，是因為他不熟悉這樣的架構，所以加入了這個企業帳號，他表示，這等於同意把權限交給對方管理。

關於設定過程，林一泓提到，對方透過訊息傳給他的網址，他並沒有隨意點擊，最後對方是用臉書的機制，發出系統通知信，他才敢確認。

他表示，對方透過臉書的這個機制，使它看起來是企業帳戶要幫你解決管理廣告相關問題。對於是否有看到You've been given access to XXX的邀請通知，他表示，如果有，他決不會同意，而他所收到的是中文的內容，可能在看似模糊的文意中，就點擊了來自臉書系統所發出的連結。

後續，我們也找到之前國內就有的類似案例，例如，網紅Crazy Man瘋男的團體，團員Nick在自己的影片中說明了遇害經歷。

根據他們的說法，是在2月11日，收到透過電子郵件寄來的訊息，有一家國外公司聲稱想要在用戶的粉專上投放廣告，並會付出廣告費。之後，他們便與對方用WhatsApp持續聯繫，過程中，對方提供了沒看過的廣告形式，雙方也逐漸談好廣告金額。

接下來，對方在半夜表示已經準備好要匯款，並表示會提供一個教學連結，寄送至他們的電子郵件信箱，當他們點擊確認後，就進入到臉書企業管理平臺的介面，然而，對方這時就短暫不回應了。而他們在這個管理平臺上，發現對方已經邀請了一些不認識帳戶，並設定為分析師的角色，而他們也無法移除平臺上的廣告主角色，之後，他們就被剔除管理員身分。

謊稱廣告設定是詐騙者的慣用騙術
近期，國內臉書粉專遭到的詐騙手法中，有一類型是假冒臉書官方協助廣告設定的名義，但實則利用臉書企業管理平臺的機制，要讓用戶誤以為只是確認廣告相關的設定，一旦用戶確認後，就會看到你已被授權存取該企業管理平臺，但實際上，這是對方讓用戶加入對方建立的企業管理平臺，成為該平臺的成員。

在近期一連串粉專遇害事件中，我們看到林一泓在臉書上提及事件經過。（註：486先生已表示自己是遭刻意檢舉.而被臉書系統將粉專關閉，狀況不同）（右圖圖片來源：林一泓）

在林一泓粉專遭盜事件曝光後，我們找到國外已有不少這類透過企業管理平臺詐騙的案例，在2018年已經有人將這樣的狀況拍成影片放到Youtube上，後續，我們發現今年2月國內網紅也曾遭遇同樣的詐騙手法，Crazy Man瘋男Nick在自己的影片公開他們的遭遇。

混淆使用者的2大關鍵

為何上述這類詐騙方式，可以不涉及用戶臉書帳密，最後卻能取得粉專管理權呢？看起來，最大關鍵就是臉書推出的企業管理平臺（Facebook Business Manager），遭到詐騙方利用。

基本上，這是臉書在2014年推出的服務，可方便企業、廣告代理商能在同一介面下，對旗下的粉絲專頁、廣告帳號集中管控，而且，透過這樣的廣告後臺，可以更輕易做到鎖定受眾對象。不過用戶要知道的是，每個臉書用戶，都可以建立企業管理平臺帳號。

而在這種詐騙手法上，為何用戶會收這種詐騙手法所吸引，我們從目前整理到的國內外遇害案例，來分析用戶被詐騙說詞混淆的原因。

關鍵1. 詐騙最後過程是透過真實來自臉書的訊息，用戶不易分辨

從這類型的詐騙過程來看，用戶最容易上當的地方，是因為自己並未交出自己的帳密，而且點擊的連結也確實都是來自臉書系統。

一般而言，在用戶建立企業管理平臺後，可以執行新增粉絲專頁，只要用戶本身是該專頁的管理員，才能新增粉專到企業管理平臺。不過，在這個管理平臺上，也可以邀請成員加入到企業管理平臺等。

因此，詐騙方利用該平臺的機制，藉由發送系統邀請加入通知並搭配詐騙話術，誘使用戶最終點擊了一個確認鍵，讓用戶加入企業管理平臺後，之後詐騙方可能進行一連串的操作，讓用戶失去粉絲專頁的控制權，最終並將用戶移除。

因此，即使確認是來自臉書的系統訊息，用戶在收到確認的網頁內容時，可要特別留意像是「You've been given access to XXX」、「你已獲得XXX的使用權限」的內容，不要因為對方催促，自己一時不夠冷靜，就因此上當。一旦同意，你可能就成為該企業管理平臺的成員，但企業管理平臺的管理者是對方。

而且，從已知的案例來看，還要注意詐騙者可能會使用一些名稱來混淆用戶。因為，詐騙者可以搭配詐騙話術並在取名方面操弄，例如，對方的臉書顯示名稱可編輯為「Facebook Support」、「企業用戶」，而對方建立企業管理平臺的名稱時，可偽裝成一家企業的名稱，或是取名為「Ad Sponsored Manager」，甚至是取名為用戶的粉專名稱，進一步造成用戶的誤解，以為該企業管理平臺，真的屬於自己。還有要注意的地方是，由於臉書系統有時會翻譯成中文，光看字面意思加上取名的混淆，也是有可能造成主動被動不清楚，或誤以為的狀況。

意外收到臉書企業管理平臺的系統通知信，小編可要特別當心
當使用者收到上述通知時，可要特別留意，這是對方建立企業管理平臺後，邀請相關人員時所發出的通知，但是，詐騙者可以透過詐騙話術與平臺取名來混淆，讓用戶誤以為只是廣告設定。在此過程中，利用用戶不熟英文與平臺功能，又或是翻譯與取名的問題，就用戶收到通知卻也不太清楚其意義，進而讓用戶加入到對方建立的平臺後，對方為企業管理平臺管理員，最終自己的粉專被他人遭盜取。

關鍵2. 利用廣告收益或企業管理平臺的名義，來勾引用戶上當

從詐騙名義與方式來看，為了取信於用戶，一開始，詐騙方可能偽裝為一家公司寄送電子郵件，聲稱要在用戶粉專下廣告，或是假冒臉書工作人員透過Message傳訊，謊稱要協助進行企業管理平臺，以及廣告相關設定。

當然，顯然詐騙者就是鎖定了用戶的心理，利用增加廣告收入的名義，來吸引使用者目光與回應，畢竟，這幾乎是所有粉專經營者，都會在意的一件事，或是讓不熟臉書企業管理平臺的用戶，以為有一個機會可以學到如何設定。而且，這種方式利用的是臉書系統本身的機制，在模擬兩可的說詞下，使得用戶很容易信以為真，但卻在沒搞清楚的情況下，上當受騙。

唯有持續認識詐騙手法才能更懂得防範

無論如何，用戶對於這於這些不請自來的訊息，即使過程中一直都是再三防範，卻仍然不慎掉入對方的陷阱。

畢竟，由於詐騙者利用金錢陷阱，以及粉專經營上的好奇心，即便用戶一直都抱持戒心，但跟隨著對方的話術、廣告設定，以及要用戶確認時用的也是臉書系統本身的機制，導致可能只是一時不察之下，失去維持冷靜判斷的心理，在最後一個環節受騙。

由於這類手法在國內較少見，用戶可能一時上網搜尋也沒查到相關案例，而這樣的案例，也提醒著大家，不要以為自己的臉書帳密沒有被竊取，粉專就不會遭盜用。

當心利用企業管理平臺邀請成員的詐騙
基本上，每個臉書帳號都能建立企業管理平臺（Facebook Business Manager），而從受害用戶所收到的系統通知內容來看，詐騙方應是利用邀請成員機制，之後再透過一些手法讓用戶失去既有粉專管理權限。

當我們嘗試用臉書企業管理平臺發送邀請成員通知，這時用戶會從電子郵件收到來自臉書的通知信（如圖左），擬以獲得XXX（圖中馬賽克位置）的使用權限，在前往臉書企業管理平臺輸入名稱並確認之後（圖右），將會看到你已被授權存取XXX。基本上，這個XXX是企業管理平臺的名稱，但是，對方可能取名為對方聲稱的公司名稱，或是廣告商，或是將用戶粉專設成企業管理平臺名稱來混淆與取信用戶。

如果真的不幸遇害，利用臉書回報機制取回

若是不慎粉專遭盜，遇害粉專管理者可前往Facebook Help Center （https://www.facebook.com/help/），找到「我存取粉絲專頁時遇到問題」（https://www.facebook.com/help/contact/1280439701975125），進行回報。

開發Jupyter Notebook的非營利組織Jupyter，發布最新支援SQLite的Jupyter核心。Jupyter開發環境是資料科學領域的好用工具，由於各種語言核心的支援，使用者可以利用Python、C++、R或Julia等程式語言進行開發與探索資料，官方提到，SQL也是重要的程式語言家族，因此Jupyter核心開始支援SQLite。

新核心讓用戶可以使用完整的SQLite語法和一些額外的操作，像是開啟和關閉資料庫檔案，或使用Jupyter指令來視覺化資料。為了簡化Jupyter實作新核心的工作，官方決定使用Xeus，這是一個提供Jupyter核心協定實作的函式庫，使用Xeus則官方可專心實作核心中語言的部分，而在連結SQLite原生C實作以及C++的部分，官方則選用SQLiteCpp函式庫。

Xeus-SQLite目前仍處於開發階段，但已經提供功能齊全的SQLite介面，可進行創建、開啟和關閉SQLite資料庫等高階操作，Xeus-SQLite還能用來載入、備份和刪除資料庫，並檢查特定資料庫存在與否，還有設定或是重設資料庫鍵值。

官方提到，他們希望可以創建一種直觀的資料視覺化流程，讓使用者能在同一個筆記本中，以SQLite查詢資料後，直接創建圖表或是地圖等內容，目前官方正評估使用宣告式語言Vega，以宣告語言來創建互動視覺化設計

以色列資安顧問公司JSOF本周揭露了Ripple20漏洞，雖然名為Ripple20，但其實是由19個漏洞組成，這些漏洞存在於Treck所開發的嵌入式TCP/IP函式庫中，由於該公司的產品受到廣泛的客戶採用，從HP、Schneider Electric、Intel、Rockwell Automation、Caterpillar到Baxter不等，因此估計全球可能有數十億，甚至更多的連網裝置受到波及。

1997年成立的Treck其實是家小公司，只服務特定的客戶群，但該公司的客戶卻有許多大企業，或是大企業的供應鏈。根據JSOF的追蹤，含有漏洞的TCP/IP函式庫被應用在工業裝置、電網、醫療裝置、家用裝置、網路裝置、企業裝置、零售裝置上，或者是部署在交通產業、石油暨天然氣產業、航空產業、政府部門或其它的IoT裝置上。目前JSOF列出了8家確定的Treck的客戶名單，以及逾60家尚待確認的Treck客戶名單。

不只是客戶類型廣泛，Treck在1990年代曾與日本業者Elmic Systems（之後更名為Zuken Elmic）合作，由雙方共同開發嵌入式TCP/IP函式庫，拆分後由Treck負責美國市場，亞洲市場則由Zuken Elmic主導，而JSOF此次在Treck函式庫所發現的漏洞中，有部份也存在於Zuken Elmic所出售的TCP/IP函式庫。

研究人員指出，在這19個安全漏洞中，絕大多數都是屬於零時差安全漏洞，並有4個被列為重大漏洞，允許駭客執行遠端程式攻擊，而這些漏洞可能會讓駭客盜走印表機的資料，變更輸液幫浦的行為，或是造成工業控制裝置故障等，駭客也可能把惡意程式藏匿在嵌入式裝置中。

JSOF在去年9月就發現了Ripple20漏洞，在與Treck協商後決定於本周公布漏洞細節，而Treck也已修補了相關漏洞並於官網上披露，這些漏洞涉及了IPv4、IPv6、UDP、DNS、DHCP、TCP、ICMPv4與ARP等協定。其中，被列為重大等級、CVSS 3.0風險等級超過9的4個漏洞，分別是CVE-2020-11896、CVE-2020-11897、CVE-2020-11901與CVE-2020-11898。

只要傳送多個異常的IPv4封包到支援IPv4通路的裝置，就能觸發CVE-2020-11896漏洞，儘管它只影響採用特定配置的裝置，但將允許駭客執行遠端程式攻擊，而且已被證實可用來開採工業物聯網業者Digi International所開發的裝置。CVE-2020-11897則是個越界寫入漏洞，當傳送多個異常的IPv6封包到裝置時，就能觸發該漏洞。

CVE-2020-11901也是個遠端攻擊漏洞，該漏洞肇因於DNS解析元件無法適當驗證輸入，駭客只要傳送一個特製的封包就能觸發該漏洞，並可能讓駭客取得裝置的控制權。CVE-2020-11898來自於IPv4/ICMPv4元件無法妥善處理長度不一的參數，收到特製封包時可能導致機密資訊外洩。

不僅是JSOF與Treck同時披露Ripple20漏洞，同一天提出漏洞示警的還有美國、日本與以色列的網路危機處理中心（CERT），以及受到相關漏洞波及的英特爾、HP與Schneider Electric。

金管會主委黃天牧在上任時就把「金融科技發展路徑圖」列為金管會6大興利方案之一，更承諾今年8月底前，將提出長期的制度和規劃。而他也特別重視金融科技的發展，將上任後首次對外溝通的業者鎖定科技業，就是要傾聽金融科技業者的意見。

黃天牧在6月17日召開金融科技發展座談會，找來金融科技相關單位與多家金融科技業者、學者齊聚一堂，各方也對金融科技未來發展提出建議。

在座談會一開始，黃天牧就強調，金管會與科技業者是平起平坐，面對新的科技時代，金管會要以傾聽科技業者為原則，盡量在金融監理的原則與法律上能夠調適，讓科技業者對臺灣金融科技的企圖心，能兼顧金融監理原則與科技發展創新的平衡。

金管會綜合規劃處處長林志吉在會中揭露了金融科技發展路徑圖規劃的3大構面：對於共通性、基礎性的通用問題，包括資料分享、eKYC等尋求解決方法；如何強化金融科技園區功能；以及如何透過媒合、資金提供提供業者發展的誘因。

林志吉進一步說明，未來金融科技發展路徑圖有4大重點業務，一是建立金融創新的差異化管理機制；二是在下半年立法院開議之後，推動電支電票管理法制整合；第三則是推動開放銀行第二、第三階段的相關作業；最後一點是，配合純網銀開業在即，要導入監理科技即時監控。

這場金管會面向金融科技業者的座談會，共有4方代表，包括金融總會暨金融科技創新園區、臺灣區塊鏈大聯盟、中華金融科技產業促進會、臺灣金融科技協會，各方也提出了多元議題。

金融總會秘書長吳當傑就表示，金融科技創新園區有三大功能，包括新創輔導、監理門診、國際鏈結。他提到，這是第一階段園區的主要功能，金融科技創新園區已進入第二階段的作業，吳當傑解釋，園區團隊除了法規風險需要協助外，最重要是資安的協助，所以他們已展開強化新創團隊的資安輔導，目前已經邀請5位資安專家與團隊來進行一對一資安健檢的諮詢，完成了30場以上的會議。

下一階段，金融科技創新園區還有另一項任務，就是與金管會各局合作，如何協助主管機關推動監理科技。除了金管會各局提出的意見，目前也結合金融機構，以實務上需求找出監理上的痛點。他透露，目前已擬出三大主題：eKYC、 市場資訊即時監理、防詐欺預警機制，預計年底前可以有相關解決方案的發表，交出一份金融監理科技報告供金管會參考。

曾在監理沙盒獲得許多幫助的麻布記帳執行長陳振榮，則對監理門診提出一些建議。比如是否可評估銀行公會或財金公司等第三方，也可以納入監理門診企業諮詢的對象。另一項建議是，參考英國、歐盟開放銀行的制度，把TSP業者納入監管，制定明確的TSP業者申請條件與相關遵循事項，讓TSP能進行自我合規，以利銀行之間的溝通與合作。

他也建議，考量到科技新創在逐步合規過程中，發現合規門檻高、資安投入成本大，是否能成立金融科技新創產業創投基金，因為單一金融機構投資容易影響其他金融機構合作的意願，若成立創投基金，除了可創造財務效益，也能幫分母較小的銀行取得新技術與金融科技夥伴的機會。

富訊金融科技董事長蔡京翰則建議，金管會可以與電信業者的主管機關NCC進行跨部門溝通，讓新創與電信業者有更多溝通機制，讓電信金融有發展的機會。他提到，電信數據是含金量很高的數據來源，若是能有數據交換平臺，新創就能產出更多加值的數位金融服務。

金融科技創新園區主任羅至善表示，園區發展創新實證主要兩個對象是金融機構企業實驗室、金融科技新創團隊。她觀察到，很多發起是來自企業實驗室，金融機構在共創過程中，蠻多願意與金融科技團隊合作，也蠻多願意跟跨金融機構合作，陸續幾家金融機構也提過，是否能在園區開放小規模的實驗，在金融機構與金融機構或金融科技團隊或國際業者之間，能否針對客戶資訊交換、多元身分認證、雲端合作，希望可以走在試辦或金融監理沙盒之前，這是園區建議能強化企業實驗室的功能。

黃天牧聽完整場座談會後，共歸納出四大方向。一是虛擬通貨洗錢防制、推動虛擬通貨有風險分級或實名制規範、STO規範放寬。二是區塊鏈如何應用在身分驗證、授權或產業應用，以及智能合約在法律上的定位。三是資料開放，聯徵中心是否能開放給科技業者一些資源，以及跨部會協調資源與整合的問題。四是監理沙盒審查程序，以及提供金融機構與相關科技業者合作的誘因。

黃天牧也透露，接下來還會舉辦下一場座談會，要找金融機構來提出對金融科技的想法。後續，會再討論並勾勒出金融科技發展藍圖。文⊙李靜宜

微軟推出兩系列新的Azure虛擬機器，採用第二代英特爾Xeon Platinum 8272CL處理器，第一個系列Ddv4、Ddsv4、Edv4和Edsv4虛擬機器擁有本地端資料暫存磁碟，但第二個系列Azure Dv4、Dsv4、Ev4和Esv4則是一類新型虛擬機器，使用遠端磁碟沒有本地端的暫時儲存，微軟提到，跟之前的Dv3和Ev3虛擬機器相比，新的第二系列虛擬機器CPU效能約提升20％。

新虛擬機器使用特製處理器，基速能以2.5 GHz運作，而睿頻可達到3.4GHz，其應用深度學習加速技術，也支援進階向量延伸指令集512，可以加速科學模擬、金融分析和人工智慧等運算。

現在正式推出的Ddv4、Ddsv4、Edv4和Edsv4虛擬機器，擁有更快容量更大的固態硬碟儲存，適用於需要低延遲且高速本地儲存的應用程式，像是需要快速讀寫暫時儲存的應用程式，或是需要快取和暫存檔案的應用程式。

與前一代相比，這些虛擬機器的本地儲存容量擴大50％，並且具有更高的IOPS，提供更好的讀取和寫入操作速度，使用者可以在Ddv4、Ddsv4、Edv4和Edsv4虛擬機器附加標準HDD、標準SSD、Premium SSD或Ultra SSD永久磁碟。

而Ddv4和Ddsv4虛擬機器最多可以搭載64個vCPU和256 GiB記憶體，以及最高2,400 GiB的本地SSD，適合測試開發，以及中小型資料庫與網頁伺服器等用途；Edv4和Edsv4的CPU則搭配更多的記憶體，最高具有64個vCPU和504 GiB記憶體，並且最大可以使用2,400 GiB的本地固態硬碟儲存，微軟表示，這樣的虛擬機器很適合用於關聯式資料庫伺服器，和記憶體分析應用。

另外，微軟也釋出Dv4、Dsv4、Ev4和Esv4虛擬機器預覽版，這是不包含本地暫時磁碟的虛擬機器類型，使用者可以在Dv4和Ev4虛擬機器使用標準HDD和標準SSD永久磁碟，Dsv4和Esv4虛擬機器則可以使用標準HDD、標準SSD、Premium SSD或Ultra SSD永久磁碟。微軟表示，使用前一版虛擬機器的使用者，切換到第4版可以獲得更好的核心價格。

新的Dv4和Dsv4虛擬機器提供達64個vCPU和256 GiB記憶體，這些虛擬機器適合用於測試工作負載以及中小型的資料庫和網頁伺服器；而Ev4、Esv4擁有較高的記憶體和CPU比例，最多一樣可以配備64個vCPU，但記憶體可多達504 GiB，適合用於關聯式資料庫伺服器和記憶體分析應用。

支援眾多壓縮格式的跨平臺開源媒體播放器VLC Media Player，在本周釋出了3.0.11版，以修補多個安全漏洞，當中包含一個遠端程式攻擊漏洞CVE-2020-13428。

打造該播放器的VideoLAN說明，駭客只要誘導使用者開啟一個特製的檔案或串流，就能觸發相關漏洞，進而以使用者權限執行任意程式，波及VLC media player 3.0.10及之前的版本。

VideoLAN表示，儘管相關漏洞在大多數的時候只會造成播放器無法運作，但無法排除駭客可能結合這些漏洞而取得使用者資訊，或是執行任意程式，惟迄今尚未發現針對相關漏洞的攻擊行動。

VLC Media Player不只支援Windows、Linux與macOS等桌面平臺，也支援Android、iOS及iPadOS等行動平臺，所能讀取的媒體格式則超過100種。VideoLAN呼籲使用者儘快升級到最新版，在更新前最好不要自不明來源開啟媒體檔案，或是暫時關閉VLC的瀏覽器擴充程式。

Twitter本周宣布，即將於iOS平臺上小規模測試新的語音推文功能，讓使用者能夠以語音取代文字張貼內容，且預計在未來幾周就會讓所有iOS用戶都能使用該功能。

Twitter表示，現階段用戶已可透過文字、照片、影片或動畫來表達自己的想法，但有時280個字元可能不足以完整說明，因此決定測試新的語音推文功能，讓用戶可以用聲音來描述。此外，他們也希望藉由語音推文，替用戶與聽眾建立更人性化的使用經驗。

具備語音推文功能的Twitter程式將會出現一個語音圖示，點選它就能進入語音貼文的編輯畫面，再按下錄音鍵就可紀錄自己的語音，每則語音推文的長度限制為140秒，若140秒還沒說完，它會自動產生第二則語音推文，最多可產生25則語音推文，總計是58分鐘33秒。

初期語音推文的功能只能用在首度建立推文時，而無法用在回應或轉推上。

本月Patch Tuesday傳出造成多款USB印表機運作異常及找不到連接埠，微軟本周（6/16）緊急釋出例外更新予以解決。微軟同時也預告20H2將首度內建Chromium-based Edge，也會是較小的升級版。

微軟針對Windows 10 1803、1809、1903與1909釋出頻外選擇性更新（out of band optional update）程式，解決「特定」印表機安裝完Patch Tuesday的更新版後無法列印的問題。微軟解釋，這是因為印表機驅動程式中的語言監控程式（Language Monitor）中有臭蟲，導致其中的OpenPortEx callback功能無法被呼叫到，也導致控制臺的「裝置與印表機」下找不到印表機連接埠。

受影響的印表機品牌包括HP、Ricoh、Canon、Brother、Kyocera、KONICA Minolta、Panasonic等USB連線的機種。

不過因為是選擇性更新，因此用戶必須透過Microsoft Update Catalog下載。至於其他版本，如最新的Windows 10 version 2004、較舊的Windows 10桌機版本、Windows 8.1及伺服器版Server 2012、Server 1709等，微軟表示也會於未來幾天內釋出更新版。

微軟也同步宣布下半年的20H2版，將是第一個內建Chromium-based Edge瀏覽器的Windows 10。此外，一如19H2，對May Update 2020（2004）的用戶而言，20H2也將好比每月累積功能更新，使安裝速度更快。至於對企業版及2004版本以前的消費者來說，20H2就是較大的升級版。

微軟也預告，到了20H2，企業版及教育版Windows 10用戶，也將獲得30個月的技術支援期間。

為了不讓美國在5G發展落後，美國商務部本周（6/16）宣布一項新產業安全局（Bureau of Industry and Security，BIS）規定，允許美國公司分享技術資訊給華為，以便和華為建立聯合的5G無線標準。

路透社本周率先引述消息人士報導，並獲得商務部的證實。

在美國優先的前提下，這項新BIS法規修改了針對華為而設的實體清單（Huawei Entity Listing），允許科技公司和華為發展5G等聯合標準分享技術資訊，無需取得出口執照。

美國商務部指出，新法規是為了確保美國產業能更全面參與電信產業的標準發展。功能、相容及安全性等國際標準是科技發展的關鍵基礎，美國參與並領導標準制訂，將影響未來5G、自駕車、人工智慧和其他尖端技術的發展。

商務部長Ross Wilbur也不諱言指出，美國不會在全球技術上交出領導地位，這項決定證實運用美國人的才智推動國安和經濟的重要性，為此商務部致力於推動美國科技成為國際標準。

但是除此之外，商務部並沒有透露任何放寬對華為技術出口限制的計畫。

華為方面對此沒有回應。

才不過一個月前，美國商務部宣布一項強制規定，要求使用美國技術的半導體業者若要供給華為，必須取得美國政府的許可，也警告可能不再展延華為銷售產品給美國客戶的臨時通用許可（Temporary General License，TGL）。

美國總統川普（Donald Trump）在今年5月底簽署一行政命令，要求商務部督促聯邦通訊委員會（FCC）審查《通訊規範法》（Communications Decency Act）第230條（Section 230）中，對社交網站的保護，以阻止社交網站執行言論審查，迄今FCC尚未公開回應此一行政命令，然而，共和黨參議員Josh Hawley以及司法部已相繼提出建議，目的都在削弱法令對社交網站的保護。

《通訊規範法》（Communications Decency Act ）第230條（Section 230）是用來保障包括社交平臺與ISP在內的網路服務供應商，讓它們免責於使用者在該平臺上所張貼的言論，同時也賦予它們出自於善意、限制平臺上所出現之冒犯性內容的權力。

Hawley則在6月17日提出一項法案，以讓美國民眾能夠控告那些選擇性審查政治言論，或是隱藏競爭對手內容的大型科技公司。該法案將禁止大型科技公司使用第230條的豁免權，除非業者修改服務條款，承諾相關操作都將基於善意，而且一旦違反承諾，就必須支付5,000美元的罰款。

Hawley說，這麼多年以來，包括Twitter、Google及Facebook等大型業者都透過他們的勢力來壓制保守派的政治言論，第230條賦予這些企業過多不必被追究的言論權力，國會應該立即展開行動，以確保居心不良的業者無法再抑制反對者的聲音。

至於美國司法部則在同一天提出了第230條的改革建議。司法部長 William Barr表示，當涉及公共安全時，政府必須代表整體社會展開行動，在執法上不得將政府保護美國人民安全的義務，完全委託給追求獲利的私人企業，因此應該要修改該條款，以確保其豁免原則能夠激勵網路平臺負起責任。

可能是為了避免外界把此舉視為司法部揣摩上意的行為，司法部特別強調它們研究第230條已有10個月之久。而司法部提出的改革建議包括鼓勵網路平臺解決違法內容、推動公開討論與透明性、闡明聯邦政府的執法能力，以及促進競爭等。

不管是司法部的改革建議，或者是Hawley所提出的新法案，基本上都削弱了第230款對社交網站的保護，但也都必須經過美國國會的同意才能生效。

而真正掌管公平競爭及媒體責任的美國聯邦通訊委員會（FCC），迄今仍尚未對川普的行政命令提出正式的回應。

6月初視訊會議平臺Zoom表示，全程加密（E2EE）功能僅提供給付費用戶，不過昨日（17）Zoom改口說免費版用戶也可以獲得這項安全保護，並將於7月啟動早期測試。

本月初，Zoom表示，為擔心有人拿全程加密功能（E2EE）從事不當用途，侵害弱勢族群的隱私，因此這項功能不會包含在免費版本中，因為免費版與會者僅以電子郵件登入，不足以提供身份辨識。但Zoom執行長袁征昨天指出，他們已找到兼顧所有平臺上用戶隱私及安全的方法，能讓他們對全球所有用戶，包括免費及付費使用者提供E2EE作為進階的安全功能，同時防止平臺被濫用。

免費版用戶只要再動手一次，輸入額外個人資訊，像是以簡訊驗證身份用的電話號碼，就可以使用E2EE。許多主流平臺在用戶建立帳號時，也都是用這個方法來避免大量人頭帳號的建立，Zoom相信結合風險驗證及現有多項工具，包括檢舉用戶的功能，可有效預防與打擊濫用的問題。

Zoom除了重申所有用戶的視訊內容，都可獲得GCM模式的AES 256傳輸層加密，也預告將在7月啟動E2EE早期beta版測試。不過袁征再次強調E2EE將限制部份會議功能，像是無法整合傳統PSTN電話線或SIP/H.323硬體會議系統。而且主持人每次會議都需額外開啟或關閉E2EE。

Zoom今天也將新版全程加密的設計公布於GitHub上。

視訊會議平臺紛紛強化安全性以爭取客戶。本周思科在Cisco Live上也宣布其安全功能，包括防資料外洩的留存（data loss prevention retention）、合法保存（Legal Hold）和電子探勘（eDiscovery）功能，延伸到視訊會議平臺WebEx Meetings，以保護錄影、轉錄資料等會議內容，協助健康照護等產業符合嚴格法遵需求。

由於人工智慧和機器學習人才需求持續擴大，微軟與線上課程平臺Udacity合作，推出適合初學者以及進階人士的機器學習課程，同時，微軟還推出了一項獎學金計畫。

Udacity是一個數位教育平臺，目前有25萬個活躍使用者，微軟提到，由於Udacity使用者，對不需要進階程式開發技能的機器學習內容表達高度興趣，因此微軟和Udacity設計了特別的課程，是以Azure機器學習為基礎，借由拖放操作的低程式碼開發和自動機器學習技術，讓學習者獲得機器學習基礎知識。學習者甚至有機會在Udacity課堂中，實際操作Azure機器學習動手做實驗室（Hands-On Labs），讓學到的資料科學技能更加扎實。

而給進階人士的課程，微軟提供了新的機器學習Nanodegree計畫，在這個計畫中，學習者會使用熱門的開源工具，像是PyTorch、TensorFlow、scikit-learn和ONNX等，建構和部署複雜的機器學習解決方案，從中學到更深入的機器學習知識，微軟提到，藉由操作Azure機器學習的各種功能，學習者將更了解機器學習模型，並擁有保護個人資料，以及控制端到端機器學習生命周期的經驗。微軟也宣布提供課程前300名參與者獎學金，鼓勵這些人發展資料科學技能。

微軟在6月17日釋出了Windows 10 Insider Preview Build 20150，這不僅是Windows 10 21H1的第一個預覽版，也是首個採用新Dev Channel名稱的預覽版。

微軟是在日前宣布變更Windows Insider的預覽設計，把基於發布頻率的Ring模式，改成基於品質的Channel模式。因此，過去的Windows 10預覽版有Fast Ring、Slow Ring與Release Preview Ring，現在則變成Dev Channel、Beta Channel及Release Preview Channel，其中，Dev Channel適用於高階的技術使用者，Beta Channel則適合早期採用者，而Release Preview Channel則是相對穩定的版本。

而Build 20150即是屬於Dev Channel，同時它也是預計於明年上半年出爐的Windows 10 21H1的首個預覽版。

Build 20150提供了Windows Subsystem for Linux（WSL）的3個新功能，一是可讓Linux二進位檔案利用GPU運算能力，其次是增加可直接安裝WSL 的wsl –install命令，以及新增了可方便管理Linux核心版本的wsl –update命令。

此外，Build 20150也將把Maps程式的圖資從Bing Maps轉換為TomTom，在程式設定頁面新增搜尋視窗，同時也修補了許多臭蟲。

在金管會昨天舉辦金融科技發展座談會，部分科技業者建議金管會能開放一些金融聯合徵信中心（簡稱聯徵中心）的資料出來，而科技業者也願意提供出自家的資料給聯徵中心。對此，金管會主委黃天牧在今天（6/18）的記者會上對此作出回應，他提到，金管會在規劃金融科技方案時，要去面對、處理這個問題。

黃天牧指出，現在是一個資訊時代、數位化時代，聯徵的資料能夠以什麼樣的方法，符合其原始設立旨意的同時，又能在權利義務對等情況下，適度讓其他機構來參與。他更提到，聯徵中心的資料將來在法令、制度、社會發展上，如何符合大家的期待，還要待銀行局進行一些了解與研究，目前還不能保證最後一定同意。

銀行局局長莊秀媛進一步表示，聯徵中心是會員制，是一個比較封閉的系統，她坦言，這麼多年來，確實有不少類金融機構或是新創業者認為，他們極需要聯徵中心的資料，金管會也不斷面臨這樣的呼籲。

莊秀媛透露，其實，目前聯徵中心有在研議開放資料，只是說是要用資料區隔或是其他方式，銀行局也會再去請聯徵中心思考，資料是否一定僅限於會員查詢，以及，如果不是金融機構查詢，而是聯徵中心未來要接受第三方去查詢資料的話，有哪些問題要去解決，這些都需要全面思考。

黃天牧也提到，聯徵中心的資料基本上是與銀行來往的資料，但，現在做徵信也不見得完全靠傳統銀行資料，比如很多大數據資料，也可以在一個範圍內對於消費者的信用進行評比，他舉例，幾家純網銀未來的目標是信用小白，就是用繳費資料、消費資料，作為判斷消費者信用風險的參考。文⊙李靜宜

AWS推出最新Snow邊緣運算、儲存和資料傳輸系列成員Snowcone，這是目前Snow系列最小的裝置，可用於網路連線不穩定，或是惡劣環境的邊緣運算應用。目前已先於美國推出。

AWS Snowcone重量約2公斤，具有2個CPU和4 GB記憶體，內建8 TB儲存，能夠以有線與無線的方式存取，AWS Snowcone的運算能力足以啟動EC2執行個體，並執行AWS IoT Greengrass軟體。官方提到，Snowcone可以用於資料搬遷、內容發布、戰術邊緣運算、醫療保健物聯網應用、物流和自駕車等使用案例。

其設計非常堅固耐用，可放置在各種環境，像是桌面、資料中心、郵差包或是無人機平臺等，Snowcone能以交流電源或是選用電池供電，滿足廣泛情境的需求。AWS提到，裝置外殼設計防篡改，且使用可信平臺模組（Trusted Platform Module，TPM），可以確保資料安全讓用戶能夠完整監控資料，Snowcone使用AWS KMS管理的金鑰，加密傳輸以及儲存的資料。

AWS Snow是一個邊緣基礎設施和軟體解決方案，讓企業把資料處理和分析作業的運算資源，盡可能的放在靠近資料的位置，減少資料傳輸量。AWS Snow系列成員除了最新發布的Snowcone，另外還有Snowball和Snowmobile，Snowball為可放在機架上，組成叢集的邊緣運算裝置，具有40到52個vCPU，單臺Snowball可提供42 TB到80 TB的儲存容量，而Snowmobile則為更進階的設備，是一個長約13公尺的貨櫃，處理PB與EB規模的資料。