Last active
May 13, 2022 13:05
-
-
Save pastak/9f1cc2933dc4c348c57c21025887b843 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
私は、京都で会社員としてウェブアプリケーションの開発者をしています。主にウェブブラウザ上で動作するJavaScriptを用いたフロントエンドと呼ばれる領域を扱っていて、ウェブブラウザの動向などには関心があるという立場です。また、PWAとSafariや各ブラウザについてのオンライン勉強会での講演なども行ったことがあります。 | |
https://scrapbox.io/pastak-pub/面白Web_API_100連発#5f3cf9af8ee91d0000d983f8 | |
https://scrapbox.io/pastak-pub/GyazoでのPWA%2FWebAPIとの向き合い方#6008049b8ee91d000059cc3a | |
報告書内には言及がなかったかと思いますが、AppleのWebKitとChrome(Blink)のバグ修正の取り組み方のオープン性の違いという観点ついて意見を書かせていただきます。 | |
Chromeのバグ報告トラッカー https://bugs.chromium.org/p/chromium/issues/list ではセキュリティなどに関わるもので無い限りはほぼ全てが公開されており、議論に参加したり、修正の進捗を常に確認することが出来ます。これはMoziilaが提供しているFirefoxのバグ報告トラッカー https://bugzilla.mozilla.org でも同様です。しかし、Webkitが提供しているバグ報告トラッカー https://bugs.webkit.org/ ではバグ報告を提出しても、なかなかハンドリングされなかったり、ハンドリングされても様子はrdarから始まる恐らくAppleの社内システムと思われるものへのリンクとなり議論や修正の様子を確認することが出来ない。その結果、長らく放置されてそのまま対応されないままになることが多々ある。PWAなどについての対応に企業としての思惑があることはある程度許容することは仕方ないと私は考えますが、一方でWebkitはそれらに関する意見や議論をオープンに他のブラウザ同様にバグ報告トラッカーを利用して行うべきであると考えます。この点についてもなんらかの言及をすることについてご検討いただければと思います。 | |
第1-4. 【有力ウェブ・サービス等を梃子とした他のレイヤー等における競争優位性獲得】 15. 有力ウェブ・サービスにおける仕様変更等によるブラウザへの影響(Google) について | |
参照されている意見について、ほぼ同意はするものの、ややGoogle批判一辺倒な意見が並びすぎていてアンフェアなのではないか、結論ありきの意見が並んでいるのではないかと感じました。関連した「オプションA」については現在ウェブブラウザの開発者としてのGoogleとウェブサイトの開発者としてのGoogleが同一であることを短絡的に同一視しすぎではないかと感じています。彼らはChromiumのCanary buildを提供したり、Origin Trialという仕組みで特定の機能を試せるようにしたり、前述のバグ報告トラッカーなどで実際のウェブサイトでの困りごとはないかなどを収集して、WHATWGでの仕様提案へのフィードバックを行っているという現実もあります。逆にAppleは実際に彼らのウェブサイトでは一部を覗いてそもそもそのようなウェブの仕組みを活用したものを提供しておらず現実の実例を同様に彼らが集めて提案できるかというと難しい現実もあるかと思います。そのような現実の例をGoogleが自身で提供して、仕様の提案などを行うことは、中間報告書で述べられているようなデファクトスタンダードへの圧力にもなっている反面で、他の開発者やベンダーに対して実際の活用事例を提示する役割もあり、そういった力を削ぐものになるのは、それこそウェブの前進を止めることになるかと懸念します。また、これは非常に個人的な意見ではありますが、Google社内のChromeの開発者や関連の仕事をしている人たちと接すると、この報告書で上げられた巨大なGoogleという企業としての思惑や見え方の印象よりも、もう少しWebに対して真面目に素直に接していると感じます(日本人にもそういった仕事をされている方がGoogle、Apple、Moziilaともに居るかと思いますが、ご意見等は聞かれているのでしょうか)。 | |
「第1-3. 【ブラウザ、ウェブ・アプリとネイティブ・アプリ】 11. WebKit の利用義務付けとブラウザにおけるウェブ・アプリに対する消極的な対応(Apple)について | |
WebkitがPWAなどの追随をしないことでAppStoreで提供されるネイティブアプリの優位性を保とうとしていることなどについては同意します。実際、私も同様の問題を回避するための取り組みや、それによる技術選択の矮小化、体験を提供できるユーザーの限定を行ったことがあります。その上で、報告書で提示されている対応のオプションについての意見を述べたいと思います。「オプションA」についてはiOSに対してサードパーティのウェブブラウザが登場することで、Appleによる恣意的な機能の制約とそれによる市場の不利益は払拭できるということについては、その通りであろうとは考えますが、一方でこの報告書冒頭でも述べられているように現状でウェブブラウザ(エンジン)を提供できる企業・開発者は限られており、結果的にiOS上でもChromeが台頭する結果にしかならないのではないかと考えると、この報告書を起点とした政策で解決したい問題解決には結びつかないのではないかと考えます。また、多くの一般的なユーザーは結果的にデフォルトのWebkit(mobile Safari)を使うであろうことが予見され、Appleがこの競争のためにWebkitの開発において、PWAやその他の機能改善について積極的に行うことは考えづらいかと思っています。 | |
オプションBの「一定規模以上の OS を提供する事業者がブラウザを提供する場合には、ウェブ・アプリをサポートするブラウザの機能の提供に関し、他のモバイル OS 上のブラウザに提供されている機能と同等の機能を自社ブラウザでも提供することを義務付ける規律」の「他のモバイル OS 上のブラウザに提供されている機能」というのは何を指すことになるのでしょうか。これがもしChromeと足並みを揃えよという意図であるなら、それはChromeのデファクトスタンダード性を助長させるのではないでしょうか、またその逆も然りであるかと考えます。この部分についてはWHATWGやECMAScriptで仕様として提案されて、各ベンダーの代表者なども交えた議論の後に仕様策定されているのですから、具体的にそのようなもので標準化されているものを一定以上の水準でサポートするように要請するなどの表現になるべきと考えます。 | |
また、こちらも前述のGoogle同様にWebkitが全くもってウェブの新機能の開発や取り込みに否定的かというと、JavaScriptの仕様であるECMAScriptの最新仕様などでChromeで利用されているV8よりも早く取り込んでいる例もありますし、CSSでの表示サイズの扱いなどでも積極的に彼らの環境(iPhone, iPadなど)に必要なものは取り込んでいるという認識です。 | |
報告書全体を通じて、GoogleやAppleなどのベンダーを一方的に否定するような書きぶりになっていますが、彼らがそもそもウェブブラウザやエンジンを開発していなければ、WHATWGやECMAScriptなどの仕様を前に進めたり、そのウェブブラウザの上で我々が体験をユーザーに提供することが出来ないという現実もあります。それらを健全に競争させることは勿論重要ですが、彼らを不必要に押さえつけるような結果になり、ベンダーから日本が総スカンを食らうことのデメリットについても考慮されたいなというのが感想です。それぞれの相互の立場をフォローした上で、健全な競争環境に寄与する最終提言または政策提案になることを期待しています。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment