次世代 Web カンファレンス - connpassに参加してきたのでメモ。

このメモは文字起こしではなくあくまでメモなので、そのままの発言じゃなくて解釈や要約が混じっています。

詳細は動画をみてください

パフォーマンス

登壇者

記録

ローディング周り

  • 1000ch: WebKitのレンダリングの様子の動画を見たのが興味を持ったきっかけ
  • 1000ch: HTTP/2になってきてローディングの通信を気にすることは減った?
  • sisidovski: 同時接続数は気にすることは減ったけど、結局は気になる
  • likr: H2 Pushとかが気になっている?
  • 1000ch: 実際に使ったことないけど、会場で使ったことある人?
    • 2割以内ぐらい
  • sisidovski: 「Pushで早くなる」ということは今の所ダウト。統計的なデータがまだない
  • sisidovski: 最近はwebpackを使わないとパフォーマンス改善できないという方向になっているのが気になっている
  • likr: prefetch気になってる。開発者がどこまでやっていいのか。どれをprefetchすればいいのか
  • 1000ch: prefetchの一番の例がGoogle検索のAMP
  • 1000ch: 圧縮周りはどう
  • sisidovski: zipfillとか色々
  • likr: 3D周りの圧縮とか。これもGoogleが出していた
  • sisidovski: CDNの圧縮について
  • 1000ch: 事前に圧縮するかダイナミックにCDNで圧縮に頼るかどうか?
  • sisidovski: オリジンも含めて圧縮した方がコストが安い
    • 特にCSSのinlineとかのケース
    • ただCDNでの圧縮した方が漏れが少ない
  • likr: lazyロードするケースで、どこまで最初にロードさせるかどうか?
  • 1000ch: 画面表示に対する最適化ってそこまで意味ないと思ってる。結局スクロールするから
  • sisidovski: ページが長い場合は読み込み順は気にしたほうがいいかんと思っている
  • 1000ch: 画像とかは遅延ロードしておきたい

Off the main thread

  • 1000ch: JavaScriptの実行のコストが気になっている
  • sisidovski: 某新聞社は実行コストよりもローディング周りの最適化が多かった
    • requestIdleCallbackはよく使っていた
    • スケジューリングの部分もよりブラウザで面倒を見てくれるようになった
  • likr: Custom Elementを使う場合にも、最初からテキストが入った状態で配信する
    • slotにコンテンツが入った状態
  • 1000ch: SEO的に良い
    • ただ、JS評価されるまでスタイルがつかない問題があるのは気になる
  • 1000ch: レイアウトがガタッとなると困る
  • sisidovski: Web ComponentはレイアウトもJSが必要
  • 1000ch: 高性能開発機問題
  • sisidovski: Chromeでしか確認しないとそれはユーザーを代表した性能なのかどうか
    • Googleとか新興国
  • 1000ch: 開発者目線だと最低限の環境に合わせたい
    • ビジネス目線だとコスパの問題があるので実ユーザーデータが必要

モニタリング

  • likr: 点取ゲームとしてのLightHouse
  • sisidovski: LightHouse、SpeedCurve
    • RUMは一時期SpeedCurveを使ったけど高かった
    • なので自前のものにした
  • 1000ch: パフォーマンスのデータ、どういうデータをとっていた?
  • sisidovski: SpeedIndexを使ってた
    • 好きなメトリクスはありますか?
  • 1000ch: LightHouse良く出来てるけどLightHouse対策になりやすい
  • likr: パフォーマンスは職人ワザになりがちじゃないですか?
    • 誰でもパフォーマンス改善できるようになるにはどうすればいいか
  • sisidovski: LightHouseとかはまさにそれで、パフォーマンス改善の民主化に力を入れている
    • けどまだ一般には少し遠い
  • 1000ch: 改善の指標をまず知るということが大切
  • likr: 最近は昔に比べて改善の指標は見えるようになったのが違い
  • このフレームワークに載っておけば早いというやつ
    • AMPとかgasbyとか
  • 1000ch: それはReactとかだいたいのフレームワーク
  • sisidovski: AMPとかはまさにそれという感じ

WebPackaging

コンピューティング

気になるAPI

  • likr: wasmがずっと気になっている。これからも改善されていくだろう
    • Basicはだいたいのブラウザで動作する
    • ThreadはまだChromeだけど
    • Workerでwasmを動かす
  • sisidovski: Workelet、Feature Policyとかが気になってる
    • サードパーティに対する制限をかけるようになる
  • 1000ch: PerformanceObserverでframe timingとか取れる
    • speedindexとかをとっていた時に50msとかかかってしまう問題をもっと早く取れるようにしたい
    • あとはlong task
    • w3c/longtasks: Long Task API
    • この辺が改善されるとRUMのデータを取りやすくなる

