CodeIQ MAGAZINECodeIQ MAGAZINE

マルチプラットフォームで動く「Electron」は本当に使える技術なのか?

2016.03.25 Category:勉強会・イベント Tag: , , , ,

  • 240
  • このエントリーをはてなブックマークに追加

HTMLとJavaScriptでデスクトップアプリケーションが開発できるElectron。
html5j・Webプラットフォーム部は、Electronをテーマに「jsアプリ怪獣エレクトロンの育て方と倒し方」という勉強会を開催。
Electronアプリの開発方法、セキュリティ関連で注意しなければならないところ、実際のエンタープライズ業務で採用した状況などについて紹介された。
by 馬場美由紀 (CodeIQ中の人)

Electronはどこがすごいのか?

最初に登壇したのは、Node.js日本ユーザーグループ代表の古川陽介氏。「Electronアプリの作り方」というタイトルでセッションを行った古川氏は、会社でも「Electronを使ってアプリを開発している」と語る。

▲Node.js 日本ユーザーグループ代表 古川陽介氏

まずは簡単にElectronとは何かという説明から。Electronとはクロスプラットフォームデスクトップアプリケーションフレームワークで、GitHub社製。もともとはAtomエディタのために作られた。

作者は@zcbenz氏。ElectronはNode.jsとChromiumでできており、ブラウザのレンダリングプロセスはChromiumが担当、中でレンダリングプロセスを作るところやファイルを開くところ、XHR/fetch以外でのメインプロセスはNode.jsが担当する。

ではElectronのどこがすごいのか。古川氏は「第一にNode.jsのライブラリを直接透過的に呼べるところ」と語る。「第二はクロスプラットフォームを実現しているところ」だ。WindowsでもOSXでも動く。

これらはよく語られるすごさだが、そのほかにもElectronは、npmを基盤とする独自エコシステムができているところがすごい。次にPhotonKitにCSS Class Setがすでにあるので、OSXっぽい見た目にすることもできるところも、Electronのすごさだ。

第三に事例が豊富なこと」である。「これはawesome-electronを参照すればわかる」と古川氏は語りながら、ScreenCatでデスクトップスクリーン共有やPlayback Video Player、Chat application FIRENDSなどの例を挙げた。

さらにElectron APIも紹介した。メインプロセスのAPIとして、app(アプリケーションの起動や終了などのライフサイクル管理用API)、autoUpdater(自動更新検知、ダウンロード、アップデート機能)、powerMonitor(バッテリが切れてサスペンドになったりACアダプターが切れたなどの検知)、Menu/MenuItemについて簡単に説明。

続けてChromium側のAPIとして、desktopCaptuer(デスクトップキャプチャーを取れるようにする強いAPI)、Webframe(zoom、input textfieldに対してspell checkerをするかどうかなど)を説明した。

さらに両方で使えるAPIとしてclipboard(クリップボードの中のコピーしたものを取れるようにする)、shell(desktopの機能との共存。shell.openExternalで拡張子に紐付いた機能の実行。いわゆるopenコマンドと同様の機能を提供する)を紹介した。「このほかにもたくさんあるので、いろいろ見てほしい」と古川氏。

またElectronについて参考にすべき資料についても紹介。以下にあるとおりだが、事例を見たいのであれば「awesome electron」が参考になる。またelectron slackは日本語で質問ができる。

Electronの育て方としては、「elecronicaというチュートリアルを作ったので、それを実行してほしい。Electronに関して一通り学べる」と語り、実際にどういうことができるのか、デモで披露した。

これを学ぶと簡易ブラウザを使って遊ぶことができる。「Electronを一緒に育てましょう」と呼びかけ、セッションは終了。

Electronにはセキュリティ保護機能はない!?

続いては、はせがわようすけさんのセッションが始まった。セッションタイトルは「Electronの倒し方」。

▲株式会社セキュアスカイ・テクノロジー はせがわようすけ氏

Electron固有の注意点としては、Webアプリ技術に加え、ローカルアプリの技術が求められることだ。メインプロセスのNode.jsであれば、例えばsymlink攻撃やレースコンディションなどWebではないローカルアプリに対するセキュリティ対策が必要になる。

またレンダラプロセスにおいては、従来通りのフロントエンドのセキュリティ対策に加え、場合によってはローカルアプリについてもセキュリティ対策が必要になる。

