【参加してきた】次世代Webカンファレンス
先週開催された次世代Webカンファレンスに参加してきました。
各セッション資料は用意されておらず、各分野の有識者によるディスカッション形式で話が進みました。
セッションの構成は下記になります。
- アクセシビリティ
- パフォーマンス
- WebXR(*)
- セキュリティ(*)
- 広告
- 認証
- マイクロサービス
- SRE
- HTTP3(*)
- フロントエンド
- HTTPS(*)
- CSS
- Webミュージック
- デザイン
*付のセッションに参加
このところはRubyによるオブジェクト指向/デザインパターン、JavaScript、Gitの基礎的なところを勉強しているので、今回は視野を広げるべく普段あまりインプットしないジャンルのセッションに参加しました。 (動画が公開されているため、全て観られるのですが)
基本的にはなるほど知らなかった、というトピックが多く検索しつつ箇条書きしたメモになります。
メモ
セキュリティ
今度から徳丸本の輪読会を始めるし、生徳丸先生もいらっしゃるのでちょっとしたミーハー感もありつつ選びました笑
Webアプリの開発者はセキュリティについてどの程度気にするべきか?
- あまり気にしなくていいのでは?(気にしたいけど)
- ブラウザ側の問題なのにアプリ側で対応する、というのはいけてない。
- Flashだとクロスドメインなのにjsonが送れる問題(徳丸本に書いてあるとのこと)
- 正しく理解せずに「いいから黙ってつけとけ」に従っていると、機能が動かない時などよくわからず外してしまったりするので危険
クッキーの上書きに対して
- __hostのクッキーで対応できる。
- githubのクッキーでも採用されている。
- これをman in the middleで設定していないと、httpsに対応していても、クッキー上書きにより他人がログインできてしまう。
- プリロードでの対応策もある?
ダブルサブミットクッキーはダメ?
- fuelPHPやDjangoでデフォルトで入っていたらしい。
- OWASP
クッキーの使用では;のみ区切り文字だが、
- パーサーにより:も対応しており、
- それによるニッチなバグがあったりする。
CSPについて
GDPRの影響
- クッキーをセットするのに同意を求めるやつ
- 今形骸化してしまっているのですごく良くない。
- 昔話) IEのP3Pポリシー
個人情報の収集について
- google検索でリファラーが送られていたり(今はやめたらしい)、マーケティング目的でユーザーの動作を収集していたりするが、これは業界的にはなし崩し的に常識となっているが、知識のない一般ユーザーはそういうことを認識していなかったりする。
- そのうち「このサイトではJavaScriptが使われています」と出さないといけなくなるのでは? →ディストピア感。。
ハードウェアだとPL法によりセキュリティバグを公表しなければならないが、ソフトウェアはそうでなく公表されないケースが多い。
man in the middleプロキシ
- 中間者攻撃 - Wikipedia
- 作って学ぶ 「Https Man in The Middle Proxy」 in Go - ( ꒪⌓꒪) ゆるよろ日記
- バーク(綴りわからん)
- http2、grcpに対応してない
Webアプリケーションエンジニアに対するお気持ち表明
- 徳丸さん「何でもかんでもコピペするのは危ない」
- 検索して一発目に出てくるコードがイケてないことが良くある。
- bulkneetsさん「開発者みんながセキュリティに対する当事者意識を持ってほしい」
- 全ては分かってなくても良いが、取っ掛かりでそこに気づいてほしい。気づいてくれれば、あとは相談してもらえれば良い。
- k2wankoさん「開発者のみなさんにもセキュリティについてもっと興味を持ってもらえると嬉しい」
- リクルートだと開発者とセキュリティのジョブローテがあるらしい。
- 徳丸さん「何でもかんでもコピペするのは危ない」
WebXR
XR: AR/VR/MRを合体させたもの
WebXRは来ると思うか?
- モバイルデバイスから来ると思っている。ARが来る。
- その中でWebで有用性があると思うのは、ショッピングサイトの商品を自分の部屋に置いてみる体験をしてもらう。
- 例えば教育。博物館などにあるようなものを実際に部屋に置いてみる。
- また地図。自分が行きたい方向へ矢印を表示する
Webの良さはインストールがいらないところ
ARクラウドという情報インフラが出て来るのでは?と各社興味を持っている。
WebGLは来る?
- ハイエンドのゲームから、一般ユーザー向けの簡単な動きを作るところまで。
- ブラウザからGPUの力を使うためにWebGLを使う。
- CG界隈は堅苦しい?WebGL界隈にはその雰囲気は持ち込みたくないと思っているが、、
- WebGL:ゲームのようなハイエンドから、サイト上での簡単な動気をつける、GPUを使うためなど、色々な使い方がある
- 3Dは必要になるし、学んで置いた方が良いのでは?
- 今の時点では3Dの表現をできるのはWebGL一択
- WebGPU、Web用のシェーダー言語、などWebGLに変わる新しい仕様が出るかもしれないが、今のところはWebGL一強
Web開発者目線でのARとの付き合い方
- Khronosという団体がWebGLをサポートしている。
テレビはしばらくなくならなさそう
- WebとつながることによりXRへつながっていく。
今時はリンクをシェアしない。画面をキャプチャしてシェアする。
- URLをわからず使っている。
- ARと知らずにARを使う世の中になるのでは。
play canvas
- 導入 | Learn PlayCanvas
- インストールしなくて使える、はかなり使いやすい体験
ARはWebがいいと思うが、VRはWebでなくてもいいのでは
- VRとARの違いはCGの濃度の違い
- 現時点のARとVRは融合する手前の状態
- nreal light
いつ来るのか?
- 今は仕様策定の最中
- WebVRはすでにChrome LTSに載っている。ARはまだ載っていない。
- ポジトラ:ポジショントラッキング
- KhronosはOpenXRをやろうとしている。
- 今乱立されているのを、標準化したいお気持ち。
- OpenXR Overview - The Khronos Group Inc
- 2020年に5Gが来るので、その頃には来るのでは?
- モバイルよりはSSRしたものを送ってしまった方がいい説
- 3Dに触れておくとか、3Dに数学が必要なんだな、ということを今のうちに知っておくのが良さそう。
CSSシェーダーなくなってしまったのが残念。。
- WebGL村はCG国とWeb国の派閥の間にいる
- WebGLは色々自分でやらないといけない。結構難しいのは知って置いた方が良い。
- だが、手軽な方向に行って欲しい。
- シェーダー
- ジオメトリ
- google poly
今のうちに低レイヤーの仕様をきちんと策定しておきたい。
WebXRは機械学習と相性が良さそう
HTTPS
2018振り返り
- Symantecの事件
- PKIベンダー苦難の年
- ワールドワイドでシェア3割だったのに、一瞬でディストラストされてしまった。
- Symantecはブラウザの信用を外されてしまった。
- Chromeで信頼されなくなるSymantec発行のSSL証明書かどうか判定・確認する方法:Tech TIPS - @IT
- Symantecの事件
- 今理解しておくべきトラスト〜Web PKIのサーバ証明書事情〜
- CT (Certificate Transparency) 証明書の発行ログを見られるようにすることで、みんなで変な証明書が発行されていないかを監視したいというモチベでやっている。
CAの重要性が上がっているが、使えるルート認証局が減少する問題
- 大手 (Symantec) でも信用できないとなると、結局どこを選べば良いのか?
- ルート認証局の数自体は減っておらずむしろ増えている。ルート自体は増えている
- lets encryptのようなDV証明書が主流になっている。EV証明書は無くなる方向
- Let’s EncryptがVerisignと棲み分けできる理由: SSL証明書の「DV、OV、EV」とは何か
- 今さら聞けないSSL証明書とは、DV、OV、EVとは、常時SSLについて | レンタルサーバーのCPIスタッフブログ
TLSは認証はしているが、信頼はしていない
- DV証明書は認証はするが、信頼はしていない
- EV証明書は、信頼をちょっと上乗せしている
- EV証明書は去年インシデントがあった。
- イギリス:identity verified
- アメリカ:stripe
- 違う州で違う会社が同じ名前で証明書をとったケース
- EV証明書を使用して既知の企業になりすませる可能性が指摘される | スラド セキュリティ
- EV証明書は去年インシデントがあった。
EV証明書は信頼されなくなったこれには2つの理由がある。
— Yosuke FURUKAWA (@yosuke_furukawa) January 13, 2019
- Identity Verified という証明書が出た、これを悪用するケースがiOSであった。
- 別の組織の人がお金さえ払えばEV証明書を作れてしまう事例があり、これによりお金さえ払えばフィッシングサイト作れるという事例ができてしまった#nwc_https
(自分がよくわかっていないところ、大体古川さんの要約ツイートがされてて助かりました)
EVも信頼を失いつつある今、CAは何を売るのか?
HTTPSだけで安全を保証できないなら、「安全に安全を保証するにはどうすれば良いか?」
TLS1.3
- RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
- TLS1.2との後方互換性を大切にしているため、それほど変わっていない?なぜか?
TLS1.3印象:
— Yosuke FURUKAWA (@yosuke_furukawa) January 13, 2019
- 今までボロボロの長屋をダンボールで補強してたのをプロトコルごと変えたのは良い
- ただし、あんまりドラスティックに変わってない
- ドラスティックに変わってない理由の反面教師はIPv6
- 後方互換性をなくすと絶対変更について来れない#nwc_https
- MLS: Message Layer Security
SSL pulse
TLS1.0と1.1を消すのはどのくらい大変なのか?
TLS1.3以降で必要になって来るものは?
- TLSの量子コンピュータへの対応も必ず必要になって来る
- 量子コンピュータがデプロイされる前に準備されておかなければならない。
量子コンピュータは周期性があるものに対する計算が強い
- 鍵交換では素数を使っているのでなんとかしないといけない(素数には周期性がある)
- ハッシュ値を使っているものは、桁数を上げれば対応できるはず。
LTSという土管を通る前後の安全性をどう扱うか?
- LTSの上位レイヤーの話
SXG
コンテンツに対して証明できるようにしたい。
AMP: Accelarated Mobile Pages
URLで識別するには、もう限界がきている。
- TLSの量子コンピュータへの対応も必ず必要になって来る
HTTP3
- HTTPなのにTCPじゃないの?
- なぜHTTP3と名乗っているの?
- 低レイヤー側は変えているが、インターフェイス的にはセマンティクスは変わっていないからいいんじゃない?的に思っている。
- 詳解 HTTP/3
- 元々の課題感
- Googleが作るQUICとIETFが作るQUICが混乱を招きそう
- ブラウザがログを吐くときにバージョニングする方が便利
- QUICは意外と広まっている (5-10%)
- キャリアグレードNAT
- Firewallが想定している挙動とQUICやTLS1.3の挙動が一致していないため通らない問題
- バージョンごとに通ったり通らなかったりする問題。。
QUICとロードバランサーの両立はどうすれば良いか?
- 対応策
- connection idはipが変わったら変更する。
- connection idを外側からは暗号化する
- 対応策
ロードバランサーがQUICに対応しないといけない?
0RTT
LRU
BBR 輻輳制御アルゴリズム
Wifiと公衆回線の切り替え時に、通信が途切れる問題が解決されるのでHTTP3 (QUIC) 使って欲しいとのこと。
new reno cubic
WebRTC over QUIC
Webのこれから
まとめ
話題も多岐にわたりいろいろと消化しきれていないのですが、各分野で前線を貼っている人たちが何を気にして戦っているのかを知れたのは良かったかなと思います。
あと「そもそも普段自分が触っている技術の最前線を抑えられているか?」と自分に問い直してみると、 「ニュースとして流し見はしているが理解度は高くない」ということが多いのでまずはそこから対応した方が良いよね、というお気持ちです。