Webページでタンパーモンキーのユーザースクリプトを検出できますか？
私の質問は、2つに分かれています。 最初、サンドボックスモデルの動作、ユーザースクリプトへの影響、アクセス可能なもの/ Webページとユーザースクリプトの観点から見たもの、および異なるサンドボックスモデルは、スクリプトがページに挿入されている（または挿入されていない）ことに気付くことができるページに影響します。 2番目、どのようにスクリプトがページに挿入され、ページはそれを検出できますか？
最初
私が見ることができるものから、@grant noneを使用すると、サンドボックスが無効になり、WebページとそのJavaScriptにアクセスできるようになります。 JavaScriptやDOMに変更を加えた場合、ページで検出される可能性があります。
私の理解では、@grant unsafeWindowを使用する場合、スクリプトは独自のjsコンテキストに分離され、windowに対して行った操作はWebページに表示されませんが、unsafeWindow。 DOMに定期的にアクセスできます。 documentは、unsafeWindow.documentと言う必要はなく、通常のページドキュメントを返します。もちろん、DOMまたはページのjsコンテキスト（unsafeWindow.foo = 'bar';など）に加えた変更はすべて検出可能です。これがunsafeである理由は、検出されたかどうかではなく、信頼できないページにこのモードの特権GM_*関数へのアクセス権を与えることができるためです（通常のモードでは許可されません）。関数の@grant GM_*はjsコンテキストを分離し、@grant unsafeWindowでない限り、ページのjsコンテキストにアクセスできなくなります）
秒
スクリプトはどのようにページに挿入されますか？ Webページがuserscriptの挿入に気付く可能性はありますか（userscriptがページ上のNOTHINGを変更すると仮定）。
例、scriptタグを使用してスクリプトが挿入された場合、ページがスクリプトの挿入に気付く可能性があると思います。コードを確認することもできますか？
サンドボックスモデルは、これが発生する方法に何らかの役割を果たし、表示されないように「安全」にしますか？たとえば、@grant unsafeWindowを使用してjsコンテキストが分離されている場合、おそらくWebページのjsはユーザースクリプトの読み込みイベントさえも認識できず、@grant unsafeWindowを根本的に安全にし、DOMまたはunsafeWindowを変更しない限り、コース。
また、特別な関数、オブジェクト、プロパティなど（tampermonkeyの存在を裏切るWebページへのGM_infoなど）のリークはないと想定しています。 @grant noneモードでも@grant unsafeWindowモードでも（ページに何もリークしていなければ）
これにより、unsafeWindowは検出されないという点で実際に安全であると感じられます（jsコンテキストが分離されているため）、何も変更しない限り（特に特権付きGM_*関数を公開しないでください） unsafeWindow）。 例、@grant noneモードでeventListenerを使用した場合、検出される可能性がありますが、@grant unsafeWindowモードで使用した場合、分離が原因で検出されない可能性がありますか？さらに、ページがユーザースクリプトの読み込みを検出できた場合（これが実際に可能かどうかはわかりません）、jsコンテキストが分離されているかどうかはわかりません。
簡単な要約で、裏切らない場合、ページはユーザースクリプトまたはタンパーモンキーの存在を検出できますか？
上記の私の考えのいずれかが、どの領域でも正しくない場合、その場合、実際にはどのように機能しますか？
更新
説明のための少しの情報：
ユーザースクリプトはページから受動的に情報を読み取るだけです（おそらくMutationObserverを使用します）。それは何も変更せず、jsライブラリを使用しません（ユーザースクリプトからもWebページからも）、ajax呼び出し、スクリプトノード、絶対にクリックなどはありません。スクリプトは、JS変数からいくつかの情報を読み取ることができます。ページ（これらの変数や関数がブービートラップされていないことを前提とします）、およびWebSocket（内部サービス）を使用します。 IIFEも使用します。したがって、質問は主に、tampermonkey それ自体（およびページスクリプトを実行する場合）は検出可能ですか？
この回答では： https://stackoverflow.com/a/8548311 1、4、5、6、および7を除外できます。おそらく2と3も同様ですが、tampermonkey自体がこれらのいずれかに影響を与えるかどうかはわかりません
ブラウザーとGreasemonkey/Tampermonkey/Violentmonkeyは、（主に）インジェクション、スコーピング、サンドボックス化の方法を改善しました。ユーザースクリプトは、通常の<script>タグを使用して挿入されません（ただし、スクリプトがこのようなタグを作成する必要がある場合もあります）。
実際、最近では IIFEを使用する必要はほとんどありません 。
しかし、 以前にリンクされた質問 の検出方法に加えて：
@grant noneモードでは、-@requireライブラリを自分自身をwindowscopeにコピーするライブラリであれば、ページはそれを見ることができます。ほとんどのライブラリはそれを行いませんが、行うのはjQueryです。- Tampermonkeyは実際にインストールされたスクリプトバージョンを提供します 詳細設定でホワイトリストに登録されているサイトに。これは主にgreasyfork.orgのようなスクリプトホスト用です。
- ユーザースクリプトが使用しているWebSocketをページが検出できるかどうかはわかりません。疑わしい。
結論は"読み取り専用"ユーザースクリプトの場合であり、require@grant noneモードのグローバルライブラリではありませんページはそれを検出できません。 =
（ページがgreasyfork.orgなどであり、Allow communication with cooperate pages設定がデフォルト値である場合を除きます。）
ページが can して「パッシブ」スクリプトを検出できるというリークを発見した場合は、私たちに知らせてください。
回答で述べたように https://stackoverflow.com/a/8548311 好きなことをするとそれは間違いなく検出可能です。しかし、tampermonkeyスクリプトで何をしたいかによって、検出がより簡単になったり困難になったりし、場合によっては不可能 。
あなたが求めていることから、あなたが作りたいことは、単にページからIIFEを呼び出して、そこで停止するだけであるように思われます、「それは単に情報を読み取るとしましょう」。
これはキャプチャするのが本当に難しいので、通常、このページでは、プロファイラーや他のユーザーの実行時間などをあなたや他のファンキーなものと比較する必要があり、ユーザーが実行したかどうかを確認する簡単な方法はありません（IIFEを使用している限り）NO SIDE EFFECTが含まれているページ内の追加のJS 100％検出できないと言っているわけではありませんが、実際には非常にトリッキーだとしましょう。
DOMを変更する場合は、外部または内部サービスへのAPI呼び出し、ユーザーの偽の動き、またはこの種の他のもの検出されます。したがって、ページで何をしたいかによって異なりますが、「簡単に」検出できます。
要約すると、裏切らない場合、ページはユーザースクリプトまたはタンパーモンキーの存在を検出できますか？
はい（上記で定義したように）ページにトレースを残した場合、ページはこれらを検出できます。これが発生するのは、ページがそれが発生しているかどうかを知りたい理由がある場合のみであることを覚えておいてください。また、この目的のためだけにこのようなものを実装するページはないので、通常のページがこれについて文句を言うことを期待しないでください。