これらがやっかいなのは「Webアプリとは異なる知識、背景なので、プラットフォーム固有の知識が必要なのと、資料がC/C++の時代から進化していないこと」。

参考資料としては次のURLを紹介した。

「Webアプリとしてセキュリティ対策をしないといけないものもある」とはせがわ氏は、レンダラプロセスについては最大の課題はDOMーBased XSSが発生しやすい点を指摘する。

しかも「DOM操作が多いので発生しやすいだけではなく、見つけにくいのが問題だ」というのである。さらに、DOM-Based XSSが発生すると致命的な被害を受けることがある。

例えば攻撃者によってinjectされたコード内でもnodeのフル機能が使えることが多かったり、alertだけではなくローカルファイルへの読み書きや他アプリへの干渉、任意プロセスの生成、ローカル環境の把握など、DOM-Based XSSをきっかけに任意コードを実行できるようになるのである。

これは従来のWebアプリと比べても深刻だ。従来のWebアプリであれば、偽情報の表示やCookieの漏えい、Webサイト情報の漏えいなど、該当Webサイト内でJavaScriptができることがすべてにおいてXSSは脅威だが、該当Webサイトを超えては何もできない。

つまりブラウザがサンドボックスとなり、脆弱性があっても自身のWebサイト以外への影響がないため、サイト運営者が責任を持てる範囲でしか被害が発生しない。

一方ElectronにおけるXSSは、アプリを使っているユーザーの権限での任意の実行ができ、PC内でそのユーザーができることすべて、既存アプリケーションの破壊やオンラインバンキング用アプリの改ざん、盗聴、マルウェア感染、配信などの脅威を与える。

該当アプリケーションの範囲を超えて何でもできるため、「開発者の責任の重みがまったく変わってくる」とはせがわ氏は強調する。では開発者は何をすればよいのか。それは「脆弱性を作り込まないことだ」と言い切る。

というのもElectronにはセキュリティ保護機能はない上、Webアプリ向けの保護機能(Content Security Policyなど)も限定的にしか効かないからだ。

DOM-Based XSSは次の様な場所で発生する。Electronの場合、ソースにおける攻撃者がコントロール可能な箇所は、ユーザー名、コンピュータ名、ファイル名、ファイルの内容、データベース内の文字列、ログの内容、その他あらゆるところが対象となる。

またシンクにおいては従来のWebアプリと比較してもそれほど増えないが、require child_process webFrame.executeJavaScript REPLなどでXSSが発生する。従来のWebアプリでは存在しなかったソースからXSSが発生するので注意が必要だ。

DOM-Based XSSを緩和する方法とは?

ではどうすればDOM-Based XSSを緩和できるのか。その方法についても紹介された。

まずレンダラでのnode機能を無効化することはどうか。例えばwebview要素にnodeintegration属性を付与するなど、XSSによってwebviewタグを挿入されるとnode機能を再活性化でき、nodeの全機能が悪用されることになる。レンダラ内で確実にnode機能をオフにできないので有効ではない。

次はレンダラにContent Security Policy(CSP)を導入することで攻撃できなくなるのではと考えたが、CSPが指定されてもWebviewタグ内ではスクリプトが実行可能になるので、「XSSの緩和にならない」。

第三の方法はiframe sandboxを使う方法である。これを使うとiframe内でのJS実行が禁止される。つまりDOM操作などレンダリングをすべてiframe sandbox内で行うことで、XSSが発生しても被害が抑えられるようになるというわけだ。

ただし、「allow-scripts、allow-top-navigation、allow-popupsは危険なのでつけてはいけない」という注意点もある。

最後にはせがわ氏は「webviewタグ、webFrameAPIなど今回触れなかったElectron固有の注意点については、3月28日に開催するShibuya.XSSで説明する」と語り、セッションを締めた。

Electronはエンタープライズで本当に使えるのかー開発編

最後に登壇したのは、グロースエクスパートナーズの酒巻瑞穂氏。「エレクトロン対エンタープライズ 技術に感電した63日(営業日)」というタイトルでセッションはスタートした。

▲グロースエクスパートナーズ株式会社 酒巻 瑞穂氏

「エンタープライズでのIT活用はエンジニアリングを中心として利益を上げているのではなく、別の産業もしくはサービスサイエンス的なITを補助的に活用することが主になる」と酒巻氏は語る。

そして責任が持てるエンジニアがいたとしても、運用でその一部のエンジニアに付加が集中や属人化するような状況を残さないようにすることが大切だと言う。つまり最低でも損益分岐を迎えるまで運用できるのか。

手離れがしやすいものか。CI/CDインフラの構築についてどれだけできるのか。該当技術の更新をキャッチアップできるのに、どれだけのコストを割かなければならないのか。「これらを考慮しなければならない」と言うのである。

とはい、手をこまねいていては扱うことはできなくなる。問題があれば改善すればよいのである。そこで、エンタープライズで導入できるか、次の様なロードマップを敷いて検証を行った。

このように小さなところから使ってみて、改善できれば次のステップに進むという方法で試すことにしたのだ。

このステップのうち、実際に行ったのは「CI/CDへの適用と検査」までだと明かす。今日の勉強会での話を聞いて、「次のステップに進むかどうかは非常に悩みどころ」と、本音を漏らす場面もあった。

まずは開発編でのElectronの検証。「Webプラットフォームが整っている場合、既存の資産がほぼ流用可能だったので創大変ではなかった。nodeやWebアプリを開発している人にとってはサクサクと開発できるのですごい技術だという感想を持つと思う」と酒巻氏。

ただエンタープライズだとUWPとかあるので、不要だという感想も持ったとも。注意するところに注意すれば、そんなにハマることはないという。注意点は次の5点。

  1. Originが file://
  2. Domを弄る系のライブラリ(JQuery, Angular)の場合、特殊なエスケープが必要
  3. Mainとrenderの2つの処理が動いている
  4. npm ーg electron
  5. Windowsは7から

中でもnpmはすごく辛かったという。またプラットフォームはWindows7からのサポートなので、「レガシーへの対応がないことも要注意」と説明した。

非常に大変だった検証編

次は検証編。これは「無駄死にの章」と自らが名付けたとおり、非常に辛いことが待ち受けていた。

ここで目標としたのは「開発からリリースまでの手順をなるべく省力化・自動化し、運用監視含めて手離れを良くしたい」ということ。具体的にはWebと同等の開発ライフサイクルでモニタリング&死活監視による問題と障害検知、リリースのオートメーション化と自動テストを可能にすることを目指したのだ。

Web開発と同等の開発ライフサイクルにするのは既存のWeb開発のノウハウが流用可能なので割と簡単にできた。ただ、異なるところもある。それはライブリロード開発部分である。

レンダラプロセスは既存のLiverload開発と同じだが、メインプロセス側に修正を入れた場合は再起動を行う必要があるのだ。これを手軽にするなら@Quramy氏の「electron-connect」というモジュールを使うとよいと酒巻氏はアドバイスする。

次のモニタリングと死活監視については、既存のSPAのようなモニタリングではレンダラプロセスしかモニタリングできないため、アプリケーション起動時のメインプロセスからWeb Socket経由でのモニタリングを行うことにした。

自動更新用サーバに監視用APIを追加するだけで済むため、既存のWebインフラがあれば簡単に導入できるのだ。最も辛かったのは、リリース自動化のための自動テスト化だったと明かす。「途中で辞めればよかった」と酒巻氏。

Electronはいろんな技術の集大成であるため、すごく便利な技術だが、それぞれの部分に対するクロスプラットフォームテストの構築が難しいからだ。例えばレンダラプロセスはブラウザが動いている。

メインプロセスはNode.jsが動いている。メニュープロセスではNative、インストーラーやアップデータではSquirrel/NSISという技術が使われている。

ブラウザであればWebAPIを使ったテストが必要になるので、ブラウザでラップしたElectronのコードを実行する必要がある。nodeであればnodeでElectronをラップしたテスト、NativeであればNative用のテストツールやフレームワークが動くかどうかの検証が必要になり、最後のインストーラーやアップデータのテストでは、受け入れテストが必要になるが、受け入れテストに関しては省略した。

計画した自動テストの内訳は図の通り。

次にこれらの自動テストをすることでどれだけコストがかかったのかを示したのが次の図だ。

「インテグレーションの部分は非常に遠回りな方法を採用している。ただ下の2つ(イングレーションとアクセプタンス)はやらなくていいと思い始めている」と感想を述べた。

運用まで進むと比較的楽に使える

運用編。「ここまで来ると開発よりは楽になる」と酒巻氏は語る。Electronはマニュアルの通りに作るとさくっと動くからだ。ただ辛いのは認証周り。Gatekeeperとcode signing認証だが、Appleに1万円ほど支払うなどお金がかかるからだ。

