ブラウザ枠に絡む命令追加の要望 - 秀丸エディタβ版 - スレッド11163, 2023/04/02

ブラウザ枠に絡む命令追加の要望

春人さん　23/04/02 19:40

秀丸サポート会議室の方に投稿した内容ですが
https://www.maruo.co.jp/hidesoft/2/x40437_.html

ブラウザ枠(WebView2)向けのマクロ命令として
以下のメソッドに相当するコマンドの追加をご検討をお願いします

ブラウザ枠に任意のスクリプトをinjectできる命令
$returnString = ExecuteScript($script, #frame_id)

ブラウザ枠に postMessage できる命令 (ブラウザ枠ページ側の登録ハンドラで受信)
PostWebMessageAsString($payload, #frame_id)
PostWebMessageAsString($json, #frame_id)

指定フォルダを任意のホスト名にマップする命令 (指定したブラウザ枠インスタンス
でのみ有効)
setVirtualHostNameToFolderMapping($hostName, $folderPath, 2)

ブラウザ枠⇒秀丸マクロ方向は ExecuteScript のみ返り値が同期的に１対１が確定
しているのを除くと、
postMessage() は非同期な上に(共通枠の場合)どの秀丸プロセスの、どのマクロ(JS
インスタンス)の、
どのコールバックに送るか？　が面倒なのと、どう同期処理させるか？が悩ましいの
で強くは求めません(笑)

RE:11163 ブラウザ枠に絡む命令追加の要望

western さん　23/04/03 04:47

カッとなって一晩で作った

秀丸エディタでMarkdownをプレビューしながらリアルタイム編集
https://youtu.be/AtwxDZ09Nw0

プレビュー(ブラウザ枠)側からエディタの方へ何かしらフィードバックしたい。
個別ブラウザ側からの postMessage をマクロから触れるキューとして保存して、
マクロ命令で１つずつ取り出す方式なら制約少なく、非同期絡めずに何とかなるか？

ブラウザ枠はまだまだ挙動怪しく、全タブ巻き込んで落ちることもありますね
それぞれ再現性を洗い出したらバグレポート作ります

RE:11164 ブラウザ枠に絡む命令追加の要望

秀丸担当 さん　23/04/03 15:50

動画を拝見させていただきましたが、すごくいい感じですね。
任意のスクリプト実行は、こみやんまさんも触れられていますが（というか既に使わ
れていると思いますが）、setbrowserpaneurlで"javascript:"から始まるアドレスに
することで、ブックマークレットのように実行ができます。
ただ現状は一方通行で、セキュリティ面が心配なこともあり、いまのところ一方通行
にしています。
双方向を可能にすると、相当いろんなことができるようになると思います。
ローカルのhttpサーバーを立てれば無理やりできてしまうと思いますが、そのあたり
も含めて今はブラウザと同じセキュリティと言えるので、何でも可能にするのは慎重
に考えたいです。

また、落ちる場合があるとのことで、すみません。
再現方法などがわかると助かります。
いろいろ調べてみます。

RE:11164 ブラウザ枠に絡む命令追加の要望

western さん　23/04/03 17:19

作成したマクロを共有します
https://drive.google.com/file/d/162hRQ9yeIgDvl2L0Ouer465Zd2RqgkNb/view?usp=share_link

・拡張子 .md のファイルを開いてマクロとして実行
・カーソル移動後タイマーのマクロ自動実行でリアルタイム同期となります

RE:11168 ブラウザ枠に絡む命令追加の要望

western さん　23/04/03 17:57

ExecuteScript は「文字列(スクリプト)を送る」と「文字列が返る」以上の挙動はな
いはずですが、
セキュリティの懸念とは何があるのでしょうか？

RE:11169 ブラウザ枠に絡む命令追加の要望

こみやんま さん　23/04/03 22:30

>作成したマクロを共有します
> ......
>・カーソル移動後タイマーのマクロ自動実行でリアルタイム同期となります

いいコンポーネントを拾ったり制作したりしているなーと関心しました。

ただ、「カーソル移動ごとに実行される」といった自動起動マクロにしてしまうと、
結構マクロ衝突でやっかいになりがちなので、

JS層で非同期で監視し、「カーソルの位置」や「マウスの位置」を考慮したものを制
作してみました。

https://github.com/komiyamma/hm_markdown_liveview

https://github.com/komiyamma/hm_markdown_liveview/releases

Markdownファイル(もしくは無題のマークダウン的な記述)に対して、
HmMarkdownLivePreview.mac を実行。

記述はグダグダですが、JSで作成するのであれば
要素としてはこんな風になるのだろうと思います。

(これでもやはりたま～にマクロの衝突が発生します。
「マクロ実行中ではない」という判定の後実行しているわけですが、
　「判定」と「実際の実行」のわずかな隙間の間にマクロが別件で実行されてしまう
パターン)

RE:11170 ブラウザ枠に絡む命令追加の要望

秀丸担当 さん　23/04/04 09:56

懸念とは、実際のWebページが見れるので、Webページ側が想定していない情報の流れ
ができてしまう可能性があるのではないかと思います。
もしやるとしたらローカルファイルのときだけとか固定の縛られた内容とか、特定の
条件が揃ったときに可能にしたほうがいいかもしれないです。
そうなると、条件によって分けるのもまたリスクがあるので、また別の第三のサンド
ボックスみたいにしたほうがいいかもしれないですが…
どちらかというと最初考えていたのはそちらでした。
双方向は相当魅力的で、できでたらいいです。
また何らかの方法ができたらいいですが、とりあえずブラウザ枠は安心して使えるも
のにしたいところです。
もし安心して使えないという話があったら、場合によっては逆に制約を増やしていく
かもしれないとも思っています。

RE:11172 ブラウザ枠に絡む命令追加の要望

western さん　23/04/04 14:48

ブラウザ枠のコンテキスト(状態)がエディタやマクロから独立した非同期な状態であ
ることで
マクロが「ページが遷移したこと」を把握、監視できないのが特有な事情だと思われ
ます。

https://learn.microsoft.com/ja-jp/microsoft-edge/webview2/concepts/navigation-events
WebView2 ではページが遷移した際に、フックできるイベントが多段階で発生しますが
秀丸マクロの updatecount キーワードで取得可能な値のようなカウンタを持たせ、
(全タブ共通で)インクリメントを行いながら、ページ遷移ごとに個別の値に更新し

その値が一致するページだけと送信受信が可能

という処理で実装ロジック側で想定外を排除できるのではないか？と提案します。

マクロからスクリプトを実行する際には、このカウンタ番号を引数に入れることで
ブラウザ枠がページ遷移していた場合は、通信に失敗するという処理が可能になりま
す。

ブラウザ枠側からメッセージを送る window.chrome.webview.postMessage() についても
その表示されているページのカウンタ番号を引数に入れて登録した受信ハンドラ
だけに送る(複数のリスナ登録不可)という制約を設けることで、
メッセージをカウンタ番号付きでキューに入れて、マクロに順番に引き渡しができ、
リスンしてないカウンタ番号のメッセージは破棄可能、カウンタ変更時は該当のキ
ューを破棄
としてはいかがでしょうか？

ご検討よろしくお願いします。

RE:11174 ブラウザ枠に絡む命令追加の要望

western さん　23/04/04 16:17

■ 想定外をすべて例外処理にするロジック

0. 2^32-1 サイクル(保証)の乱数カウンタ生成器 (同じ精度で乱数を取得できるマク
ロ命令でも可)
0. ブラウザ枠はアドレスが変わるたびに新しい乱数カウンタ番号を取得して保持

■ 安全にブラウザ枠に injectScript / postMessage する

1. ブラウザ枠のメニューにある[クリア]に相当するマクロ命令を実行すると新しい
乱数カウンタ番号が返る
2. その乱数カウンタ番号を指定して setbrowserpaneurl (ex) をする (保持された
番号でないならエラー)
3. マクロからスクリプト実行をするには、この乱数カウンタ番号を引数に入れ、ブ
ラウザ枠の保持と一致しなければエラー

エラー時は対象のブラウザ枠が保持する乱数カウンタ番号を 0 にリセット (乱数カ
ウンタが生成できない番号)

■ 安全にブラウザ枠から postMessage を受け取る

1. 乱数カウンタを指定して setbrowserpaneurl したページからのみ受信が可能
2. 乱数カウンタを指定して受信ハンドラを登録する (ブラウザ枠の番号と一致しな
ければエラー)

秀丸プロセスが WebView2 から window.chrome.webview.postMessage() のメッセー
ジを受け取った時は
そのブラウザ枠の乱数カウンタ番号で受信ハンドラが登録されていなければ破棄 (不
作為の攻撃を抑止)

受信ハンドラが存在していれば、そのブラウザ枠の乱数カウンタ番号を含めてキュー
に入れる
乱数カウンタ番号ごとにJSマクロ内の同期処理が可能な setInterval 的に受信ハン
ドラをコールバックする

これで簡潔で漏れのない同期ロジックになるはずです

ブラウザ枠の保持する番号がマクロと一致する(ページ遷移が発生していない)限りは、
実行したマクロが責任を担保できる状態となります

RE:11175 ブラウザ枠に絡む命令追加の要望

秀丸担当 さん　23/04/04 17:18

WebView2が非同期であることの厄介なことは、確かにあります。
それはそれであるのですが、ここでいうセキュリティ上の懸念というのは、技術的な
問題というより、設計上のポリシーの問題のことになります。
この場所は本物ブラウザと同じで、安心して使ってもらっていいと言える状態にした
いです。

ちなみにマクロのJavaScript対応（jsmode）では、WebView2の非同期的なことをして
いたりします。
これはブラウザ枠/個別ブラウザ枠とは分離した、開いているファイルごとの別のjs
インスタンスになっています。

懸念されているのは、タブモードの複数タブで共通のブラウザ枠と使う場合の同期と
いうことでしょうか。
それをやろうとすると確かに難しいことがあると思いますが、それを必要とするシー
ンでは、タブごとに存在する個別ブラウザ枠のようなものになっているのが一番いい
気がします。
ただ個別ブラウザ枠がそのままできてしまうようになるのは安心できない気がするの
で、それとも分離した、個別のレンダリング枠(仮)のようなものがあったらいいです。
よくわかっていなかったらすみません。

RE:11176 ブラウザ枠に絡む命令追加の要望

western さん　23/04/04 18:10

#11175 で言及した非同期は JavaScript 処理の話ではなく、状態の排他制御がされ
ていないという話となります

ある１回きりのマクロ実行(ブックマークからのスクリプト含む)、あるいは永続する
JSmodeインスタンスにおいて
「今のブラウザ枠は、私(マクロ)が最後に操作したままなのか？」「他の何者も弄っ
ていない保証があるのか」
はセキュリティ的に重要なカギとなります。

現状はこれを識別できるコールバック／フィードバック手段などがないのと、
汚染状態チェックがされずにスクリプト実行できてしまうのが安全性を担保できない
根源となっています。

WebView2 インスタンスは本来ウィンドウ表示されるもので、ヘッドレス(JSmodeがそ
うですが)としても
いわゆる WebDriver による「WebViewの生成から『始末』まで管理」されるオート
メーション操作が基本です。

今回のブラウザ枠はここがネックで、ほかのマクロ実行から WebView2 インスタンス
の排他制御がないまま永続して、
(個別)ブラウザ枠も「GUI操作」「単体マクロ実行」「複数のJSインスタンス」が
『操作を共有できる』恐ろしい状態です(笑)

現状のブラウザ枠のセキュリティリスク要因はこの１点によるものだけです

秀丸エディタ利用ユーザが設定した内容で動作するので、利用ユーザに手落ちがなけ
れば問題はありませんが
悪意のあるマクロや設定を潜ませることが可能な状況です（この手の要因はワクチン
ソフトは面倒見てくれないので）

Chromium の WebView は electron/nwjs/WebView2 として分離されて多様な利用が始
まって以来
多くのセキュリティ懸念が散在していて、実際に VS Code などの開発時にハッカー
(笑)から
の大量の報告があり洗い出しが賑わって楽しい時期がありました。

現状では WebView2 内での操作においてセキュリティリスクはほぼ無くなっている
(アップデートもされる)状況で、
あとはコンポーネントを使う側が #11177 で報告したようなイベントを適切にハンド
ルできているか？だけです

意図して開けたトリッキーな入口 (これがスクリプトのInject) の外部要因がなけれ
ば、ほぼ安全といえます

あとはInjectするスクリプト実行が「意図した状態から」実行されているか？
メッセージ通信を送ってくる相手が「意図した相手から」のものか？

外部由来を許可する限り、解決する方法は適切な汚染チェックの仕組みの導入だけです

RE:11171 ブラウザ枠に絡む命令追加の要望

western さん　23/04/04 19:41

getUpdateCount() の比較と getUpdateCount() の比較の両方をやっていますが
一文字書いてアンドゥなら、変わってない判定としての削減が意図でしょうか

カーソル位置取得、更新カウント取得、全テキスト取得いずれも非同期なのと
WebView2 操作の命令は[非同期]で問題ない処理なので
hidemaru オブジェクトにブラウザ枠のコマンド対応が待ち遠しいですね

１文字単位リアルタイムが好みだったので、高速タイピングに追随して
恐ろしい勢いで連打されるスクリプト処理となりました。

javascript:boxScroll() は、範囲選択の先頭と終端の２つの引数で渡すと
少し幸せになれます (htmlはもともと対応済み。マクロ側の実装忘れ)
マウスカーソルで追随されると悲しみ。好みのオプションいりますね

他のプレビュー系もいけるかと試してはいるのですがSourceMapな情報
が取れるパーサ部分使えるモジュールが意外と見つけられなくて難儀です
(Markdownだけは運よくトランスパイル部分への改造でいけましたが)

逆コンパイル、デコーダ系はブラウザ枠からのフィードバックができないと楽しく作
れないですね
（Markdown もブラウザ枠内のクリックでエディタのカーソル移動させたい）

RE:11178 セキュリティとは...

こみやんま さん　23/04/04 19:45

個人的には、秀丸のプロセスという意味では、ネイティブのdll動作できるようにし
てある時点で「セキュリティとは？」っていうレベルでしょうし、
「仮に秀丸が直接提供している機能のみで実現できるもの」に絞ったとしても、
setbrowserpaneurlで任意のサイトの任意のURLやクエリを構成できるる時点で
いくらでも該当PCのの環境変数やレジストリ情報やファイル構成情報、
ファイルの中身の情報などを
ネット経由で収集し(され)放題なので、
もうすでに「セキュリティって？」っていう構成になっているのでは？と個人的に
は思ってるんですが、違うのかな？

一方で便利なものはどんどんSAAS化していくので、外部Web全部遮断となると長い目
ではかなり微妙でしょうし。

テクニカルというよりもサイトー企画としてのスタンスの表明という印象。

RE:11180 セキュリティとは...

western さん　23/04/04 21:02

モノづくりに関係者の思想的なこだわりは最重要だと思いますが、
充分なセキュリティや複数の対策法があるのに杞憂で怖がっているのか
リスクに気付いていないから放置となりそうなのか
ポリシーの向いてる方向が察せられないところがあります

RPAやWebDriverのオートメーション機能がOSや専用ブラウザ的なものに
標準機能として添付されていたりと、情報を取得する方向の仕組みの
ここ３年くらいで広告も案件も溢れていますし、SAASやエコシステムにびっくりしき
りです

サポートの方でも、秀丸エディタを経由してそういう加工が目的と思われる
質問も多く見受けられます (企業の業務指示や事業なのかもしれませんが)

現状の意図しない情報漏洩につながるセキュリティホールは潰して頂きたいですし
思想的な「超限定的」であっても双方向は期待してしまいます

様々なChromeコンポーネント操作やハックを経験しての要望と助言ではあるのですが、
過剰すぎる要望や指摘なのであれば明らかなバグ以外は正式版になってからの指摘と
したいと思います

利用ユーザの悪意はどうしようもないですが、
疎い利用者がやらかしがちなトラブル防止の上級者モードという思想や
制限解除などでの対応は推奨するところです (Windows自体も開発者モード前提なｗ)

RE:11181 セキュリティとは...

秀丸担当 さん　23/04/05 10:14

詳しいことありがとうございます。
言われていることがようやくわかりました。
とりあえず情報の取得については、ブラウザ枠ではやるつもりではなくなっています。

一方的な実行については、本物ブラウザのブックマークレットと同じというスタンス
のつもりではありました。
ですが、実際のWeb上のコンテンツをいじるのは現実的ではないし、httpでは実行さ
せないようにして、ローカルファイルやクリア状態だけの実行にするのが妥当かもし
れないです。
さらに厳密にするなら、ご提案の方法もありかと思います。
ローカルでない任意の外部の１ページは、ちょっとわからないです。

マクロ等の実行はユーザーの任意ではありますが、最近はcurlとかで簡単に送信でき
たりしますし、悪さをしようという行為があるとすれば、秀丸エディタやネイティブ
DLLだからという話でもない気がします。
ブラウザ枠の枠組み１つでいろいろ両立しようとすると、そのうちどこかで無理が出
てくる気がするというか、無理が出ないにしても使う側はちょっと心配になるんじゃ
ないかと思います。

ブラウザ枠は、本物ブラウザができること以上の緩い方向には向かわず、もし安心で
きないことがあるとしたら厳しいほうにしたほうがいいと思います。
双方向の操作で、レンダリングやUI目的のことが必要になってくるとしたら、ブラウ
ザ枠とは別の分離したものを作ったほうがいいと思います。
１ページに限定で実際の外部のWeb情報の操作が必要になってくるとしたら、テキス
トエディタの領分を超えているというか、レンダリングを伴わないxmlhttpなんとか
とかcurlとかfetchとかみたいな手法のほうがいい気がします。

RE:11182 セキュリティとは...

western さん　23/04/05 16:41

ご丁寧な回答ありがとうございます

curl/fetch というワードが出てきていますが、それらは
当方が要望している話に一切絡みようがない話なので
根本的に齟齬があるのだと思います

セキュリティや、悪意あるユーザの手段としての loadDLL
なんかも、絡まない次元での話となります

双方向(特に希望するに受信方向)は
「文字列が受け渡される」以上の存在は出てこないので
レンダリングやUI が関与することもあり得ない領分です

file:// 限定なら許可であるとか http:// は不許可など
その辺も、違いがあるという認識の理由が思い当たりません

どこかで無理が出てくるという言い回しがありますが
非公式なトリッキーなギミックを作るわけではなく
もともと用意された仕組みを正しく使うだけのことなので
今後のバージョンアップなどで何をするときに悩ましい問題や
衝突が出てくるかも、想像がつかないところであります

利用ユーザ、あるいはマクロ機能として

秀丸エディタを利用して、具体的にどのような行為／処理をされてしまう

ことが、思想的に折り合わないのか
利用する上で尊重したいラインをお伺いしたいところではあります

RE:11187 セキュリティとは...

秀丸担当 さん　23/04/05 17:30

httpで不可としたらいいんじゃないかと思うのは、ほとんどの公にあるwebページ側
がたぶんそれを想定していないからです。
具体的には、一方的な実行では勝手にボタンを増やしたり消したり書き換えたりでき
ます。でもそれは本物ブラウザでもできるのでセキュリティ的には同じと言い張れも
したのですが、やっぱりあまり適切ではないと思います。
読み取りで具体的なこととしては、例えばクッキーでログインするページがあったと
したら画面に現れるものを勝手に見られたくないんじゃないかと思います。
あとこみやんまさんがchatGPTのマクロなんか作っていただけていますが、そういう
有料につながるサービスがあったとして、webページ内容を読み取ってできてしまう
かもしれないのは適切ではないと思います。

ローカル上での排他制御はもちろんできたらいいですが、できなくても共有できる
ツールになりえるかもしれないです。
例えば一方通行ではリッチなアウトプット枠的なものだったり、双方向だったら何か
リッチな候補を出して選択みたいな感じでしょうか。

web上のリクエスト/レスポンスでもなく、ローカルのレンダリング/UIでもないとし
たら、どういうことを想定されたことなのかわからなくなってきました。

RE:11190 セキュリティとは...

western さん　23/04/05 18:54

主要ブラウザの公式ストアでは、

広告を消してしまうもの
特定(のこだわりデザイン)ページで、見やすくデザインを書き換える
他のページのデータをくっ付けて、便利にするもの

がトップに並んで配布されていて、
Opera/Vivaldi などのメジャーのブラウザでも標準で同梱され有効だったりします

セキュリティをアピールブラウザほど、サイト運営者の意図からほど遠くなるのが現
状です

……が、こういったソフトウェアは適切ではない、という思想であればそれは納得す
る話です

RE:11190 セキュリティとは...

western さん　23/04/05 18:56

ログインページにのみ出てくるプライベートな個人情報や、隠しAPIキーなどは

(1) 操作ユーザの悪意 (上記の適切ではないという思想、啓蒙はしても禁止は出来ない)
(2) マクロ製作者の悪意 (いわゆるセキュリティホール)

を切り分けて考えるべきで (1) はどうしようもなく (2) を如何に防ぐか？
という話になると思います。

『汚染チェック』というワードを先のコメントで使いましたが

マクロでページを起動する際は「常に新規インスタンスのプライベートブラウザ」とし
一度でも POST が行われた場合は「汚染(不正)の可能性がある状態」とする
などで (2) は割と簡単に防止可能です (もう少しブラウザ事情の条件ありますが)

RE:11190 セキュリティとは...

western さん　23/04/05 19:05

http(s):// のページでもスクリプトを許可制にする仕組みとして

X-Hidemaru-Permission: "マクロで指定した文字列と一致のチェック"

のようなHTTPレスポンスがあるページについては javascript: 実行(や双方向) を許可
などのチェックの仕組みを導入するための手段も WebView は想定されていて
特定のフックイベントでのロジックを組むことは可能となっています

「公にあるwebページ側がたぶんそれを想定していない」というサイトは当然に
このヘッダは送ってくるはずもないので、不適切な処理の防止が保証されます