fuji_harukaのブックマーク - はてなブックマーク

URL.parse を Chromium で Ship するまで | blog.jxck.io

Intro Chrome 126 で筆者が実装した URL.parse が Ship された。 Chromium にコントリビュートしたことは何回かあったが、単体機能を Ship したのは初めてだった。 invalid URL の処理 new URL() によって、文字列の URL をパースすることができるようになって久しいが、この API は invalid な場合に例外を投げる。例外処理をするよりも、先に URL としてパース可能かどうかを知るための URL.canParse() が提案され、先に実装が進んだ。 URL.canParse(str) // boolean しかし、これでは二回パースが必要になるため無駄が多い。 if (URL.canParse(str)) { // 1 回目のパース return new URL(str) // 2 回目のパース } そこで、失敗したら

fuji_haruka 2024/06/14

リンク

令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

Intro CSRF という古の攻撃がある。この攻撃を﹁古(いにしえ)﹂のものにすることができたプラットフォームの進化の背景を、﹁Cookie が SameSite Lax by Default になったからだ﹂という解説を見ることがある。確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。今回は、﹁CSRF がどうして成立していたのか﹂を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。結果として見えてくるのは、今サービスを実装する上での﹁ベース﹂(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件例えば、攻撃者が用意した attack.examp

fuji_haruka 2024/04/26

リンク

なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io

Intro 10 年ほど前に同じことを調べたことがある。なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatena blog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。この問題についてあらためて記す。仕様策定の経緯表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

fuji_haruka 2023/11/28

リンク

HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io

Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field

fuji_haruka 2022/06/16

リンク

Web のセマンティクスにおける Push と Pull | blog.jxck.io

Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装と Pull 型の実装があると考えている。もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。この話は﹁Push よりも Pull が良い﹂などと簡単に切り分けられる話ではない。﹁自分は今 Push で実装しているのか、 Pull で実装しているのか﹂この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro

fuji_haruka 2021/12/08

リンク

mouseover 中に表示される DOM のデバッグ | blog.jxck.io

Update 2024-03-30: Chrome 123 から "Emulate a focused page" が追加された。これを用いれば良いため、以降の全ての方式は古くなった。 Apply other effects: enable automatic dark theme, emulate focus, and more https://developer.chrome.com/docs/devtools/rendering/apply-effects#emulate_a_focused_page マウスが乗ってないと出ない UIも、そこに Tab などでフォーカスを移し、その状態で Dev Tools の "Emulate a focused page" を有効にすれば良い。 Intro 先日、後輩が﹁mouseover 中にしか表示されない DOM のデバッグ﹂に手こずっ

fuji_haruka 2021/08/21

リンク

Public Suffix List の用途と今起こっている問題について | blog.jxck.io

Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。最近、このリストへの追加リクエストがあとを絶たず、問題になっている。そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ

fuji_haruka 2021/04/21

リンク

ローカル開発環境の https 化 | blog.jxck.io

Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。この辺りの話を、直近1ヶ月で3回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。開発をローカルで行う

fuji_haruka 2020/06/29

リンク

Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io

Intro ECMAScript の Private Class Field の仕様策定と各ブラウザの実装が進んでいる。これにより、従来のJSにはなかった Class の Private フィールドが使えるようになる。提案されている構文や、挙動について解説する。 Class Field Declaration まず前提として、現状の Class のフィールドはコンストラクタで定義する必要がある。例えば count フィールドを持つ Counter クラスを定義した場合、以下のようになる。 class Counter { constructor() { this.count = 0 }increment() { this.count ++ } display() { console.log(this.count) } } const c = new Counter() c.in

fuji_haruka 2019/03/15

リンク

安全な文字列であると型で検証する Trusted Types について | blog.jxck.io

Intro 脆弱性の原因となる DOM 操作の代表例としてelem.innerHTML や location.href などが既に知られている。こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付けるTrustedTypes という提案がされている。まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。element.innerHTML location.href scri

fuji_haruka 2019/01/27

リンク

「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io

Intro 「Socket.IO 使ったほうがいいですか?」という主旨の質問をもらった。これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは最初に、なぜ繋がらないことがあるのかを、きちんと把握したい。まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく

fuji_haruka 2016/08/22

あとで読む

リンク

はてなブックマーク

タグ

ブックマーク / blog.jxck.io (11)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス