新生鳩丸掲示板♯

>ウェンディーズ竹芝店 (www.minatoku-town.com) は、レジカウンターのすぐ横に喫煙席があるという構造のため

アレは確かにマズいと思いますよ･･･。

普通に商品を扱うところ (厨房･･･カナ？) に煙が流れるワケですから。

なので，アノ店の場合は 2F を喫煙席にすればヨイ。

# でもソレだと喫煙席数のほうが多くなってしまうから，昨今の社会的に理解を得るという点では現実的でないカモ。

新幹線に限らないですが、非喫煙者も通らざるを得ないような場所を喫煙可能エリアにする神経が解せませんね。それ意味ないじゃん、と。

たとえば喫茶店で奥のほうが禁煙席で手前が喫煙可、とか。3階が禁煙席で2階が喫煙可、とか。新幹線の新しい車両も「デッキの喫煙コーナー」というのが物理的に分煙されていれば良いのですが、そうでないなら非喫煙者にとっては大変迷惑で辛い状態になります。それだったらこじかたんの言うように喫煙者があったほうが良い。とか思ったり。

あとちょっと話変わりますが、喫煙者のモラルによっては上の段落と同様の状態が出来てしまったりします。たとえば某ビルの3階の出口付近では入館時にタバコを消すための灰皿があるのですが、何を思ったかそこにたむろして喫煙する輩がいます。アホかと。以前の某ビル1階入り口も同じ状態でしたが。あっちは閉じた空間だったでもっとひどい状態でした。

何の愚痴だこれ。

んだから、ちゃんと喫煙車両を用意して（存続して）、デッキは禁煙、でいいジャマイカと思うわけだが。

>禁煙車はデッキも当然のごとく禁煙だと思っていたのですが，そうではないんでしょうか。。。

　それはそのはずです。

　ただ、隣接する車両のデッキは繋がっていますので、禁煙車に隣接する喫煙車のデッキで喫煙された場合、扉が開くたびにその煙が流入してきます。そして扉は結構頻繁に開きます。

　つまり、喫煙車のデッキを禁煙にしないと、隣接する禁煙車に煙が流れ込んでしまうということです。

ん？

禁煙車はデッキも当然のごとく禁煙だと思っていたのですが，そうではないんでしょうか。。。

# 座席というか客席だけ禁煙だとすれば，効果は半減ではないかっと･･･。

>近所のモスバーガーでは喫煙席が別室になっていて完全密封されていました

>（ここまで来ると喫煙席ではなく喫煙室）

>これはこれで、「飲食店でそこまでやるか」という思いもします。

煙草の煙を吸うだけで、頭が痛くなってくる(そこまで酷くは無いですが・・・)私としては食事をする場所できっちりと分離してくれるのは非常にうれしいです。

はじめまして。

近所のモスバーガーでは喫煙席が別室になっていて完全密封されていました

（ここまで来ると喫煙席ではなく喫煙室）

これはこれで、「飲食店でそこまでやるか」という思いもします。

ドトールは入り口に近い席が大抵禁煙席ですね。

喫煙席と同じエリアにある禁煙席に意味はあるのでしょうか・・・？

>>たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。

>

>　そんなブラウザの不具合があれば、フォームが https でも駄目だと思いますが。

結果としては駄目ではありますが、それは自分が信頼したサイトと自分が信頼したユーザーエージェントがもたらした結果であって、信頼していない第三者が介入してセキュアでない結果をもたらした訳ではありません。

なので信頼したサイトが提供しているフォームがアレな動作をしたとしても、それはサイト自体がやられてしまっているとか、管理が杜撰で個人情報が漏れまくりというのと同じであって、通信経路に第三者が割り込んで改竄しているという問題とは別のものです。

で、その第三者による改竄の内容としてブラウザの謎の仕様や不具合を突くものというものも十分に考えられますし、安全を考えるならばその可能性すらも考える必要があるはずです。

>　まあ、スクリプト無効だと使えない系のフォームを使わなければいけない場合は、そういうことを良くやるわけですが。

>　ただ、その HTML を何処に置くかという問題はありますね。受け側が Referer を見たりしていると駄目だったり。

ブラウザを使ってクエリーを送信しなければならない決まりは無いので、そういう場合は人間ユーザーエージェントで対応するとか。まあ、そこまでして利用したいと思うようなサービスというのは無いとは思いますが。

>http://bakera.jp/hatomaru.aspx/ebi/topic/397