HTTP/3

  • 1000ch: ラウンドトリップの問題が解決される?
  • sisidovski: CDNが早く実装して欲しい
    • 今もHTTP/2のサーバを自分で運用してるケースがすくなってきている
    • HTTP/3でもそういう傾向があるのでは

画像の圧縮

Security

登壇者

ログ

  • k2wanko: みんな(登壇者)はセキュリティ診断とか相談とかその辺をやっている

  • k2wanko: 最近のウェブの脆弱性ってどうなのがあるのか?

  • bulkneets: ざっくりとしてフリだよね

  • bulkneets: この2社でCDNの事故ケースがあった話

  • bulkneets: 0秒キャッシュで他の人のレスポンスが表示されてしまうケース

    • privateを使わないと

  • yagihashoo: 事故がきっかけで社内にセキュリティチームを作ろうという話になった

  • bulkneets: 本当に世の中で多いといえばWordpress

  • ockeghem: Wordpress、EC-CUBEとかがおおくなりがち

    • 利用者側の問題が多い
    • Wordpressはプラグインを完全に信頼するモデルで、いけてないプラグインのせいでWordpress自体の評価を下げている

  • bulkneets: バグハンターのモラルの問題

  • yagihashoo: npmのパッケージに実行コードが入ってしまう問題

  • bulkneets: パッケージはバージョンを固定してないことが脆弱性

  • yagihashoo: GitHubのセキュリティアラート便利

    Renovate | Automated Dependency Updates

  • ただ非互換の変更もあったりするので上げにくいことも多い(これ本当にアップデートする必要がある脆弱性なのかがバラバラ)

  • k2wanko: npm auditはnext.jsの脆弱性のやつがでてこなかった

  • bulkneets: 逆に自動アップデートで、あやしいやつが降ってくる問題がでてくる

  • ockeghem: どこかでトレードオフがある。できるだけプラグインを入れない + 自動アップデート

  • bulkneets: CVE全部読むことで、実際にサービスでどういう影響があるかを見てる

    • CVEが投稿されるチャンネル + Code Executionをキーワードハイライト
    • XSSとかはサービス依存だからいいけど、TLSとかセッションとか
    • セキュリティ系のメーリングリストは攻撃コードが載ってたりする

  • k2wanko: ウェブに話を戻す

  • k2wanko: 開発者はどこまでセキュリティをきにするか

  • yagihashoo: そこまできにする必要がない

  • bulkneets: ブラウザが直すべきなのにサイトが直すの嫌

    • 事例としてnavigation.sendBeaconで送れた話は結構ながびいた
      • content-typeに依存してた問題
      • Flashがなくなれば大丈夫ではあるけど
    • カスタムヘッダが一番安全ではあるけど

  • ockeghem: 徳丸本もその辺悩んだ

    • カスタムヘッダも一応書いた

  • bulkneets: 脆弱性があるブラウザを使っているやつが悪い

  • ockeghem: 画像アップロードのやつはIEが問題なので消した

  • bulkneets: セキュリティのヘッダが多くなりすぎる問題

  • ockeghem: セキュリティのヘッダがつけてないだけで脆弱性スキャナが検知する問題

  • yagihashoo: つけておいて問題ないものはつけておきたい

  • bulkneets: ただ意義を理解しないでとりあえずつけておくと、別の機能が動かなくてうっかり外す問題がおきる。

  • yagihashoo: 全部入りのセキュリティ機能が欲しい

  • bulkneets: X-FrameOptionとかは3rd party cookieがちゃんとしていればそもそもクリックジャッキングはおきない

  • bulkneets: same-siteもポップアップで少し問題があるので、全部つけると扱いにくいときもある

  • bulkneets: サーバのライブラリがsame-siteの読み書きに対応してないときがある

  • yagihashoo: DNSのライブラリで同じようなことがあった

  • bulkneets: Cookieはprefixで機能対応してたりするので、いままでのライブラリでも動く

    • ただのネーミングルールだから
    • Set-Cookie | MDN
    • Cookieは別のサブドメインからセットできるから、送られる側は区別できない
    • 外からCookieをセットして、攻撃者のアカウントでログインさせる攻撃の対処に __Secure Cookieとかで対応できる
    • 今の大体のサイトはログインさせることができる

  • ockeghem: double submit cookie

  • bulkneets: ;と:をどっちも区切りとして扱うCookieパーサーもあったりして問題がおきることもある

  • k2wanko: CSPを入れられるかどうか

  • yagihashoo: Lv2、Lv3で出し分けとか開発環境だと、webpackのeval対応とかコンソールを埋め尽くすとか大変

  • bulkneets: nonceとかも運用が難しい

  • yagihashoo: nonceCDN対応とかできないかも

  • k2wanko: CSPのreport-only

  • yagihashoo: CSPのreportで拡張機能のエラーが送られると問題がおきる

  • bulkneets: エラー収集でユーザー名が取れるとかの問題がおきたりしてる

  • ockeghem: MSがXSSフィルターを辞めてCSPに寄せると言っていたけどできるのかどうか

  • k2wanko: GDPRとかの問題

  • yagihashoo: あれは手続き的な話

  • bulkneets: Cookie法が形骸化した

  • bulkneets: P3PCookieという形骸化した歴史的経緯

    • 同意が必要なものを出す

  • bulkneets: 同意説明はユーザーによって欲しい粒度が違う

  • yagihashoo: machine readbleな同意表現が欲しい

  • bulkneets: まずは機械的な表現が欲しい。プライバシーは人間相手なので、解釈の違いがでる

  • ockeghem: JavaScriptに同意が必要になる時代がくるのでは

  • bulkneets: 裁判次第

  • bulkneets: Google検索からリファラが送られるのはユーザーが知らないことも多い

    • 業界の中での常識と一般ユーザーの認知は異なる

  • yagihashoo: Canvas finger printing

  • bulkneets: 効果測定とかで未だにfinger pritingが使われている

  • yagihashoo: これも似たような問題

  • bulkneets: コンテキストによって許可するかどうかと難しい

    • 不正対策という意味合いで使われていることもある
    • 普段と異なる場所からログインしてる場合とか

  • k2wanko: 広告

  • bulkneets: 広告のカンファレンス行くとセキュリティ、プライバシーのセッションがない

  • yagihashoo: 知らないというケースが多い

    • 知ってて無視してるのはだめ

  • ockeghem: 使えるから使えばいいじゃんという話も多い

  • bulkneets: JSONPで広告配信してるやつ

    • ターゲティング広告でデータが取れてしまう問題

  • セキュリティ、プライバシーリスクがプライスレスてきな値段がわからない

  • yagihashoo: プライバシーの問題は回復不可能

  • bulkneets: 比較することがだいたいおかしい

  • bulkneets: クライアント側でおきる脆弱性は検知できないこともある

  • 脆弱性 を公表しないことがある

  • k2wanko: どうやったらその辺が変わるか

  • bulkneets: 0day出せば変わるけど、野蛮な方法

    • ハードウェアだとPL法とか
    • ソフトウェアだと被害の大きさが定量ではないので放置されてしまう

  • bulkneets: 普段からMITMする生活をしている

    • iPhoneでVPNに接続すると自動的になるようにしている
    • Androidだと面倒

  • bulkneets: 検証の手間も大きくなっている

    • 独自プロトコルとかだと面倒になる
    • GoogleがQUIC使ってるとか
    • キャプチャできないとかがおきる

  • yagihashoo: BurpがHTTP/2対応してない

  • bulkneets: SourceMapとか他人でもデバッグできるようにして欲しい

  • k2wanko: 難読化の問題

  • bulkneets: SourceMapとかは食べ物に原産国表記みたいな話

  • k2wanko: セキュリティのお気持ち

  • ockeghem: コピペ問題

    • 権利の問題
    • 脆弱性もコピペ問題
    • 検索してでてきた最初のコードに脆弱性
    • SQLi対策とか

  • ockeghem: C言語の入門書の改定で脆弱性の話が入る

    • PHPで入門書に脆弱性のツッコミをしていた時に、賛否両論だった
    • ユーザーランドとホストランドの脆弱性対策
    • でも入門書とかそういうところから上げていくしない

  • bulkneets: 開発者一人ひとりが当事者意識持ってないといけない

    • プライバシーのところも法務チェックOKもらえたので大丈夫とかならないように

  • yagihashoo: 開発者がセキュリティのことをすべて学ぶのは難しい。逆も同じ

    • とっかかりは必要

  • bulkneets: とっかかりがあれば詳しい人に聞くという対応が取れる

  • ockeghem: 何でも無料で答えると逆の職業破壊

  • k2wanko: もっとセキュリティ

