Web 技術年末試験 2024 講評 #web_exam2024

作問意図

今回は、大問テーマとして何を選ぶかが非常に難しかった。

2024 年のトレンドという意味でも、PQC と Passkey の話は出したいと思っていたが、どちらもコーディングなどを問題にすると規模が大きく難易度が上がるため、半分が分かる問題に落とし込むのが難しかった。

最後まで、別のテーマにするかを迷い、入れたり外したりを繰り返した結果、完成が直前になってしまったため、事前に少人数に対して模擬試験を実施することもしなかった。

結果、当日になって一部、作問から回答を消し忘れるミスがあったため、そこだけ全員加点とした。これも、平均点が少し上がっている要因になってもいる。

アンケートでは最も難しかったのが「大問 1: PQC」で、最も簡単だったのが「大問 3: Popover」だったようだ。

大問 1: PQC

PQC は、2024 年にちょうど NIST によるアルゴリズムの選考が終わったため、このタイミングで出そうとは早い段階から構想していた。

とはいえ、耐量子暗号アルゴリズムなどの内容は難しすぎるため、最低限以下の 3 つが振り返られる作問にした。

• NIST が 3 つのアルゴリズムを採択したこと
• デプロイへの課題/問題
• なぜ Web にも PQC が必要なのか

アルゴリズムは、調べると「採用された名前」、「リネーム前の名前」、「規格の名前」の 3 つが混在して出てくる。そこを問題文で補強しておいたので、採用された名前は満点で、他は減点とした。

デプロイは、文章回答でバリエーションが多かったが、「分割されたパケットをうまく処理できない実装がある」という点が触れられていれば加点している。

最後の問題は、それっぽいが間違った選択肢をでっちあげるのが難しい(かつちょっと楽しい)が、多くの人にとってはさっと読んで正解できる問題だった(正答率も 100% だった)ため、もう少し難しくても良かったかもしれない。

大問 2: Passkey

Passkey の作問は、今回最も苦労した。

WebAuthn のコーディング問題も考えたが、規模が大きくなりすぎる。Signals API など 2024 年にあった変更について触れるのは、少しニッチすぎる。そこで、文章問題寄りにし、「そもそも Passkey はなぜ必要なのか」の部分についての知識問題に寄せることにした。

しかし、Apple が発表したばかりのころと比べ、「Passkey とは何か」「何がどうあれば Passkey か」というのは、非常にブレがある話になってしまった。これは Passkey が「仕様」というより「コンセプト」や「ブランド」のような色合いが強くなり、その使われ方も多様化しているからだ。

特に今回の T/F 問題は、どう作ってもケチの付け所が多くなりそうなため、あまりやりたくなかったが、これしかもう出し方が浮かばなかった。

作問観点は以下の 3 つだ。

• なぜ Passkey はフィッシング対策になるのか
• 今言われている Passkey は Apple の製品ではなく FIDO を主導としたもの
• Apple の製品だった頃の Passkey と、今の Passkey はどれくらい変わったか

フィッシング対策は、単に「サイトの一致」や「URL の一致」と濁されないように、あえて RPID を必須語句としたが、実際答え方はそこまで変わらない。「登録したサービスと同じでないと使えない」という点が説明できていれば加点している。

T/F については、Apple が発表したころは「iCloud Keychain で同期できる」ことが売りの 1 つであったが、今の Passkey は「同期」自体を必須とせずに、単に Discoverable Credential (Resident key)があり、それをどう扱うかの部分にかっちりした規定が無いという部分を前提に作問した(ここが気に食わない人にとっては、気に食わない問題になっていると思う)。

したがって、iPhone/Android のように同期できても良いし、1Password のように 3rd Party でも良いし、Discoverable Credential が保存できれば、パスワードマネージャである必要もない。

そのあたりを踏まえて「素直に」解けば解けると思ったが、多くの受験者が「自動車試験学科脳」になってしまったため、裏を読んだ回答をされてしまったようだ。次回から T/F 問題はあまりやらないようにしたい。

大問 3: Popover

Popover は、コーディング問題としても比較的出しやすい部類だった。今回は APG の menu pattern を参考に、Popover 以前と以降でどう変わるかという観点で作問した。

• そもそも APG というものがある
• 単に display を切り替えるだけでは問題がある
• Popover を用いるとキレイに実装できる

APG のリンクは、深いのと浅いのがあったが、そこを問いたいわけではないので、どちらでも加点にした。

HTML のコーディング問題は、「JS を用いず popover の機能のみでメニューの開閉が行えること」と書いたが、閉じる方を見落としている人が多かった。

CSS のコーディング問題は、position-area と position-try-fallback に書き方のバリエーションが多いが、指定通りに動くなら加点とした。また、他に CSS が書かれていても、動きそうであれば減点はしなかった。

CodePen での提出にし、挙動の確認をするという案もあったが、採点が大変になりすぎることと、動かない場合の部分点も難しいため、今後も今回のようにコード提出にすると思う。

大問 4: Iterator Helpers

Intl/Temporal とも迷ったが、難しくなりそうなので Iterator Helpers にした。

といっても、実際 Iterator Helpers 自体は単なる便利メソッドで、それ自体は簡単であるため、Iterator 自体の方を中心とした。

観点は以下だ。

• Iterator Helpers の使い方
• Generator/Iterable/Iterator などの語彙
• Iterator Helpers が呼べる Iterator の作り方

特に語彙がややこしいと思うので、これを穴埋めにしたのだが、想定回答からコピーする際に回答を消し忘れるというミスをやらかした。ただ、調べれば埋められると思うので、全員 6 点加点としている。

Iterator のコーディングは、フルスクラッチにするか迷ったが、さすがに時間が足らないかもしれないと思い、サンプルコードを提示してそれを元に実装できるようにした。最終的には Iterator Helpers を呼ぶ問題でありながら、サンプルコードの方では extends Iterator していないので、これに気づかないと条件を満たせない。継承していないコードは減点とした。継承していると Symbol.iterator は不要だが、書いてあっても動くため不問にしている。

fib.take(10).toArray() を想定して「Iterator Helpers を用いること」という条件をつけたが、[...fib.take(10)] のようなコードがいくつかあった。使ってはいるので加点にしている。