>> 出力 HTML を DOM で扱っているおかげで XSS はないのですが、制御文字系は斬るようにした方が良いかも。

>とか。

XMLだとそもそも

http://www.fxis.co.jp/xmlcafe/tmp/rec-xml.html#charsets

に含まれていない制御文字系はそのまま含められないので(数値文字参照でも無理)、無理矢理入れるならbase64とかにするしかないと思うのですが。

>ユーザが確認したソースとブラウザが解釈しているソースが同一でなければならないので、ソースの確認方法に注意が必要かもしれません。

　ですね。微妙に invalid になっている場合とか……。

>たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。

　そんなブラウザの不具合があれば、フォームが https でも駄目だと思いますが。

>今回の場合、その可能性が否定できないのは送信フォームだけなので、それを信頼できるものに、つまり自分でそのフォームが送るはずのクエリーと同様のクエリーを意図したURLに送信するHTMLを自らの手で記述し、それを使用すれば解決できるような気がします。

　まあ、スクリプト無効だと使えない系のフォームを使わなければいけない場合は、そういうことを良くやるわけですが。

　ただ、その HTML を何処に置くかという問題はありますね。受け側が Referer を見たりしていると駄目だったり。

>yuuさんのところで出ていたこれですか?

　元々はその話です。

　しかし、いろいろ考えて条件を追加していったら、既にそのフォームでは絶対無理という結論になっています。

　ので、もはや単なる思考実験と化しています。

たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。安全性を重視するのならば、信頼できないリソースはどこまでも信頼できないと考るべきでしょう。

要するに自分と自分が信頼した相手以外の第三者が関わっていることを否定できなければ危険というわけで、相手側がその手段を提供してくれないのならば、自らがそれを用意すれば解決できるはずです。用意できるものであれば。

今回の場合、その可能性が否定できないのは送信フォームだけなので、それを信頼できるものに、つまり自分でそのフォームが送るはずのクエリーと同様のクエリーを意図したURLに送信するHTMLを自らの手で記述し、それを使用すれば解決できるような気がします。

yuuさんのところで出ていたこれですか?

http://www.web-standards.jp/apply/form_cm.html

送り先は思いっきりASPのような気がしますが(私が攻撃を受けて送り先を差し替えられているのでなければ)。

https://www.mshonin.com/

>Firefoxのインストーラをローカルに保存済みだったのでうっかりしていましたが、

>>hostsに

>>202.181.97.84 download.mozilla.org

>>と追加してからFirefox 1.0.1をインストールして、

>順番逆にしないと偽ホストに繋ぎに行ってしまってFirefoxがインストールできないかも。

自分で仕掛けた罠に自分で引っかかりました【謎】。

とりあえずFirefox 1.5はちゃんとエラーにしてくれることも確認できました。

ユーザが確認したソースとブラウザが解釈しているソースが同一でなければならないので、ソースの確認方法に注意が必要かもしれません。

>ばけらさんが何度も書いてますが、ぜんぜん読んですらいなかったということでしょうか。

確かに仰られるとおりです。よく考えて読んでいませんでした。DOMから(X)HTMLを作り出して出力する仕組みにばかり気がいっていました。(X)HTMLのフォームからDOMにつっこむ際にどうなるかまでについては脳内で曖昧にしていたようです。

今度こそ一生忘れないことでしょう。

ご教示大変にありがとうございました。

心を入れ替えます。

>ということを私は全然知らないわけなのでした。

ばけらさんが何度も書いてますが、ぜんぜん読んですらいなかったということでしょうか。

http://bakera.jp/hatomaru.aspx/ebi/topic/2473

> この日記を処理している hatomaru.dll というプログラムでは、HTML の出力をサニタイズする処理を一切書いていません。すべてが DOM で処理されている (そして InnerXml に値を直接セットしないと決めている) ので、サニタイズを意識する必要がないのです。これは非常に気が楽でした。

とか。

http://bakera.jp/hatomaru.aspx/htmlbbs/article/3321

>　DOM でやってしまうという方法は、こういうことも一切考えなくて良くなるので、その意味でも楽ですね。

とか。

http://bakera.jp/hatomaru.aspx/ebi/topic/397

> 出力 HTML を DOM で扱っているおかげで XSS はないのですが、制御文字系は斬るようにした方が良いかも。

とか。

http://bakera.jp/hatomaru.aspx/htmlbbs/article/345

> ちなみに hatomaru.dll は内容全てを DOM で作っているので、System.Xml 系のクラスにバグが無い限りは安全、なはずです。

とか。