あとはマニュアル通りにネットワークインフラが整えばアップデートができるので準備完了。また、既存のWebシステムに部分的にElectronを追加することもできる。

ただし、この場合大変なのは「Electron本体の更新が早いため、手放し運用ができないことだ」と指摘する。「Electronは更新速度が速いプラットフォームなので、ネイティブの部分を作り込むと手痛いしっぺ返しを食らうかも」とも。

社内でElectronを導入することについて。同様のインフラが構築済みの場合は、無理にElectronを利用する必要はない。ただ例外としてフロントエンジニアのリソースが余っているのなら、一考の価値がある。

まだ同じようなインフラができていないばあいについても、Electronにこだわる必要はないとのこと。ただ社内にWebエンジニアがいる場合は、Electronを取り入れる価値はある。

また既存のWebシステムの拡張機能として使うと、既存Webで諦めていた機能が実現可能になるので、「そのような限定的な使い方をしてみれば有効」と説明した。

酒巻氏が挙げた導入に効果のありそうなところは以下の通りだ。

  • 常駐アプリケーション
  • 既存Webシステムの延長
  • XULRunnerと同様の用途
  • Browser Extensionで無理矢理実現していた業務

そして辞めた方がよいところとしては、既存XULRunnerアプリを置き換える、既存WebシステムのElectron化、Windows7以前のOSの対応を挙げた。

「Electronは内製で社内システムだと有用に使える。Electronは素晴らしい技術だが、ただ個人的な感想としては業務デスクトップアプリを作る技術としては.NETが一番」とまとめ、セッションを締めた。

講演資料

※お詫び:「ワンバイナリ」という表現をタイトルに使用しておりましたが、適切ではなかったため、訂正いたしました。

  • 240
  • このエントリーをはてなブックマークに追加

■関連記事

及川卓也・増井雄一郎・白石俊平・湊川あい──新しい言語・フレームワークは何を選ぶ?どう学ぶ?... 得意な言語と好きな言語 本セッションのファシリテーターを務めたのは、及川卓也さん。増井雄一郎さん、白石俊平さんがエンジニア枠、そして湊川あいさんはデザイナーという立場で語っていただいた。 ☆登壇者プロフィール プロダクト・エンジニアリングアドバイザー 及川 卓也さん早稲田大学理工学部卒業後...
技術系コミュニティ運営者たちが語る、コミュニティの成長の軌跡──21cafe 4周年感謝祭レポート... あきらめずに続けることが大事  コミュニティ運営者によるLT大会のトップバッターは、「DevRel Meetup in Tokyo」の中津川氏。 毎月開催しているイベントの参加率はほぼ100%という特徴があり、東京にとどまらずアジア圏にも活動の場を広げている。 今回は「楽しいコミュニティの作り...
【鹿児島の熱量を感じろ!】モバイルの未来は地方こそ主役「MOBILE CONFERENCE 2017... エンジニア・デザイナーのためのカンファレンスが鹿児島で開催 ウェブやモバイルのエンジニア・デザイナーのためのカンファレンス「MOBILE CONFERENCE 2017」。鹿児島キャリアデザイン専門学校マルチホールを会場に開催された。 この日はあいにくの雨天にも関わらず、会場はウェブ・モバイ...
Webで簡単・効率的にアニメーションを実現できる最新フレームワーク・CSS3アニメーションを紹介... MozillaでWebアニメーションの機能の開発者が登壇 Webでアニメーションというと、数年前まではFlashコンテンツが当たり前に使われていた。 しかしスマートフォンの普及と共に、Webから駆逐され、今はHTML5でアニメーションを表すには、setInterval関数やrequestAnim...
「React.js × React Native」―メリット・デメリット、将来はどうなる?【後編】... LT1「Webpackを使ったReact Hot Loaderの導入」 パネルディスカッションの後は、LTタイムに。最初に登壇したのはISAOで社内SNS「Goalous」の開発を行っているフロントおよびサーバサイドエンジニアの吉田将之さん。テーマは「Webpackを使ったReact Hot Lo...
「React.js × React Native」―メリット・デメリット、将来はどうなる?【前編】... React・React Nativeをテーマにパネルディスカッション 3月16日、リクルートテクノロジーズで、React.js meetupとReact Native meetupによる合同勉強会が開催された。 今回の勉強会はWeb開発において急速に普及しつつあるReact、そしてその書き方をベ...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