Electron API の履歴がドキュメント内で詳解されるようになります。
こんにちは 👋、2024 年 Google Summer of Code (GSoC) の Electron のコントリビューターの、Peter です。
GSoC プログラムの過程で、Electron ドキュメントとその関数、クラスなどに API の履歴の機能を実装しました。これは、Node.js ドキュメント と同様の方法で、API ドキュメントの Markdown ファイルにシンプルかつ強力な YAML スキーマを使用できるようにし、Electron ドキュメントのウェブサイトでわかりやすく表示することで実現しました。
Electron 32.0.0 がリリースされました! これには Chromium 128.0.6613.36、V8 12.8、Node 20.16.0 へのアップグレードが含まれています。
Electron チームは、Electron 32.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。
何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。
webcontents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 以前のナビゲーション API は非推奨になりました。 #41752128.0.6613.36
20.16.0
12.8Electron 32 では、Chromium は 126.0.6478.36 から 128.0.6613.36 へ、Node は 20.14.0 から 20.16.0 へ、V8 は 12.6 から 12.8 へとアップグレードしています。
app モジュールの 'login' イベントを介して応答するためのサポートが追加されました。 #43317CPUUsage 構造体に cumulativeCPUUsage プロパティを追加しました。このプロパティは、プロセスの起動以降に使用された CPU 時間の累計秒数を返します。 #41819webContents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 #41752WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42086nativeTheme に新しいプロパティ prefersReducedTransparency を追加しました。これは、ユーザーがシステムのアクセシビリティ設定を介して OS レベルの透過度を下げることを選択したかどうかを示します。 #43137zstd 圧縮を使えるようにしました。 #43300File.pathウェブの File オブジェクトの非標準の path プロパティは、レンダラー内ですべてを実行するのが一般的だった時代に、ネイティブのファイルを操作する便利な方法として Electron の初期バージョンで追加されました。 ただし、これは標準からの逸脱であり軽微なセキュリティリスクも伴うため、Electron 32.0 以降では webUtils.getPathForFile メソッドに置き換えられました。
// 以前 (レンダラー)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);
// これから (レンダラー)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);
// これから (プリロード)
const { contextBridge, webUtils } = require('electron');
contextBridge.exposeInMainWorld('electron', {
showFilePath(file) {
// できればウェブコンテンツへの完全なファイルパスを
// 公開しないことを推奨します。
const path = webUtils.getPathForFile(file);
alert(`Uploaded file path was: ${path}`);
},
});
WebContents の clearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffsetWebContents インスタンスのナビゲーション関連の API が非推奨になりました。 これらの API は、ナビゲーション履歴を管理するための、より構造化された直感的なインターフェースを提供するために、WebContents の navigationHistory プロパティへ移動されました。
// 非推奨
win.webContents.clearHistory();
win.webContents.canGoBack();
win.webContents.goBack();
win.webContents.canGoForward();
win.webContents.goForward();
win.webContents.goToIndex(index);
win.webContents.canGoToOffset();
win.webContents.goToOffset(index);
// こちらで置き換えてください
win.webContents.navigationHistory.clear();
win.webContents.navigationHistory.canGoBack();
win.webContents.navigationHistory.goBack();
win.webContents.navigationHistory.canGoForward();
win.webContents.navigationHistory.goForward();
win.webContents.navigationHistory.canGoToOffset();
win.webContents.navigationHistory.goToOffset(index);
プロジェクトの サポートポリシー に則り、Electron 29.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。
| E32 (2024 年 8 月) | E33 (2024 年 10 月) | E34 (2025 年 1 月) |
|---|---|---|
| 32.x.y | 33.x.y | 34.x.y |
| 31.x.y | 32.x.y | 33.x.y |
| 30.x.y | 31.x.y | 32.x.y |
短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。
Electron の公開タイムラインはこちらで ご覧いただけます。
今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。
Electron 31.0.0 がリリースされました! これには Chromium 126.0.6478.36、V8 12.6、Node 20.14.0 へのアップグレードが含まれています。
Electron チームは、Electron 31.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。
何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。
WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42319NODE_EXTRA_CA_CERTS のサポートを追加しました。 #41689WebSQL のサポートを削除しました #41868nativeImage.toDataURL が PNG 色空間を保つようにしました #41610webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432126.0.6478.36
20.14.0
12.6Electron 31 では、Chromium は 124.0.6367.49 から 126.0.6478.36 へ、Node は 20.11.1 から 20.14.0 へ、V8 は 12.4 から 12.6 へとアップグレードしています。
Session に clearData メソッドを追加しました。 #40983
Session.clearData API に options パラメーターを追加しました。 #41355navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 #41638NODE_EXTRA_CA_CERTS 環境変数のサポートを追加しました。 #41689webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432WebContentsView を既存の WebContents インスタンスを受け入れるように拡張しました。 #42319navigationHistory と navigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 #41577 (及び 29, 30)WebSQL のサポートChromium は WebSQL の上流サポートを削除し、Android のみに移行しました。 詳細は Chromium の削除する意図についての議論 をご参照ください。
nativeImage.toDataURL が PNG 色空間を保つようにしましたPNG デコーダの実装が色空間データを保持するように変更されました。 この関数から返される符号化されたデータは元と一致するようになります。
詳細は crbug.com/332584706 をご参照ください。
win.flashFrame(bool) を macOS 上で持続的に点滅するようにしましたこれにより、Windows および Linux と同等の動作になります。 以前の動作: 最初の flashFrame(true) は Dock のアイコンを 1 回バウンスするだけ (NSInformationalRequest レベルを使用する場合) で、flashFrame(false) は何も行いません。 新しい動作: flashFrame(false) が呼び出されるまで、持続的に点滅します。 これは代わりに NSCriticalRequest レベルを使用しています。 NSInformationalRequest を明示的に使用してこれまで通り一度だけの Dock のアイコンをバウンスさせたい場合は、dock.bounce('informational') を使用できます。
プロジェクトの サポートポリシー に則り、Electron 28.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。
| E31 (2024 年 6 月) | E32 (2024 年 8 月) | E33 (2024 年 10 月) |
|---|---|---|
| 31.x.y | 32.x.y | 33.x.y |
| 30.x.y | 31.x.y | 32.x.y |
| 28.x.y | 29.x.y | 31.x.y |
短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。
Electron の公開タイムラインはこちらで ご覧いただけます。
今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。
Electron 30.0.0 がリリースされました! これには Chromium 124.0.6367.49、V8 12.4、Node.js 20.11.1 へのアップグレードが含まれています。
Electron チームは、Electron 30.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。
何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。
@electron/packager@18.3.1 または @electron/forge@7.4.0 にアップグレードしてください。WebContentsView と BaseWindow メインプロセスモジュールを追加しました。これは BrowserView を非推奨にして置き換えるものです (#35658)
BrowserView は WebContentsView の上のシムとなり、古い実装は削除されました。WebContentsView API と他の類似 API との比較については、私たちの Web 埋め込み ドキュメント をご参照ください。124.0.6367.49
20.11.1
12.4Electron 30 では、122.0.6261.39 から 124.0.6367.49 へ、Node は 20.9.2 から 20.11.1 へ、V8 は 12.2 から 12.4 へとアップグレードしています。
transparent のウェブ環境設定 を追加しました。 (#40301)navigationHistory と navigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 (#41662)BrowserWindow.isOccluded() メソッドを追加しました。これによりアプリが覆い隠されている状態を確認できるようになります。 (#38982)net モジュールを使用して行われたリクエストに対するプロキシ構成サポートを追加しました。 (#41417)navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 (#41734)NODE_EXTRA_CA_CERTS CLI フラグのサポートを追加しました。 (#41822)クロスオリジンの iframe にアクセスするには、特定の iframe で利用可能な機能を allow 属性を介して指定しなければなりません。
詳細は ドキュメント をご参照ください。
--disable-color-correct-rendering コマンドラインスイッチこのスイッチは正式にドキュメント化されたことはありませんが、削除したことをここに注記しておきます。 Chromium 自体が色空間のサポートを強化したため、このフラグは必要なくなります。
BrowserView.setAutoResize の動作Electron 30 では、BrowserView は新しい WebContentsView API のラッパーになりました。
以前の BrowserView API の setAutoResize 関数は、macOS では autoresizing で、Windows と Linux ではカスタムアルゴリズムによって支えていました。
BrowserView をウインドウ全体に表示するなどの単純な使用例では、これら 2 つのアプローチの動作は同じでした。
ただしより高度なケースでは、Windows および Linux のカスタムサイズ変更アルゴリズムが macOS の自動サイズ変更 API の動作と完全に一致しませんでした。そのめ、BrowserView の自動サイズ変更は macOS 上では他のプラットフォームとは異なる動作でした。
この自動サイズ変更の動作がすべてのプラットフォーム間で標準化されました。
もしあなたのアプリが BrowserView をウィンドウ全体に表示するよりも複雑な操作を BrowserView.setAutoResize で行っていたのならば、macOS でのこの動作の違いに対処するカスタムロジックを既に用意していたことでしょう。
その場合、Electron 30 からは自動サイズ変更の動作が一貫し ているため、そのロジックは必要なくなります。
WebContents の context-menu にある params.inputFormType プロパティWebContents の context-menu イベント内の params オブジェクトにある inputFormType プロパティを削除しました。 代わりに新しい formControlType プロパティを使用してください。
process.getIOCounters()Chromium はこの情報へのアクセスを削除しました。
プロジェクトの サポートポリシー に則り、Electron 27.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。
| E30 (Apr'24) | E31 (2024 年 6 月) | E32 (2024 年 8 月) |
|---|---|---|
| 30.x.y | 31.x.y | 32.x.y |
| 29.x.y | 30.x.y | 31.x.y |
| 28.x.y | 29.x.y | 30.x.y |
短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。
Electron の公開タイムラインはこちらで ご覧いただけます。
今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。
Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。
プログラムの詳細については、Google の Summer of Code のホームページ をご覧くださ い。
Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。
Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。
Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの 貢献者の一部と協力して頂きます。
Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。
Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。
npm init electron-app@latest my-app
コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。
Google Summer of Code に初めて参加する方やオープンソース全般に馴染みがない方は、コミュニティに参加する前に、まず Google の 貢献者ガイド を読むことをお勧めします。
Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。
この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。
応募には以下のものがあるとよいでしょう。
Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。
計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。
応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。
2022 年の Google Summer of Code では、インターンの @aryanshridhar さんには素晴らしい働きをして頂きました。 Aryan さんが夏に Electron で取り組んだことを確認したい方は、2022 GSoC プログラムのアーカイブ から彼のレポートを閲覧できます。
ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。
Electron 29.0.0 がリリースされました! これには Chromium 102.0.6261.39、V8 12.2、Node.js 20.9.2 へのアップグレードが含まれています。
Electron チームは、Electron 29.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。
何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。
webUtils モジュールを追加しました。これは Web API のオブジェクトと対話するユーティリティレイヤーを提供するレンダラープロセスのモジュールです。 このモジュールで最初に利用可能な API は webUtils.getPathForFile です。 Electron の以前の File.path 拡張は Web 標準から逸脱していましたが、この新しい API は現在の Web 標準の動作に沿ったものになっています。122.0.6261.39
20.9.0
12.2Electron 29 では、120.0.6099.56 から 122.0.6261.39 へ、Node は 18.18.2 から 20.9.0 へ、V8 は 12.0 から 12.2 へとアップグレードしています。
webUtils モジュールを追加しました。これは File.path 拡張を置き換えるものです。 #38776grantFileProtocolExtraPrivileges を追加しました。これは、file:// プロトコルを Chromium と一致するよりセキュアな動作に制限するものです。 #40372protocol.registerSchemesAsPrivileged に追加しました。 #40544app.{set|get}LoginItemSettings(settings) を macOS 13.0 以降で Apple 推奨の新しい基盤フレームワークを使用するように移行しました。 #37244ipcRenderer は contextBridge を越えて送信できなくなりました。ipcRenderer モジュール全体をオブジェクトとして contextBridge 経由で送信しようとすると、ブリッジの受信側には空のオブジェクトが生成されるようになりました。 この変更は、セキュリティの落とし穴を撤去/軽減するために行われました。 ipcRenderer やそのメソッドをブリッジ越しに直接公開してはいけません。
代わりに、以下のような安全なラッパーを用意してください。
contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});
app の renderer-process-crashed イベントapp での renderer-process-crashed イベントは削除されました。
代わりに新しいイベントである render-process-gone を使用してください。
// 削除済み
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});
// こちらで置き換えてください
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});
WebContents と <webview> の crashed イベントWebContents と <webview> の crashed イベントは削除されました。
代わりに新しいイベントである render-process-gone を使用してください。
// 削除済み
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});
// こちらに置き換えてください
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});
app の gpu-process-crashed イベントapp の gpu-process-crashed イベントは削除されました。
代わりに新しいイベントである child-process-gone を使用してください。
// 削除済み
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});
// こちらに置き換えてください
app.on('child-process-gone', (event, details) => {
/* ... */
});
プロジェクトの サポートポリシー に則り、Electron 26.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。
| E29 (Feb'24) | E30 (Apr'24) | E31 (2024 年 6 月) |
|---|---|---|
| 29.x.y | 30.x.y | 31.x.y |
| 28.x.y | 29.x.y | 30.x.y |
| 27.x.y | 28.x.y | 29.x.y |
この度 Electron がコミュニティの Request for Comments (RFC) のプロセスを追加したことはご存知でしょうか? フレームワークに機能を追加したい場合、RFC はその設計においてメンテナとの対話を始める有用なツールとなります。 プルリクエストで議論されている今後の変更も確認できます。 詳細については、electron/rfcs の紹介 のブ ログ記事をご覧いただくか、electron/rfcs リポジトリの README を直接ご確認ください。
短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。
Electron の公開タイムラインはこちらで ご覧いただけます。
今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。
Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。
要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。
現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。
より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。
このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。
RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。
簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。
提唱の RFC は次のように遷移します。
main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。RFC が アクティブ になるには、PR が少なくとも 2 人の API ワーキンググループのメンバーによって承認されなければなりません。 マージ前に、RFC は WG メンバーの 3 分の 2 以上の定足数によって開かれた会議で同期的に提示され、全会一致で承認される必要があります。 合意に達した場合、1 か月の最終コメント期間 が開始され、その後 PR がマージされます。
実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。
Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!
text フォルダ を参照してください。私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。
Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。
今日このごろ、いくつかの有名な Electron アプリに対して最近提出された公開 CVE について Electron チームが警告を受けました。 CVE は、Electron の 2 つの fuse - runAsNode と enableNodeCliInspectArguments - に関連しており、これらのコンポーネントを積極的に無効化しない場合、遠隔攻撃者がこれらのコンポーネントを介して任意のコードを実行できると誤って主張しています。
これらの CVE が誠意を持って提出されたとは考えていません。 まず、この記述は誤りで す - この構成では遠隔コード実行は 不可能です。 第二に、これらの CVE で指摘されている企業は、バグ報奨金プログラムを実施しているにもかかわらず、そのバグを通知されていません。 最後に、問題のコンポーネントを無効にするとアプリのセキュリティが強化されることは信じられますが、その CVE が適切な重大度で登録されているとは考えられません。 「Critical」は最も危険な問題に対して予約されたものですが、今回の場合は明らかに当てはまりません。
CVE は誰でも発行できます。 これはソフトウェア業界全体の健全性にとっては良いことですが、一人のセキュリティ研究者が評判を高めるために「CVE を稼ぐ」ことは役立ちません。
とはいえ、恐ろしい「重大」な深刻度を持つ CVE が存在するだけでエンドユーザーの混乱を招く可能性があることは理解しています。そのためプロジェクトとして、問題に対処するためのガイダンスと支援を提供したいと考えています。
CVE をレビューしたところ、Electron チームはこれらの CVE は重大でないと判断しました。
この攻撃者は、ハードウェアに物理的にアクセスするか、完全な遠隔コード実行を実現することによって、マシン上で任意のコマンドを実行できる必要があります。 これは繰り返しとなっています。ここで説明されている脆弱性を利用するには、攻撃者が対象のシステムに既にアクセスできていなければなりません。
例えば、Chrome は 脅威モデルで物理的にローカルな攻撃を考慮していません。
これらの攻撃は Chrome の脅威モデルの範囲外であると考えています。これは、ユーザとしてデバイスにログインした悪意のあるユーザーや、オペレーティングシステムのユーザアカウントの権限でソフトウェアを実行できる悪意のあるユーザーから Chrome (または任意のアプリケーション) を保護する方法がないためです。 このような攻撃者は、実行可能ファイルや DLL を変更したり、
PATHなどの環境変数を変更したり、構成ファイルを変更したり、ユーザアカウントが所有するデータを読み取ったり、それを攻撃者自身に電子メールで送信したりできます。 このような攻撃者はデバイスを完全に制御できるため、Chrome が施せる対策では防御を完全に保証できません。 この問題は Chrome に特有のものではありません — すべてのアプリケーションは物理的にローカルなユーザを信頼せざるをえません。
CVE に記載されているエクスプロイトにより攻撃者は、影響を受けるようなアプリを、継承された TCC (透明性、同意、制御) の権限を持つ汎用 Node.js プロセスとして使用できるようになります。 したがって、たとえばアプリにアドレス帳へのアクセスが許可されている場合、攻撃者はそのアドレス帳へのアクセスを継承するアプリを Node.js として実行し、任意のコードを実行できます。 これは一般に「Living Off The Land」攻撃として知られています。 攻撃者は通常、PowerShell や Bash などのツールを用いて任意コード実行をします。
デフォルトでは、リリースされている全バージョンの Electron は runAsNode と enableNodeCliInspectArguments の機能が有効です。 Electron Fuses のドキュメント で説明されているように、これらをオフにしていない場合、アプリが「Living Off the Land」攻撃に利用される危険性は同様に高くなります。 繰り返し強調しますが、攻撃者は 既に 被害者のマシン上でコードとプログラムを実行できている必要があります。
この問題を軽減する最も簡単な方法は、あなたの Electron アプリの runAsNode の Fuse を無効化することです。 runAsNode ヒューズは、ELECTRON_RUN_AS_NODE 環境変数が尊重されるかどうかを切り替えます。 これらのヒューズを切り替える方法については、Electron Fuses のドキュメント をご参照ください 。
注意としてこの Fuse が無効になっている場合、メインプロセスの process.fork はこの環境変数に依存して動作するため、期待通りに動作しなくなることがあります。 代わりに、ユーティリティプロセス を使用することを推奨します。これは、スタンドアロンの Node.js プロセス (SQLite サーバーのプロセスや同様の場合) が必要な多くのユースケースで機能します。
Electron アプリで推奨されるセキュリティのベストプラクティスの詳細については、セキュリティチェックリスト をご覧ください。
Electron 28.0.0 がリリースされました! これには Chromium 120.0.6099.56、V8 12.0、Node.js 18.18.2 へのアップグレードが含まれています。
Electron チームは、Electron 28.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。
何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。
UtilityProcess API のエントリポイントなどの領域も含まれます。 詳細については 私たちの ESM の ドキュメント をご参照ください。120.0.6099.56
18.18.2
12.0UtilityProcess API に ESM エントリポイントを追加しました。 #40047display オブジェクトに、detected、maximumCursorSize、 nativeOrigin を含むいくつかのプロパティを追加しました。 #40554ELECTRON_OZONE_PLATFORM_HINT 環境変数のサポートを追加しました。 #39792WebContents.backgroundThrottling を false にすると、ホストの WebContents 内のすべての BrowserWindow に影響しますWebContents.backgroundThrottling を false に設定すると、BrowserWindow によって表示されるすべての WebContents でのフレーム抑制が無効になります。
BrowserWindow.setTrafficLightPosition(position)BrowserWindow.setTrafficLightPosition(position) は削除されたので、代わりに BrowserWindow.setWindowButtonPosition(position) API を使用してください。こちらは、デフォルトの位置へリセットする際に { x: 0, y: 0 } ではなく null を受け取るようになっています。
// Electron 28 で非推奨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });
// こちらに置き換えてください
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);
BrowserWindow.getTrafficLightPosition()BrowserWindow.getTrafficLightPosition() は削除されたので、代わりに
BrowserWindow.getWindowButtonPosition() API を使用してください。こちらは、カスタム位置が無ければ { x: 0, y: 0 } ではなく null を返すようになっています。
// Electron 28 で削除
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// カスタム位置が無い時。
}
// こちらに置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
// カスタム位置が無い時。
}
ipcRenderer.sendTo()ipcRenderer.sendTo() API は削除されました。 これはレンダラー間で MessageChannel を設置するように置き換える必要があります。
IpcRendererEvent の senderId と senderIsMainFrame のプロパティも削除されました。
app.runningUnderRosettaTranslationapp.runningUnderRosettaTranslation プロパティは削除されました。
代わりに app.runningUnderARM64Translation を使用してください。
// 削除されました
console.log(app.runningUnderRosettaTranslation);
// こちらで置き換えてください
console.log(app.runningUnderARM64Translation);
プロジェクトの サポートポリシー に則り、Electron 25.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。
| E28 (Dec'23) | E29 (Feb'24) | E30 (Apr'24) |
|---|---|---|
| 28.x.y | 29.x.y | 30.x.y |
| 27.x.y | 28.x.y | 29.x.y |
| 26.x.y | 27.x.y | 28.x.y |
短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。
Electron の公開タイムラインはこちらで ご覧いただけます。
今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。
2023 年の Electron の開発者エコシステムの改善と変化を振り返ります。
過去数ヶ月で、Electron アプリの開発者体験を強化するために、Electron エコシステム全体でいくつかの変更を醸成してきました。 Electron HQ からの最新の追加の速報はこちらです。
Electron Forge 7、Electron アプリケーションのパッケージ化と頒布のためのオールインワンツールの最新メジャーバージョンが利用できるようになりました。
Forge 6 は v5 からの完全な書き換えでした。v7 のスコープは小さいですが、いくつかの改善点が含まれています。 今後も、破壊的変更が必要になり次第、Forge のメジャーバージョンを発行していきます。
詳細については、GitHub 上の Forge v7.0.0 変更ログ をご覧ください。
notarytool に切り替え ました: 2023-11-01 時点で、Apple は macOS の公証のための altool をレガシーとしました。今回のリリースでは Electron Forge からこれを完全に削除します。electron-prebuilt と electron-prebuilt-compile のサポートを終了しました: electron-prebuilt は Electron の npm モジュールの元々の名前で, これは v1.3.1 で electron に置き換えられていました。 electron-prebuilt-compile はその DX 機能が強化された代替バイナリでしたが、最終的にプロジェクトとして放棄されました。forge.config.js ファイルをサポートするようになりました。 (P.S. Electron 28 での ESM エントリポイントのサポートをご期待ください。)🙇 Forge の設定で GCS パブリッシャーと ESM の両方のサポートに貢献していただいた mahnunchik** さんに多大な感謝を送ります!
Squirrel.Windows と Squirrel.Mac は、Electron に組み込まれた autoUpdater モジュールの土台となるプラットフォーム固有のアップデーター技術です。 両方のプロジェクトは次の 2 つの方法で自動更新をサポートしています。
従来のアップデートサーバーの手法は Electron アプリに推奨されるアプローチ (かつ更新ロジックの追加カスタマイズを提供するもの) でしたが、これには大きな欠点があります。それは、アプリがクローズドソースの場合、独自のサーバーインスタンスをメンテナンスする必要があることです。
一方、静的ストレージの手法は常に可能でしたが、Electron 内で文書化されておらず、Electron のツールパッケージの間でサポートされていませんでした。
@MarshallOfSound さんの素晴らしい働きにより、サーバーレス自動アプリ更新のアップデートのシナリオが大幅に能率化されました。
autoUpdater 互換の更新マニフェストを出力する設定ができるようになりました。update-electron-app の新しいメジャーバージョン (v2.0.0) で、これらの生成されたマニフェストを update.electronjs.org サーバーの代替として読み込めるようになりました。メーカーとパブリッシャーが更新マニフェストをクラウドファイルストレージへアップロードするように設定すれば、以下の数行の設定で自動更新を有効化できます。
const { updateElectronApp, UpdateSourceType } = require('update-electron-app');
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
📦 もっと知りたいですか？ 詳細なガイドにつきましては、Forge の自動更新のドキュメント をご参照ください。
@electron/ で拡張された世界はじめに Electron が始動したとき、コミュニティは Electron アプリケーションの開発、パッケージ化、頒布の体験向上のために多くのパッケージを公開しました。 これらのパッケージの多くは Electron の GitHub Organization に組み込まれ、コアチームがそのメンテナンスを負担していました。
2022 年には、npm の @electron/ 名前空間の下で、これらのファーストパーティツールをすべて統一し始めました。 この変更により、以前の electron-foo パッケージは npm で @electron/foo になり、かつて electron/electron-foo という名前だったレポジトリは GitHub 上で electron/foo となりました。 これらの変更は、ユーザーランドとファーストパーティのプロジェクトを明確に分別するのに役立ちます。 これには以下のような、一般的に使用されているパッケージが多数含まれます。
@electron/asar@electron/fuses@electron/get@electron/notarize@electron/osx-sign@electron/packager@electron/rebuild@electron/remote@electron/symbolicate-mac@electron/universal今後リリースされるファーストパーティパッケージも、すべて @electron/ 名前空間になります。 このルールには 2 つの例外があります。
electron パッケージの下で引き続き公開されます。@electron-forge/ 名前空間の下にその monorepo パッケージ全てを公開し続けます。⭐ この過程で、私たちは誤って electron/packager リポジトリを非公開にしてしまいました。これにより、GitHub のスターの数を消えるという不幸な副作用がありました (消える前は 9000 以上でした)。 Packager をいつもご利用の方は、⭐ スター ⭐ していただけると幸いです！
@electron/windows-sign の紹介2023-06-01 以降、業界標準は FIPS 準拠のハードウェアに格納される Windows のコード署名証明書の鍵を要求するようになりました。
実際には、CI 環境でビルドおよびサインインを行うアプリにとってのコード署名が非常に困難になりました。 多くの Electron ツールは、設定パラメータとして証明書ファイルとパスワードを取り込み、そこからハードコードされたロジックで署名しようとします。
この状況は Electron 開発者にとって共通の苦痛となっています。だからこそ、Windows のコード署名をスタンドアローンな手順へと分離する改善策に取り組んでいるのです。この手順は macOS で @electron/osx-sign が行うこと に似ています。
将来的には、このパッケージを Electron Forge のツールチェーンに完全に統合する予定ですが、現在は独自のものになっています。 そのパッケージは現在 npm install --save-dev @electron/windows-sign でインストールでき、プログラムからまたは CLI 経由で利用できます。
レポジトリの Issue トラッカー にてぜひご意見をお寄せください！
私たちは来月から、毎年 12 月の安息期に入る予定です。 私たちはその間、2024 年に Electron の開発体験をさらに向上させる方法について考えていることでしょう。
次に取り組んでほしいことがおありですか？ ぜひお聞かせください！