HTTPS

登壇

ログ

  • jxck: 下から上へ行く
  • 4ma_: まずシマンテック
  • kjur: 去年はPKI苦難の時
  • jovi0608: 3割ぐらいのシェアを持ってるPKIもやらかしてしまってだめになった
  • jxck: シマンテック -> PKIの話で
  • 4ma_: 元々ベリサインだったとか買収で大きくなってきた会社
  • jxk: 次はGPKI
  • jovi0608: GPKIはv2になる話
  • 4ma_: 実際に外へ発行されたものじゃなくて中で発行されたものについても分かるようになった
    • Certificate Transparencyで誰でもログを監視できるようになった
    • ChromeがCertificate Transparencyを要求してる
  • jxck: CAもブラウザみたいに参入障壁が高くなって、CAも減っていくのでは
    • EVのようなマネタイズもしにくくなった
  • 4ma_: 国、地域ごとにルート認証局をもつ
  • kjur: ルート証明書の数自体はそこまで変わってない 3-400ぐらい
    • EVのように組織確認よりもDVのようにドメイン確認レベルが主流になってきている
  • jovi0608: 最近GoogleとAmazonがルートに参入してきた
    • 掟破りのルート証明書
    • EV証明書はなくなるとは思っている
    • TLSの世界では認証と信頼は別
    • 証明書はFQDNを認証しているだけで、信頼はしていない
    • EV証明書は信頼をとうろしてるけど、そこまで大きな信頼になっていない
    • コンテンツの信頼は保証してない
  • EV証明書のインシデント
  • jxck: Let’s Encryptでいいじゃんと言われたと言われた時にCAは何をするのか
  • 4ma_: EVとBR(EV以外)は確認のルールは違う
    • 名前の区別をしたいという目的はあるけど、結構夢
    • 都道府県とかも結構商標とかでもルールが違う
  • jxck: TLSレイヤー
  • kjur : TLS 1.3がやっとでてきた
  • jovi0608: TLS 1.3やりとげた
  • 4ma_: TLS 1.3以外の仕様を作れるような状態ではなくなってきた
    • Alternativeな仕様を作るのが難しい
  • jovi0608: TLS1.3は仕様とか形式証明書とか実装とかのイテレーションをした
    • このイテレーションがうまく行った
    • プロトコルの作り方が今までと違った
  • kjur: https://www.ssllabs.com/ssl-pulse/
  • https://kjur.github.io/www/sslpulsetrend/index.html
    • Google はQUIC、FBが殆ど
  • jovi0608: 世の中から1.1とか1.2をなくすのは大変
    • git clone した時にエラーでてハマった体験
  • 4ma_ : 問題は問題が起きないとわからない問題
  • jovi0608: HTTP 1 HTTP/2はなくならない
    • TLS 1.2はそのような起点となるのかも
    • 一度うまく行けば、そのフローに載っていける
  • kjur: TLS 1.2はIoTとか使われるようになって、広く残るのでは
  • jovi0608: 0 RTTは1.3でも簡単ではない
    • 量子コンピュータがきたら今のTLSは解読されてしまう
    • post-quantumをやっておいて備えておかないといけない
  • jovi0608: 量子コンピュータは周期性があるものは見つけるものが簡単になる
    • 鍵交換の部分はforward securityがないといけない
  • jxck: HTTPSやっていく-> 4年後
  • kjur: HTTP Public Key Pinning (HPKP)とかHSTSとか色々やってきたけど、ずっとダウンしっぱなしになってしまうような問題がある
  • 4ma_: 成熟度があまり高くない状態で進んでいってしまった
    • Securityには必ずAlternativeが必要。それがUnSecureであっても
  • もう一つのレイヤー
  • jxck: 配信元とコンテンツの安全性の分離
  • jovi0608: 今までコンテンツに対して認証はなかった
    • コンテンツの認証や信頼をやろうとしてる
    • AMPの例
    • AppStoreやGoogleAppsみたいなことはウェブでもできる
  • kjur: Signed HTTP Exchangesと通常の証明書を共有しちゃうのではないかというか
  • jovi0608: プロじゃないと難しい仕組み
  • 4ma_: コード署名と同じような考え方になるんじゃないかな
    • Signed HTTP Exchangesは期限あるので、アーカイブとは相性悪い
    • 「安全」は天井があるが「安心」は青天井

