Firefoxは危険なJavaScriptに対応しない

Firefox / [Safari](https://qiita.com/rana_kualu/items/2e610c78aa8887ca62bb)

Mozillaは[Mozilla Specification Positions](https://mozilla.github.io/standards-positions/)というリストを公開しています。

IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。
あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。


# Mozilla's Positions

Mozillaはどのように評価しているかの分類。

## under consideration

評価の検討中。

## important

優れた概念であり、Mozillaにとっても重要である。

## worth prototyping

優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。

## non-harmful

有害ではないが、良いアプローチではなく、取り組む価値があるとは考えていない。

## defer

近い将来にこの仕様を導入するつもりはない。

## harmful

有害である。


たとえば[Chromeの右クリックに実装された](https://qiita.com/rana_kualu/items/1f3f2474550392064e78)[選択箇所へのリンクのコピー](https://github.com/WICG/scroll-to-text-fragment)や、Chromeがユーザエージェントの代替を目指している[HTTP Client Hints](https://qiita.com/nightyknite/items/257251b9692dff1b62be)などをFirefoxは`non-harmful`あまり良くないと評価していて、温度感の差がわかります。


# harmful

ここではharmful、すなわちFirefoxが『これは有害である』と評価している技術を紹介してみます。
これらのAPIは、現在の仕様のままでFirefoxに実装される可能性はほぼ無いということです。
そしてFirefoxにすら実装されないということは、SafariやVivaldiやBraveといった他のブラウザには余計に実装されないということです。

一部JavaScriptではないものもありますが、まあ細かいことは気にするな。


## [File System Access](https://wicg.github.io/file-system-access/)

ローカルファイルに自由にアクセス可能にする機能です。

指定ディレクトリ以下の全ファイル読み込み、およびファイルへの上書き保存などができてしまいます。
こんなものパーミッションがあろうがなかろうが絶対に許可すべきではありません。

### Mozilla's Position

localStorageへのアクセス手段提供など、部分的には気に入っている機能もある。
ただしローカルファイルシステムへのアクセスなど危険なものと一緒くたになっているため、全体としては有害である。


## [First-Party Sets](https://github.com/privacycg/first-party-sets)

`google.com`と`youtube.com`を[同じドメインだと見做す](https://qiita.com/rana_kualu/items/13a77f76257767a23643)機能です。

これをユーザ側で好きに設定できるとかいう代物なので、実装されたら即トラッキングに使われるのは明らかです。
またユーザにとってもどことどこが繋がっているのか極めて分かりにくいということで、[Mozillaは明確に反対を表明しています](https://github.com/privacycg/proposals/issues/17)。

### Mozilla's Position

ファーストパーティの定義は、ユーザ、Web開発者、パブリッシャーにとってわかりやすいものでならねばならない。
従って、理想的にはトップレベルのURLのみに基づいて定義されるべきである。
現在はそのようになっていないが、だからといって例外を標準化すべきではなく、理想を実現する方向に持っていくべきである。


## [Generic Sensor API](https://w3c.github.io/sensors/)

様々な種類のセンサに対して、統一的な方法でアクセス可能にするAPIです。

何のセンサが繋がるかわからないなんてものに責任なんて持てるはずもなく、またそこまでして対応する価値もないということで[拒否されました](https://github.com/mozilla/standards-positions/issues/35)。

### Mozilla's Position

多種多様なセンサについて、それぞれにアクセスする目的とリスクを適切にユーザに伝えることは非常に難しい。
Webサイトがセンサを必要とするユースケースにはたしかに興味があるが、しかしWebサイトがセンサに直結することは、セキュリティやプライバシーの問題になるため、それは許可できない。


## [Geolocation Sensor](https://w3c.github.io/geolocation-sensor/)

Geolocation APIの機能拡張です。

ほとんどの機能はGeolocation APIでも同じことが可能ですが、新たにバックグラウンドでも動作できるようになります。

### Mozilla's Position

RFCは『プライバシーとセキュリティを両立できる』と主張しているが、実際はそうでもない。
既にほとんど同じ機能のGeolocation APIが存在するのにわざわざ似たような別のAPIを作ると、メンテナンスの労力も倍になる。
多くをGeolocation APIでpolyfillできるのならば、そちらを機能拡張したほうがいい。


## [Get Installed Related Apps API](https://wicg.github.io/get-installed-related-apps/spec/)

ネイティブアプリが端末にインストールされているかを検出できるようにするAPIです。

ネイティブアプリが入っていればそっちを動かし、なかったらWebアプリを動かすみたいなことを考えているみたいです。

### Mozilla's Position

十分な保護機能を講じない限り、ブラウザフィンガープリントの危険が増えるだけである。


## [HTML Imports](https://www.w3.org/TR/2016/WD-html-imports-20160225)

`<link rel="import">`でHTMLをインポートする機能です。

唯一対応していたChromeすら[非対応に戻した](https://caniuse.com/?search=HTML%20Imports)ため、今後日の目を見ることは無いでしょう。

### Mozilla's Position

この分野はJavaScriptのほうが向いていると考えており、HTML Modulesを支持している。


## [Keyboard Map](https://wicg.github.io/keyboard-map/)

キーボードの入力は`KeyboardEvent`で取得できますが、これはロケールやレイアウト、シフト押下などの状態を無視します。
たとえばキーボードをdvorakレイアウトで使っていたとしても、印字が`s`のボタンを押したときに発生するイベントは`s`であり、`o`ではありません。

これをユーザが想定しているであろう`o`で取れるようにしよう、という提案です。

むしろ`getLayoutMap()`で全てのキーボードマップを回収できます。

### Mozilla's Position

ブラウザフィンガープリントの情報源を増やすだけであり、ユーザの意志に関係なく取得できることも問題である。


## [Low-level (Raw) Sockets API](https://github.com/WICG/raw-sockets/blob/main/docs/explainer.md)

他のホストとソケット通信を行うことができます。

通常のHTTPS等では飽き足らず、独自プロトコルで超リアルタイム通信を行いたいなどといった高度な使用法を目的とした低レベルAPIです。


### Mozilla's Position

これまでに開発されてきた同一生成元ポリシーなどの保護機能を回避することが可能であり、ドキュメントに記載されている保護機能では対策として不十分である。
ユーザの同意に頼ることは、安全策ではない。


## [Media Feeds](https://wicg.github.io/media-feeds/)

パーソナライズされた広告を表示する機能です。

ということみたいなのですが、どうも○○は××しなければならないという定義ばかり並んでいて、では具体的になんなんだよってのがいまいちよくわかりませんでした。
誰か解説よろ。

### Mozilla's Position

Media Feedsは、有害な機能を有害な技術で増幅させる有害な存在である。
このAPIで実現される機能の多くは既に他の方法で実現されている。
まだ[Media Session API](https://w3c.github.io/mediasession/)を拡張する方がいいだろう。


## [Network Information API](https://wicg.github.io/netinfo/)

現在接続しているネットワークの種類などを取得できます。
これによって、低速回線であれば小さい画像を、高速回線なら高精細な画像を表示する、といった出し分けが可能になります。
さらに4GからWiFiに変わったなどのイベントを`onchange`で感知することができるようになります。

ネットワークの変更をウォッチすることで、外出した帰宅したなどの行動パターンを読み取られる可能性があります。
また、たとえば[4Gだとわかったところで実際の品質は千差万別なのだから意味がない](https://github.com/mozilla/standards-positions/issues/117#issuecomment-613777978)わけで、それならば実際の速度を測定した方がまだよいでしょう。

### Mozilla's Position

回線種別ではなく帯域幅を使った方が、より正確な対応ができる。


## [Periodic Background Synchronization](https://github.com/WICG/background-sync/blob/main/explainers/periodicsync-explainer.md)

定期的なバックグラウンド同期を可能にします。
ニュースを最新のものに更新したり、お気に入りアーティストの新曲を配信したり、緊急のセキュリティアップデートを実行したりが可能になります。
これまでServiceWorkerやWeb Pushを使って行っていたことを、よりスマートに行えるようになるわけです。

そしてこのAPI、ブラウザを閉じていても動きます。

はぁ？

### Mozilla's Position

位置情報やIPアドレスを定期的に取得することで、ユーザの追跡が可能になる。
ユーザに気付かれずにスクリプトを動作させ、リソースを消費させてしまう。
単発のバックグラウンド同期ですらこれらの懸念の解消が難しいのに、定期的なバックグラウンド同期となれば猶更だろう。


## [Raw Clipboard Access](https://github.com/WICG/raw-clipboard-access/)

OSのクリップボードを介して、ネイティブアプリとWebアプリでデータをコピペ可能にする提案です。
現在のクリップボードでもある程度は可能ですが、tiffやdocsのような独自フォーマットには未対応で、あまり細かな制御が効きません。
そこでクリップボードと直接生データをやりとりすることを可能にする低レベルAPIを提供します。

### Mozilla's Position

現在の提案には、ネイティブアプリに攻撃可能という致命的なリスクがある。
この問題が解決されるまで、再評価されることはない。


## [Restricting Document Access of Same Origin Documents](https://github.com/dtapuska/documentaccess)

埋め込みドキュメントのエージェントやイベントループを、それぞれ個別のものにする提案。

正直ちょっとよくわからなかったんだけど、iframeで読み込んだドキュメントは親子間や子子間で操作可能ですが、それらをどの程度操作可能かを制御するみたいな話でいいんですかね。
`allow-same-origin`ほど緩くもないが、クロスオリジンほどきつくもない制限`disallowdocumentaccess`を導入する？

### Mozilla's Position

クロスオリジンのドキュメントの制御フローを同意なしに変更することは攻撃手段を増やすことであり、拡張すべきではない。
同一オリジンの場合は、アーキテクチャの大改造を行ってまで実装するほどの利点がない。


## [Serial API](https://wicg.github.io/serial)

ブラウザがシリアルポートを読み書き可能にします。

この時点で論外すぎる。

### Mozilla's Position

シリアルデバイスは、強力なローレベル機能を、ほとんどもしくは全く認証なしに公開していることがよくある。
それらを適切な保護なしにWebに公開することは、脅威以外の何物でもない。


## [Signed HTTP Exchanges](https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses)

[この図](https://developers.google.com/web/updates/2018/11/signed-exchanges)を見れば一発です。

![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26088/8baaea5c-da2a-ad1c-55a3-685c0d9d2b21.png)

つまりどういうことかというと、URL欄に`https://a.com`と入力してアクセスできて正しい鍵マークも表示されているのに、実際は`https://b.com`にアクセスしているとかいう代物です。
URLというモデルの崩壊です。

元々Googleがごり押ししていたAMPのページが常にURLが`https://google.com/amp/xxx`となって醜いからどうにかしようと[捻り出した仕様](https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages/)なわけで、こんなものに他のブラウザが追随する義務なんてこれっぽっちもありませんね。

### Mozilla's Position

クライアントが権威サーバに問い合わせることなく、別のオリジンが他のオリジンを代行できること、Webセキュリティモデルから機密性の保証が消えることなど、Webセキュリティモデルの変化に問題がある。


## [Unicode Emoji QID](https://www.unicode.org/review/pri408/pri408-tr51-QID.html)

UNICODEの文字は、[ユニコードコンソーシアム](https://home.unicode.org/)が管理しています。
で、何かの絵文字を追加したいって思ったときに申請するプロセスは[こんな](https://unicode.org/emoji/proposals.html)です。
とてもつらい。

そこで[Wikimedia](https://www.wikidata.org/wiki/Wikidata:Main_Page)のQIDで絵文字として使えるようにしようという提案。
たとえば今のところ存在しない[NATOの旗](https://www.wikidata.org/wiki/Q459788)などを追加したいと思ったときに、ユニコードコンソーシアムの手を煩わせずすぐに新たな絵文字を使えるようになります。

まあ利点より弊害の方が大きすぎますね。
それに万一実装されてしまったとして[これ](https://www.wikidata.org/wiki/Q11284655)どうすんですかね。

### Mozilla's Position

絵文字に対応するグリフが無いためユーザ間のミスコミュニケーションが増える懸念がある。
バージョン承認プロセスがなくなるため、実装者間の同期がとれなくなる。
QIDシステムを悪用し、UNICODE承認プロセスを回避して絵文字ではない何かを追加される恐れがある。


## [Web Background Synchronization](https://wicg.github.io/background-sync/spec/)

Periodic Background Synchronizationと何がちがうんだ？

ちなみにRFCには`Background sync SHOULD be enabled by default.`とか書かれてる。ふざけんな。

### Mozilla's Position

位置情報やIPアドレスを定期的に取得することで、ユーザの追跡が可能になる。
ユーザに気付かれずにスクリプトを動作させ、リソースを消費させてしまう。


## [Web Bluetooth](https://webbluetoothcg.github.io/web-bluetooth/)

ブラウザからBluetoothデバイスを検出し、通信するAPIです。

言うまでもなく論外です。

### Mozilla's Position

WebUSB同様、機器の状態について大きな不確実性がある。
ユーザの同意のみに頼ることは正しい保護ではない。
またRFCでは悪意のあるデバイスへの対策としてブロックリストを使うことになっているが、常にメンテナンスが必要であり、持続可能なモデルではなく、ユーザとデバイスに大きなリスクをもたらす。


## [Web NFC](https://w3c.github.io/web-nfc/)

近距離無線通信、要するにSuicaとかマイナンバーカードを読み書きできるようにするAPIです。
e-TAXのWeb版がIEでしか使えなかった原因ですね。

### Mozilla's Position

既存のNFCデバイスは機能が非常に多いため、ユーザのセキュリティやプライバシーにリスクがある。
ユーザの同意以外に、個人情報の流出を防ぐシステムが存在しない。
何を読み込み、何を書き込むのかをユーザに明示できないのにユーザへの同意を取るわけにはいかない。


## [WebRTC Next Version Use Cases: Trusted JavaScript](https://github.com/w3c/webrtc-nv-use-cases/pull/49/files)

[WebRTCの機能拡張](https://w3c.github.io/webrtc-nv-use-cases/)の一部、`Untrusted JavaScript Cloud Conferencing`の項目です。
`サーバは信頼できないけどJavaScriptは信頼できる`という状態で、ビデオ会議の内容にはアクセスできないが会議のメンバーにはアクセスできるみたいなユースケースらしいです。

いまいちどんな状態なのか全然わかりませんが、Mozillaとしては[そんな状態でJSにアクセス権渡すとかねーわ](https://github.com/mozilla/standards-positions/issues/205#issuecomment-610712986)だそうです。

### Mozilla's Position

`Untrusted JS`の案は、ユーザにビデオ会議のセキュリティの保証を提供できる。
しかし`Trusted JS`のバリアントではセキュリティが保証されず、無駄に複雑さが増すだけである。


## [WebUSB API](https://wicg.github.io/webusb/)

ブラウザからUSBデバイスへアクセスするAPIです。

こちらも論外です。

### Mozilla's Position

多くのUSBデバイスは、USBプロトコルを介した悪意のあるメッセージを適切に処理できるように設計されていない。
USBデバイスをWeb上に公開するリスクはあまりにも広範であり、ユーザに対してリスクを適切に説明することはできない。
WebサイトがUSBデバイス内のデータや一意のキーをトラッキングに使う懸念も存在する。


## [passwordrules attribute](https://github.com/whatwg/html/issues/3518)

`input`タグに`passwordrules`属性を追加し、パスワードの制限を任意に指定できるようにする提案です。

```html
<input type="password" minlength="8" passwordrules="required: upper; required: lower; required: digit, [-().&@?'#,/&quot;+]; max-consecutive: 2">
```

8文字以上、`大文字`・`小文字`・`数値か記号`の3種類が必須、同じ文字を2文字以上連続すること禁止、の場合はこんな書式になります。
ややこしい。

ただ、役には立たないけどharmfulとまでは個人的には思わないかな。

### Mozilla's Position

このAPIは、パスワードに関するバッドプラクティスを奨励するものであり、しかも既存の属性と矛盾するところがある。
パスワード要件を満たすためには、既存の属性とAPIで十分である。


# 感想

あの手この手でユーザデータを吸い上げたいGoogleと、それに抵抗するMozillaの図、というふうに見えてしまいますね。
実際harmfulの8割がたはGoogleの手によるものです。

ちなみにSafariが[有害であると評している技術](https://qiita.com/rana_kualu/items/2e610c78aa8887ca62bb)16種類のうち、Firefoxのリストに並んでいるのは8種類と半分です。
意外と少ない、と思いきやMozillaは[Firefoxも全て対応しないよ](https://twitter.com/marcosc/status/1277737614687170560)と発言していて、実際全てに未対応です。
元々Firefoxに実装されていた[Battery Status API](https://caniuse.com/?search=Battery%20Status)・[Proximity API](https://caniuse.com/?search=Proximity)・[Ambient light sensor API](https://caniuse.com/?search=Ambient%20light%20sensor)に至っては、わざわざ[非対応に戻されました](https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html)。
リストには表記してないけど実際はharmfulだと考えている技術もまだまだ存在するということですね。



## 同意は免罪符ではない

同意していようが公に同意の誓約書を書いていようが殺人は犯罪です。

それなのに何故かWeb APIにおいては、同意さえ取れば何をやってもいいと考える人が多い不思議。

その点Mozillaは、`Relying on user consent is not a sufficient safeguard`『ユーザの同意に頼ることは十分な安全策ではない』と主張していて、どちらが正しいかなんて明白ですね。
そもそも[警告なんて誰も読んでない](https://security.srad.jp/story/16/08/22/1055212/)ので、ちゃちなポップアップが契約として有効かどうかすら怪しいものです。