セキュリティとUXの◯◯な関係 - 参加記
「セキュリティとUX」のイベント
2017年6月9日(金)に開催されたセキュリティとUXの◯◯な関係に参加してきました。
「セキュリティとUXの◯◯な関係 - すれ違い続けた二人の運命の邂逅～セキュリティとUXは本当にトレードオフなのか」というテーマで、ビジネス・アーキテクツ(BA)の太田さん、徳丸本の徳丸さん、ヤフーの日野さんの3人が講演してくれました。
80人の参加枠に260人ほどが応募され主催側もこの人数は想定外だったとのことでしたが、追加されたレポートするぞ枠で参加したので、ここでレポートしておきます。
（執筆後のコメント）なんだかずいぶんと長くなってしまいました。読みたいところだけを読むと良さそうです。
（6月13日追記：他の方の記事はセキュリティとUXの◯◯な関係 - 資料一覧 - connpass にまとめられています）
セッション内容
今回のイベントではWebコンテンツを作っていく上で我々は何を意識すべきか、組織としてどのように振る舞うべきかといった表面的・概念的な内容がメインでした。
セキュリティの深い話はほとんどなかったので、セキュリティに関心のある人には少し物足りなかったかもしれません。
ただ、セキュリティに関心のない人やUXという言葉を知らない人が多いような組織で、そのどちらの品質も担保するにはどうすべきかということを考えるという点では有意義な内容でした。
以下でスライドの内容を参照しながら、振り返ってみます。
アクセシビリティ vs セキュリティ ～こんな対策はいらない！～（BA 太田 良典）
ひっそりとスライドを公開しましたがフォントがちょっとおかしいですね……。あとでなんとかします。 https://t.co/uJZybzMw9w #securityux
— 水無月ばけら (@bakera) 2017年6月9日
太田さん（@bakera）は、ウェブアクセシビリティ基盤委員会（WAIC）、HTML 4 の仕様書邦訳計画、独立行政法人情報処理推進機構(IPA)が毎年公開する情報セキュリティ10大脅威の選定に関わっている方です。http://bakera.jp/profile にいろいろと書かれています。
ばけらさんのセッションでは、
について話されました。
アクセシビリティとセキュリティ
2015年7月にデザイニングWebアクセシビリティという本を出している。この本では、誰でもアクセスしやすいWebサイトの制作プロセスについて、実例を交えながら解説している。セキュリティに関係する内容（CAPTCHAの問題、入力が困難なフォーム、セッションタイムアウトの問題）も掲載している。今回はそのお話を紹介する。
といった導入でした。
CAPTCHAの問題
バリデーションの問題
お問い合わせフォームなどで「住所」の入力欄があるとき、「赤坂ビル2F」と入力したら「全角で入力してください」とエラーがでた。
なぜこのような「半角を許さないバリデーション」が生まれたのかについて、どうやら「一部の半角記号を使ってSQLiやXSS攻撃ができる。全角しか受け付けないようにすれば安全だ！」という発想からそのようなバリデーションが生まれた可能性があるのではないかとのことです。
無意味なバリデーションは使い勝手を悪くするだけなので、必要性をきちんと説明できない対策はやるべきでないということですね。
バリデーションによってセキュアになるわけではない。バリデーションとセキュリティは別の話。
という話で、大垣さんの名前が出て、徳丸さんと浅からぬ関係であると紹介されました。
- 大垣さんが「入力バリデーションはセキュリティ対策である」と主張し、対して徳丸さんが「バリデーションはセキュリティ対策とは言えない」と主張したやりとり。
- 大垣さんと徳丸のバリデーション論争のリンク集 - 徳丸浩のtumblr
- 徳丸浩氏との長年の議論に終止符 - 論理的／体系的セキュリティとそれ以外 | yohgaki's blog
少し話が逸れますが、たとえば「入力バリデーションはセキュリティ対策か」というテーマを考えたとき、（読者の）みなさんは何かしらの意見を出せるでしょうか。徳丸さんの主張が全て正しいとも限りません（正しいかもしれません）。天動説と地動説のように、どちらの主張が正しいとするか判断するのが難しいこともあります。
議論したり深く考察することは非常に重要です。こうしたイベントに参加したり関心を持っている人であれば、「自分ではどう考察するか」を意識しながら記事を読んだりすると良いかもしれません。
セッションタイムアウトの問題
「一定時間操作がなかったのでログアウトしました」というもの。視力の悪い人、操作に慣れていない人などは入力に時間がかかってしまう。健常者でも入力に時間がかかることがある。例えば、泣き出した赤ちゃんをあやしたり、トイレに行ったり、何か別の作業を併行した場合など。
セッションタイムアウトを有効にする意義については、
「もし、本人がブラウザを終了させずに席を離れた隙に他人が操作をした場合、各種の情報が漏れてしまう」（IPAの2002年の文書より）
といった記述があります。特に（施設等の）共用パソコンでの問題を想定できそうですが、実際に他人にセッションを乗っ取られる問題と利便性のバランスが取れているのか？ということをよく考えたほうがよいという話です。
まとめ
サービスの提供者は、セキュリティを考慮して利用者が安全にサービスを使えるようにしなければならない。しかし中途半端なセキュリティ対策を行うと、セキュリティ面で無意味なばかりか使い勝手が悪くなってしまう。
サービスは便利に使えなければ意味がない、ということを忘れてはいけません。本当に必要なことを見失うと、セキュリティもUX（ユーザ体験）も良くないものになってしまうのでよく考えなければいけませんね。
セキュリティ対策の都市伝説を暴く（徳丸 浩）
資料公開しました #securityux / “セキュリティの都市伝説を暴く” https://t.co/L2WGH89bKn
— 徳丸 浩 (@ockeghem) 2017年6月9日
徳丸さん（@ockeghem）は、Webセキュリティ界のすごい人です。https://www.eg-secure.co.jp/company/profile/ にもいろいろと書かれています。
徳丸本と呼ばれる著書「体系的に学ぶ 安全なWebアプリケーションの作り方」は、Webセキュリティに関する書籍としてとても素晴らしい本です。発売は2011年ですが2017年現在でも内容が古いといったことはありません。Webアプリケーション開発者が最低限理解しているべき情報が非常に読みやすくまとめられているので、もし読んだことがなくあなたの会社にもこの本が置かれていなければ Amazon またはお近くの書店にてご購入されることをお勧めします。
徳丸さんのセッションでは、
- セキュリティの都市伝説
- パスワードのマスク表示
- IDまたはパスワードが違います
- パスワードの有効期間
- autocompleteの停止
- 戻るボタンの問題
について話されました。
セキュリティの都市伝説
セキュリティのために「不便」を強いられることはありませんか？パスワードのマスク表示、autocompleteの禁止、戻るボタンの禁止など。それで本当に安全になるのか？を考えてみます。
といった導入でした。
パスワードのマスク表示
<input type="password"> のフォームコントロールでは入力内容がマスクされる。ショルダーハック対策として有効そうだが、長い複雑なパスワードを入力するときには入力ミスしていないか確認したいこともある。実はIEでは「マスク表示を解除する」ボタンが実装されていて確認したいときにはマスクを解除できる。他のブラウザでは残念ながらそのような機能は実装されていない模様。
「パスワードを隠すのをやめよう」という記事がありますが、マスク表示自体を否定するのは極端な考え方にも思えます。ショルダーハック対策を意識することも必要といえば必要でしょう。（記事では、攻撃者がその気になればマスクしていようがパスワードを盗み見できると書かれていますが、マスクに意味がないとは思いません）
「パスワード表示ボタン」をアプリケーション側（JavaScript）で独自実装するのは危険が伴う。
個人的にもこの機能を独自実装することはお勧めしないですが、どうしても独自実装したい場合にはパスワード入力用の input 要素を type="text" にして JavaScript で操作するのではなく、type="password" のまま別のDOMオブジェクトに input.value を出力するような方針が良いかと思います。HTTPS 通信ではない場合に <input type="password"> があると「パスワードを盗聴される危険がある」と警告を出したり autocomplete を無効にするブラウザもありますが、type="text" にした場合、その恩恵を受けられなくなってしまいます。（参考サイト）
IDまたはパスワードが違います
不正ログインの攻撃者にヒントを与えないように、どちらが間違っているかを教えるべきではないという考えがある。しかし、利用者がタイプミスした場合、どこが間違っているか分からないのは不便ではないか。TwitterのようにIDが公開されているサービスでもこれをやっているのはなぜか。最近のGoogleのログイン画面ではログインIDを先に入力させていて、ログインIDが存在するかどうか分かるようになっている。GoogleのようにログインIDとパスワードを別々する場合のメリット・デメリットはどうなるのか。
というお話です。
- メリットに関して
- フィッシング対策になる
- 利便性をあげることで、強いパスワードをつけてもらいやすくする（パスワード表示ボタンと同じ動機）
- デメリットに関して（IDとパスワードを別々に攻撃されたら？）
- それはそれで対策する（アカウントロックとか）
- オンラインバンキングでは2要素認証が一般化しつつある
- オンラインバンキング等は、フィッシングやマルウェア感染される前提の対策に移行しつつある
- みずほ銀行のトランザクション署名では、MITB攻撃などで振込先を書き換えられるような攻撃を受けた場合でも不正送金が成功しないように、振込先口座番号を基にしたワンタイムパスワードでのチェック機構が用意されている
- IDとパスワードを別々に入力する仕様にして、別途対策するのもあり。
一般的なサービスで、ログイン時に「ログインID」を先に聞くとフィッシング対策になるというのはどういう仕組みなのでしょうか。「(1)ユーザが、フィッシングサイトでID入力」→「(2)攻撃者が、正規サイトにそのIDを入力してレスポンスを受ける」→「(3)攻撃者が、フィッシングサイトで正規サイトのレスポンスを表示する」とした場合、ユーザは正規サイトでないことに気づけないのではないかと思ったのですが、徳丸さんはどういう説明をしていましたっけ。
ただこのお話を聞いて、「IDとパスワードのどちらを間違えたかヒントを与えても良い」という考え方も悪くはない、ということを考えるよいきっかけになりました。
パスワードの有効期限
パスワードに有効期限を設けて半強制的にパスワードの定期的変更をさせるようなもの。WindowsやLinuxのOSアカウントでは採用されていたりする。Webサイトでもオンラインバンクで採用されている事例も。IPAの公開資料でも過去には「パスワードの定期的変更」が推奨されていた（IPAの2008年の文書）。
議論されるまでは「パスワードの定期的変更はセキュリティ対策である」であるという認識に疑問を持つ人は少なかったようですが、徳丸さんには浅からぬ関係の方が少なくないようで、パスワードの定期的変更の是非についてもこれまでに重要な議論を残してくれています。
2016年頃には「パスワードの定期的変更は有害である」という認識が広がったようで、各種メディアでもパスワードの定期的変更を批判する記事が出てきています。しかし皮肉なことに、パスワードの定期的変更を批判する趣旨でトンチンカンなことを書いている記事も少なくありません。
おっと、つい脱線した話をしてしまいました。閑話休題。
前述のIPAの2008年の資料では、英数記号（93種）6桁に注目すると約54日で解読（不正ログイン）可能と書かれているが、これは秒間約14万回の試行となる。オフラインクラックではこの速度は出るがオンラインクラックでは非現実的ではないか。IPAに限らず、オフラインクラックとオンラインクラックを区別せずに論じる記事がある。
2017年5月には「パスワードは定期的に変更してはいけない」--米政府という記事も出てきた。パスワードの定期的変更の効果は、しばしば誤解されている（過剰な期待がある）。自主的にパスワードを定期的に変更するのは勝手にやればよいが、サイト側で矯正するのは推奨されない。
パスワードの（定期的な）変更を強要するということはユーザに変更する手間を掛けさせていることになります。その手間を掛けるだけの意味を説明できないのであればUX（ユーザ体験）を悪化させるだけでしかありません。「安全のために定期的変更」とだけしか言わず「なぜ安全になるのか」を説明できないサービス事業者には、ユーザとして疑問を持った方がいいと思います。
autocomplete（オートコンプリート）の停止
ブラウザの機能で入力フォームに入力値を補完してくれる機能のこと。パスワード入力欄は、サイト毎にパスワードをブラウザが記憶して次回以降に自動入力してくれる。伝統的に、パスワードのautocompleteが有効だと、脆弱性診断の際に危険だと指摘されてきた。
なぜ危険なのか。パスワードは記録するものでなく、記憶するものであるという伝統的な考え方。MITBやXSSで漏洩するリスク、離席中に他人に端末を操作されて盗聴されるリスクがあるじゃないですか。（本当か？）
確かにリスクもあるが、メリットもあるはず。パスワードを全て覚えられますか？最近のブラウザは autocomplete=off にできない（指定を無視する）。つまり、autocomplete=on であるべきだと各種ブラウザの開発者は考えている。なので autocomplete=off にしないと危険だという考えは古い。
このテーマとか議論する甲斐がありそうです。ブラウザ開発者側の主張は正しいでしょうか？（私は懐疑的な立場です。否定もしませんが肯定もしません）
2要素認証（2段階認証とも言われるが、多段階より多要素であることが重要）の話をしましょうか。ログインなどユーザ認証をする場合、そのユーザであることを「認証」するために必要な要素としては、次の三大要素があります。
- 記憶 - Something You Know (SYK)
- 暗証番号、パスワードなど
- 漏洩（使い回しはリスク増大）、推測（総当たり試行）などの脅威に対して脆弱
- 所有 - Something You Have (SYH)
- カードキー、鍵、秘密鍵ファイル、所有メールアドレスへのシークレットトークンの通知、SMSでのワンタイムパスワードの通知など
- 紛失、盗難、盗聴などの脅威に対して脆弱
- 生体 - Something You Are (SYA)
- 指紋、筆跡、声紋など
- 認証する側が生体情報を管理するコストやプライバシー上のリスクが大きい。物理的な認証デバイスが必要。怪我をした場合などに生体要素の再設定が不可能。
各要素を1種類しか用いていない場合、その要素認証の特徴としてある問題（脆弱性）の影響を受けてしまいます。一方、パスワードとカードキーの組み合わせで認証していた場合、どちらか一方を他人に奪われても他人が認証を突破することはできません。
「パスワードを2種類用意する」あるいは「鍵を2つ用意する」といった「1要素2段階認証」では、1段階認証よりは安全かもしれませんが本質的なリスクの軽減にはなっていません。鍵を2つ用意した場合でも大抵はその鍵を一緒に持ち歩くはずですので、鍵が1つの場合とリスクが変わっていません。
異なる要素の認証を組み合わせることが重要です。一般には「2要素認証」を指して「2段階認証」と呼ばれているようですが、この「要素」の種類が異なっていることが重要です。
※上記の説明を書くに当たって、おうちで作れる生体認証システムのご提案 - co3k.org を参考にしました。
さて、パスワードは「記憶(SYK)」要素であったわけですが、ブラウザに記録させてしまうとそれは「所有(SYH)」要素になってしまいます。いわゆる2段階認証で「パスワード」と「携帯端末」を組み合わせた場合、「所有」と「所有」になってしまいますから、2要素ではなく1要素認証になってしまいます。
この問題を回避するには、ブラウザに記憶させた「所有(SYH)」要素を使うために他の要素の認証を予め行う必要があります。これには、「ブラウザのマスターパスワード」や「パスワード管理ツールのマスターパスワード」、または「端末での指紋認証」があります。パスワードを「記憶せず、所有して使う」という方針を採用する際には、多要素認証の意味を理解しておくことが大切です。
戻るボタンの問題
JavaScript でブラウザの「戻る」機能を禁止しているサイトは多い。サーバー側で「戻る」を検知してエラーにしているサイトもある（オンラインバンクに多い）。オンラインバンクでは特にセッションデータとページ遷移の不整合を避けたいという意図がありそう。あるいは単に設計が悪いせいで想定フロー以外の画面遷移ができない実装になった説。
オンラインバンクはPOSTがお好き。入力フォーム項目のない遷移でもPOSTで遷移するものがある。
そのようなサイトは「ブラウザバックするとエラーになります。改めてログインし直してください」と、ユーザへのデメリットを一切考慮していません。そのようなサイトをユーザが使いたいと思うでしょうか。
https://twitter.com/coeurl_tw/status/871066234741112833まとめ
結果的にセキュリティ対策として一定の効果があるものもあるが、そのような保険的な対策にはメリットだけでなくデメリットがあるものもある。デメリットが大きい場合にどうなるか？そのセキュリティ施策、本当に効果があるかよく考えよう。
「よく考えて対策をしよう」という話ばかりですが、もしも考えるのが面倒なのであればその対策をすべきではありません。考えもせず説明もできない余計な対策がアクセシビリティやユーザビリティを低下させてしまいます。セキュリティ対策によってUX（ユーザ体験）が悪化するのは思慮の浅い対策が原因です。あなたが考えるのが面倒ならば、開発者や専門家に任せましょう。
セキュリティ教育とUXの知られざる関係～結ばれていた赤い糸～（ヤフー（株） 日野 隆史）
講演スライドの代わりに Togetter を載せておきます。（6月13日追記：スライドが公開されたので掲載しておきます）
日野さんは、ヤフージャパン社のCISO室セキュリティ推進室サービスマネージャーの方です。CISOは、Chief Information Security Officer（最高情報セキュリティ責任者）とのことです。
ヤフージャパンでは、東京オリンピックに向けて全世界から日本に注目が向く中、日本のWebサービス事業者としてヤフーのセキュリティを高めるための活動をしているそうです。その一環で社員へのセキュリティ教育の体系化や、組織の人間を動かすにはどうすればいいかといったマネジメント論、そのために受け手（ユーザ）がどう感じるか（UX）をうまく考えること（UXデザイン）が有効だといった内容を話されました。
ヤフーでのこれまでと現在の教育体系
ISMS研修や座学、eラーニング、他人に教える経験といった学び方も必要だけれど、より理解を深める、記憶に残りやすい学習方法は実体験だった。演習などのシミュレーション、特にセキュリティ上のアクシデントなどの「逆境における実体験」がモチベーションや理解の促進といった様々な面で効果的だと分かってきた。
座学にしろ実体験にしろ、教育する側が用意すべき「教材」をつくるのは大変ですよね。より効果的な教材として実体験ベースのものが有効だというお話ですね。
関心を持ってもらうための施策
「モノ（規約・ルール）」から入らず「コト（日常体験）」から入る。学ばせるのではなく、学んでもらう動機づけを提供する。そのためにもeラーニングの内容を、学習内容ベースではなく、ストーリー仕立ての事例を考えようという日常体験ベースのものにしたら、関心を持ってもらいやすくなった。
ガバナンス（統制、ルールだから守って）としても自分事化できず、ルールに従うことが苦になってしまう。そうではなく、なぜそのルールが必要なのかを自分から気づいてもらえるような教育・情報共有の仕方が大切で、各自が自分事化できていれば自然と組織としてのセキュリティインシデントを回避できる。
ルールに縛られるということは自由を制限されていることになるので、そのルールの意義が分からなければ誰でさえルールを守ろうという気にならないことが多いと思います。なぜこのルールを守らなければいけないのか？という疑問を最初から解消できるような教育・情報共有が、本当に効果のある教育ということですね。
可視化と測定
社内教育（研修）のUX（ユーザ体験）を改善するためには、現状の問題点や効果測定をする必要がある。そのために「表激化攻撃訓練」のジャーニー化を行い分析をした。また感情を数値化するアンケートを実施した。効果が小さい（盛り上がらない）ところには必ず原因があるので、状況を可視化して対策を打つ。可視化しなければいくら仮説を唱えても周りの人は動いてくれない。
Webマーケティングの用語としても「カスタマージャーニー」という言葉がありますが、ジャーニー化というのは顧客（カスタマー）の行動・思考・感情の情報を基に、どのような理由でそのアクションを行ったのかという事実を旅（ジャーニー）に例えて可視化することですね。ペルソナ分析に似ていますが、ペルソナ分析は事前に予測することに主眼を置いているのに対して、ジャーニー化は事後に結果を可視化することに主眼を置いている感じでしょうか。
効果測定は、起点がないと測れない。ある施策に効果があるかどうかは、実施前の状態を記録しておいたり別の施策での効果と比べたりすることで見えてくる。
大学で講義をする場合も、その講義を選んで受けてもらうまでの体験デザインを考える。事前に興味を持ってもらうために掲示板でのビラ配りをする。中学生でもわかる言葉・受け取りやすい表現になるようレビューする。講義をするときも学生をよく観察する。講義後には次回のためにもアンケートを実施して効果測定をする。
プログラムのデバッグ作業じゃないですが、何を変更したらどういう影響があるのかを正確に見通すには、異なる状態間の比較が重要ということですね。
「伝える」と「伝わる」は違う
「伝える」は送り手側の主観。「伝わる」は受け手側の主観。「伝えた」からといって「伝わる」とは限らない。伝わることを意識して、伝え方を考えなければならない。
当たり前といえは当たり前の話ですが、特にUX（ユーザ体験）という文脈でユーザに「伝わる」ように伝え方を考える必要があるということですね。ある人に伝わったからといって、同じ方法で別の人に伝わるとは限らないと。
学生は最高の先生
偽りがない、真剣、初心に帰れる、励ましてくれる。
弱視の学生さんが最前列で授業を聴いてくれて、真剣に授業を聴くあまり授業後に倒れてしまった。その学生さんの期待に応えられるだけの授業内容だったのか考えさせられた、ということがあった。
伝えたい側と学びたい側のいいお話ですね。教える側がより効果的な教え方を考えるのに、教えられる側のフィードバックが重要だということですかね。
まとめ
まずは打席に立つ（体験する）こと。失敗しても死にはしない。
セキュリティとUXの関係は総合格闘技。何をすべきかはその状況ごとの解釈次第。状況に応じた効果的な技をうまく使うことで問題を解決することが重要。
総合格闘技ですか。なるほど。私は、コンテンツの面白さや使いやすさ（UXやUI）、良い設計・実装や運用の容易さ、セキュリティ（安全性や可用性）の担保などを「心技体」のように思っています。原則は心も技も体もすべて必要で、どうしてもどれかが不十分になってしまうような場合でもできる限りバランスを保つことが大事かなと思います。
そのためにも、プロジェクトが始まってから決められたスケジュールの中で心技体を満足することは難しいので（セキュリティの知見のないメンバーにそれを担保させるのは無理がある）、普段から心技体のそれぞれをきちんと満足できるように社内教育をしたり、社内勉強会の開催やイベントへの参加をしたりといった活動が結果に繋がるんじゃないかと思っています。
ところで、今回、ヤフーの「Hardening」ステッカーが配られましたが、この「Hardening」について何も説明がありませんでしたね。Hardening（ハードニング）というのは一般用語で「システムのセキュリティを堅牢にする」といった意味の言葉です。同時に Capture The Flag (CTF) のようなコンテストと同様の、攻める側ではなく守る側の技術を競う Hardening Project というイベントもあります。
今回のステッカーは、ヤフージャパンが主催する実践型セキュリティ総合演習としての Hardening のものですが、その詳細はサイバーセキュリティ演習を実施しました | LAC WATCH | 株式会社ラックあたりの記事を読むと知ることができるかもしれません。
総括
まず最初に、もし参加者の方がこの記事を読まれていたら、「セキュリティとUXの◯◯な関係 参加後アンケート」へ回答いただけると幸いです。
応募と参加枠について
このようなイベントではいつも悩ましい問題ですが、多くの応募者がいる中で抽選に当たった人しか参加できないというのは、抽選が外れた方はもちろん、主催側としても心苦しいものがあると思います。
また今回のような場合に、後から追加で先着10名枠、のような追加をするのは幸せな方法だったのかどうかと考えてしまいます。（批判しているわけではありません）
今回のイベントの参加者募集の方法がどうだった、ということではないのですが、一般的にこうしたイベントで応募者をいい感じに募集するにはどうすべきかと考えているのですが、参加したい人が参加できないというのはちょっと残念です。
会場までの案内について
セキュリティとUXの◯◯な関係 - connpass に書かれている「受付までの順路」がちょっと分かりにくかったです。具体的には「2階のオフィスエントランス」がどこのことなのか、「向かって一番右側のフラッパーゲート」がどこのことなのかすぐに分かりませんでした。ちょっと考えてこっちかな？という感じで辿り着けましたが、フラッパーゲート付近の看板をもっと手前にも置いたり、ウェブページ上に写真を掲載して順路を案内するなどがあったほうが親切かなと思いました。（なお、私は迷子になりやすい属性の人なので、私の問題なのかもしれません）
会場のいろいろ
プロジェクタでスライドを表示していましたが、前の方がいるために、スライドの下部があまり見えませんでした。会場的に仕方がないのかもしれませんが、何らかの方法で改善できるかを検討したいなと思いました。
ドリンクとお菓子を配っていたようですが、案内されるまで気づきませんでした。奥の方に座られた方は、わざわざ取りにいくのも面倒だったかなと思ってしまいます。数カ所に置いたり、あるいは最初から配ってしまったりしてもよかったのかなと思いました。
ただ、席について、前後の席との間隔に余裕があったのは良かったです。遅れて来られた方が中側の空いている席に座るにも、比較的容易に席まで辿り着ける様子でしたし、途中で帰ったり、休憩時間に離着席するのも他の方をあまり気にしなくて済むのは楽でした。
感想
2時間という時間制限の中で調整するのは難しいのかもしれませんが、質疑応答の時間がなかったのは少し残念でした。質疑応答の有無というより、発表内容について納得のいく部分と「うーん？」という部分があった感じです。「セキュリティとUXの◯◯な関係」というテーマでしたが、なんというかタイトルを「回収」できていない感が残りました。
今回のイベントのターゲットが、セキュリティに関心を持っている人というよりもそういうことをあまり知らない非エンジニア向けだったのかなという印象も受けました。太田さんも徳丸さんもセキュリティの深い話はほとんどなく、ユーザーエクスペリエンスと接する表面的なセキュリティの話だけだったなあと感じました。その範囲の話を伝えたかったということなら良いのですが、参加者に何を「持って帰ってもらいたいか」というところを考えたときに、何だったのかなと（素朴な疑問として）思いました。
無料イベントでお話を聴かせていただいているだけでありがたいので、こうしたイベントを開催いただけたことはありがたく感じています。今後もセキュリティや UX あるいはアクセシビリティなどの Web 関連の情報を共有して、みなさんが考察したり Twitter 等での議論が増えるきっかけとなれば一技術者としても嬉しいので、このようなイベントを応援したいと思います。ありがとうございました。