Frontend(#nwc_front)

登壇者

ログ

  • laco2net: あの頃から技術的/フレームワーク的にはそこまでは変わってない

    • DXは上がってきた

  • koba04: ReactとかVueとかAngularとかだいたい同じ方向に進んでいたここ数年

  • laco2net: Angularここ1-2年ぐらいはアプリの最適化とかみたいに話になってきている

  • kazu_pon: VueはDXにフォーカス、Vue CLI 3とか

  • takanoripe: PolymerはWeb Componentsをベースにしたフレームワーク

    • PolymerチームはもうPolymerの開発しない
    • lit-htmlとかlit-elementとかより小さい部分をやっていく

  • laco2net: フレームワークの限界はブラウザの限界

    • 良いAPIを作れるかのセンスの問題
    • 機能としてはフレームワークじゃなくてブラウザががんばる話になっている

  • kazu_pon: まだウェブ開発は難しい

  • koba04: 状態管理が難しいと言われてきたけど、その辺は固まったの?

  • laco2net: 2014年は状態管理はやるやらの話だった

    • 今はやるのが前提になっている
    • Angularはngrxという頼れる1つはある。他のも選べる

  • koba04: 前回やったときより型がすごい浸透した

  • laco2net: AngularはTypeScript前提

    • Flowは型がJavaScriptに必要というところに貢献した

  • takanoripe: 初心者に対して型を教えるのはどうやるか

    • primitiveなところは簡単だけど、複合型になると…

  • laco2net: JavaScript書いて型推論して欲しい

  • koba04: TypeScriptを使うことでLintのフェーズに変化はあった

  • laco2net: TSLintはあんまり使ってない

  • laco2net: 最近はテストのレイヤーが上がった

    • Cypressとかでてきてやりやすくなった

  • koba04: 去年変わったことは?

  • laco2net: React.lazyとかコンポーネント単位の遅延ロードができたので、コンポーネント設計は少し変わってくるかも

    • 今まではAtomic Designがよりどころみたいな感じだった

  • takanoripe: デザイナーとエンジニアのコンポーネントの切り方が違う問題

    • エンジニアが切っているパターンもあれば、エンジニアがFigmaとかコンポーネントを切って作っていく

  • koba04: Storybookは結構コンポーネント設計の考え方は変わった

  • kazu_pon: 開発者以外でも確認できる

  • takanoripe: Story書かなくても勝手作って欲しい

    • ちょっと気を抜くとStorybookが死ぬので、死なないStorybookが欲しい
    • 保守コストがある

  • kazu_pon: コンポーネントの分割統治について

  • laco2net: コンポーネント設計は自己満足みたいなところがあった

    • Storybookなどでコミュニケーション手段となった

  • kazu_pon: デザイナーはトップダウンが多いので、もう少し何かありそう

    • デザインも組み立てられるデザインになるのでは

  • kazu_pon: Observableについて

  • laco2net: 仕様としてObservableは特に進んでない、Angularの実装としてのObservableは浸透してる

  • kazu_pon: Vue 3でObservableのAPIが入る

  • laco2net: ObservableはInput/Outputどちらも非同期

  • koba04: Service Workerはつかってますか?

  • koba04: Service WorkerでCache.addしまくるサービスが出てくるとおもったけど、思っていたより出てこなかった

  • takanoripe: workboxを使ってる

  • laco2net: Angularが出力するservice workerのコードを使う

  • koba04: low levelな感じなのでそれをラッパーを使う感じなっている

    • Extensible webっぽいAPI

  • laco2net: 最近だとdeclarative routerとかhigh levelなものとか

  • kazu_pon: PWA

  • laco2net: Google I/OでPWAをやろうからPWAでどうやるかに変わってきた

  • takanoripe: iOSのSafariだとPWAでログインできない問題

Web Components

  • kazu_pon: EdgeがChromiumベースになると主要なブラウザでは実装される
  • laco2net: 一時期に比べてWebComponentsに夢を見なくなった
  • takanoripe: アプリを作るのはフレームワークで作る
  • laco2net: WebComponentsだけでアプリを作るのは辛いということはPolymerでわかった
    • WebComponentは属性だけでデータ渡さないといけない
    • 自分のコントールできるコンポーネントと外で読み込まれるコンポーネントの境界がWebComponentになるのでは
  • laco2net: WebComponentで分けたときの2重ロードはimportのキャッシュで解決するのでは

module

  • koba04: 未来でもwebpackしてる
  • YES

Layered API

Off the main thread

  • laco2net: 2-3年後に当たり前になるのでは?
  • koba04: 何をoffにするのか?
  • laco2net: ロジックとか
  • takanoripe: fontsのサブセット取得