2007年2月8日
なんかまた変な記事が出ているぞという話を見かけたので。
詳しく検証していませんけど、ざっと読んだ限りではhttpsのページからhttpで何か情報が送信されるとまずいという話のようですが、HTML中の何らかのリンク(例えば画像)等でGETのパラメータ等で何かを投げようとしているのであれば、送信前に警告が出るようにしていれば警告が出ると思います。(多くの人はこの設定を初回の警告時にオフにしちゃってるでしょうけれど。)
それ以外の方法(リライトを利用したりとか)での送信は防ぎようが無いですけど、それってhttpのページでも結局同じ事が言える訳で、そこまで気にするならフル機能のモダンブラウザって、そもそもその人には向かないものなんだと思います。(つまり、多機能なブラウザを使う上では仕方のないリスクだと思います。また、そう考えるとURIのリライトって危ない仕様ですね。)
そもそも、httpsで情報の送信を全て暗号化しておいて欲しい(そういう必要がある)ようなサイトでhttp通信を使っちゃっているというのは、UAに過失が無いとは言いませんけど、どちらかというとコンテンツ提供者に過失があるように思えるんですけど、そういう根本的な話は無視されているようで。
その後のhttpsからhttpへのリンクでの移動をキャンセルできないという話は言いがかりにしか思えません。そこまで気にする人なのに、リンクをクリックする前にステータスバーを見てないんでしょうか? また、普段はhttpなサイトではリンクはいっさいクリックしないような運用をしている人なのでしょうか? これではケチをつけたいがために書いた文章のように見えます。
最後に画像の件ですが、セキュリティバグのままではありますが、bugzilla-jpにも報告あがってます。また、本家では公開済みのセキュリティバグとして登録されています(bug-org 135007)。
これは本家のバグが公開されているので、世間的に既知の問題なので良かったのですが、それへのリンクが無いところを見るとどうも問題のblogの作者さんは、そのこと自体を知らないようにみうけられます。もしそうであるなら、セキュリティに関する話を適切に報告せずに世間にいきなり喧伝するという行動が感心できません。プロダクトへの批判は良いんですけど、セキュリティに関わる話題の場合は、それを使っているユーザがいるわけですから、そのへんのことももう少し考えて気を使って欲しいなぁと思います。
Linuxで文字が表示時にのみ消えることがあるというバグ。修正済み。
原因は単に複数回走る可能性のあるコードで適切に変数の初期化を行えていなかったのが原因。a2には間に合っているので安心して欲しい。
Re: 感性で動く
初回投稿日時: 2007年02月08日17時01分25秒
カテゴリ: 雑談
固定リンク: id=2007020802
SNS:
(list)
Piroさんの言いたいことは理解はできるんですけど、発言した内容を「生理的に」嫌われるのはどうしようも無いかと思います。(以下、ただの愚痴。)
身分を明かしてblogやるってのは、メリットもありますけど、それ以上にリスクが異様に大きい訳です。Piroさんのいつぞやのエントリにもあった気がしますが。
昨日の件も、書く必要が無かったと言われりゃ、そうなのかもしれないです。怠惰な発想をするなら、自分にリスクが無い道を選んだ方が利口なのかもしれません。でもやめてしまうと、今度は情報発信する気が無いとか、閉鎖的だとかそういう話になってくるんでしょう。(私も外部から見たらそう思いそうです。) つまり、黙ってりゃケチがつかないとは限らない。
かといって、何らかの行動を起こすと賛同する人も居りゃ、ケチを付ける人もやっぱりいます。各種イベント、フォクすけ、例のビデオ等々考えてもらえれれば分かるかと思います。でも、ケチを恐れてたら何もできない訳で、前に進みたけりゃリスクを冒さないといけない。ケチの内容によっては反省すべきものもあるでしょうけど、大抵は織り込み済みというか、想定できたものだったりしますし。(ケチを付ける人は万人受けするという前提で行動を起こしているかのように錯覚しているところが興味深いところなのかもしれませんけど。)
何かをやろうとする場合、万人受けなんてのは幻想で非常識な発想でしか無いということを前提に、ある程度の割り切りは必要です。そのバランス取りに失敗した場合に初めてその行動が失敗だったと言える訳ですが、そうじゃない場合は成功なんだと私は思います。
2007年2月9日
Re: Re: Re: httpsだと思っt(ry
初回投稿日時: 2007年02月09日03時14分43秒
最終更新日時: 2007年02月09日06時47分34秒
カテゴリ: 雑談
固定リンク: id=2007020900
SNS:
(list)
リライトって何ですか。Apacheでmod_writeを使って行われるあの処理のことでしょうか。それが何か今回の話に関係してるんですか。
おっとすいません。一般的な呼称じゃないんですかね。mod_rewriteのことです。
で、前回のエントリでは、「httpsのサイトからhttpで通信が行える、なおかつFirefoxはそれを通知するのみで中止できないのは問題だ」という論調から、セキュリティの問題を論じているようにしか私には読み取れません。そして、中止できないのはセキュリティ上マズイと考えた場合、ぱっと思いついた情報の送信方法がgetによる送信と、mod-rewriteを利用してgetの内容を普通のURIと見た目変わらなくしての送信です。getは明らかにデータを送信しようとしているのでUAが警告を出すことは可能ですが、後者は防ぎようが無いという話です。
httpsのページの中にhttpのコンテンツは埋め込まない方がいいとは個人的には思います。でも、仮に埋め込んだとして、それがコンテンツ提供者の過失かどうかはまだわからないと思います。
私はコンテンツ提供者の過失だと言って良いと思います。断り書きがなければ許されるというのは好ましいことではありません。
それはさておき、Firefoxが通信をキャンセルできたとしても許されることじゃないし。
とのことですが、前のエントリのページ自体はhttpsでも、その中にhttpのコンテンツが埋め込まれる場合があります。
という文言からそれは読み取れません。あたかもそういうことが当たり前のようにあり、それを中止できないのは非常にまずいことであるかのように書かれているように読み取れます。(中止できた方が良いということには私も賛成ですが。)
あなたの今回のエントリには中立的な視点での文章が散見されますが、前回のエントリはそうは見えません。一方的にFirefoxのセキュリティは駄目だという結論の元に、わざわざ侮蔑をこめた言葉(例えばイエスマン
)を選んでいる文章だと感じます。
それに、「リンクをクリックした後の遷移先は常にステータスバーに見えているとは限らない」ということを知ってて触れないのはいいのですか。
おっしゃるようにステータスバーの情報は常に信頼できるものではありません。(Bug-org 229050)
まあFirefoxがもし私専用のソフトなのであれば、私はステータスバーを見るタイプなのでケチを付けないかも知れません。でもそうじゃないので。
で、このコメントに戻りますが、もし、一般的な(大多数の)ユーザを想定して書いた文章なのであれば、そういうユーザで「いいえ」が押せないことを不思議、もしくは不満に思うユーザはごく少数でしょう。また、その人たちはおそらくあなたが指摘するようにステータスバーを見ないでしょう。
逆にセキュリティに対するリテラシが高いユーザであればステータスバーの確認や、「いいえ」が無いことへの不満にも納得がいきます。
私はこの件をUIの問題だと思ってました。さらに言えば「問題」よりも、「IEとFirefoxのUIの差」ですね。もっと厳密に言えば「IEと、一般にIEよりも安全だとされるFirefoxのUIの差」。
(中略)
なので、この事象(警告が出ないこと)がバグだったとしても、それセキュリティ上のバグではなくUIのバグなんだと思いました。
何故セキュリティ上の問題とUIのバグとを分離しようとされるのか理解できないのですが、結果的にあなたは前のエントリの最後でIEとFirefoxのどちらが安全であるかという不毛な議論の結論を導こうとしています。セキュリティに関係の無いUIの話でFirefoxは安全では無いという話だったのでしょうか?
私には未だに前回のあなたのエントリはセキュリティに関する話題を提供しているようにしか読み取れません。あなた自身もそのことを一考されたようですし。ならば何故そのまま情報の公開に至ったのかその経緯があなたの説明を読んでも理解できません。より良いアイデア(IEと同様にYesNoの問い合わせをすべき)と、imgの問題を知り得た訳ですから、やはりベンダかIPAに問い合わせるべきだったと私は思います。(結果的に既知の問題のみでしたが、もし、未知の問題であれば、あなたはすごい人数のユーザを危険にさらしていたかもしれません。)
既に知っている人も多いかもしれないが、昨日、ツリーが閉じている間にかなり大きいランディングが発生している。(パッチのサイズは700kB!)
Bug-org 177805で、簡単に言うと長らく設定だけあって(UIはFirefoxでは削除されていたが)使えなかったdpi値への本格的な対応だ。
そしてサマリにあるようにマルチディスプレイではメニューの表示がおかしくなっている。はっきり言って、マルチディスプレイ環境で、プライマリディスプレイ以外でFxを使う人には使えないビルドになってしまっているので要注意。
イージーミスだったようなので既にパッチを提出してあるので早ければ明日のビルドで修正できているかもしれない。
tinderbox大炎上
初回投稿日時: 2007年02月09日08時18分56秒
最終更新日時: 2007年02月09日08時28分58秒
カテゴリ: 雑談
固定リンク: id=2007020902
SNS:
(list)
といっても私の責任ではないのですが。
Stuartの14:54のコメントに吹いた。そんだけ。
イージーミスによるregression。ようやく解決。炎上のおかげで最後の最後まで焦らされた。
修正完了。
個人的にblockerなバグだったので、助かった。
2007年2月24日
報告しづらい。いちいち、説明やら手順やら多すぎる。管理する人は良いんでしょうけれど、ただ報告したい人にははっきりいって苦痛。
あれでも必要最小限の情報です(現実にはあれでも情報不足の時すらあります)。あれより少ない情報量で済まそうとするなら、なんらかの権限を持っている人が報告しているパターンのように、他の開発者(テスタ含む)がその人の常用環境を有る程度知っている必要があります。
バグ報告というものを誰でもできると考えているのであればそれは間違いです。バグ報告をするにはそれなりの知識が必要です。知識がなければバグなのかどうかも分かりません。例えば件の問題をバグだと考えるには、CSSの知識が必要です。Fx2では期待通りの表示だった、では根拠になりえないのです。崩れた表示の方が仕様通りという可能性もあるわけですから。また根本的な問題として、開発者がどのような情報を必要としているかも理解できないでしょう。そして現実問題として、クオリティの高いバグを報告しないと、よりクオリティの高いバグから検証が行われるために、せっかくのバグ報告が埋もれていく可能性が高いです(特に本家)。それは報告者の望むことではないでしょう。(私がbugzilla-jpへの報告を推したのはこれが理由です。あれだけ大量のバグがある中で、現象だけ報告してもおそらく放置されるだけです。)
もし、報告された内容が不十分でさらなる情報が必要な場合、スタッフが確認や問いかけを行います。ですが、それへの返答率というのは案外低いものです。Bugzilla-jpではメールすら配信しているはずなのに、です。
メールを配信していないシステムではFirefox 2 問題報告センターがあります。こちらを見ると、その返答率の悪さに驚かれるかもしれませんが、こんなものです。間口を広げて報告者にクオリティを要求するのは愚行です。
さらに酷いことに、報告した直後の問いかけの時点でメールの配信に失敗することもあります。アカウント作成用にメールアドレスを作成して、それをすぐに破棄したりしているんでしょう。ここまで行くと問題外ですが、現実にそういうケースがあってる訳です。
おそらくamiさんはこのFirefox 2 問題報告センターのような手軽な報告がしたいんでしょうけど、問題報告センターを見て貰えれれば、そのような形態ではbugzilla本来の目的であるバグのデータベース化には問題があることが分かると思います。も組のフォーラムでもよく、過去ログを検索していないことを批判する人が居ますが、フォーラムはデータベースとしての質が悪いということも考慮すべきです。(実際問題としてそれ以前のケースが多いのは認めますが。)
データベースとしての質を高めようとすると、クオリティの高いコンテンツで構成していく必要がありますが、それは書き込む人間にそのクオリティを要求することに他なりません。クオリティを求めるには有る程度の敷居は必要です。そのバランスは重要ですが、意外と答えは簡単です。開発者の求めるレベルに設定すれば良いんです。何故なら、開発者の処理能力は報告者の報告する物量より絶対に少ないからです。開発者自身が報告者も兼ねているのですから当然です。(もっとバグの少ないシンプルなプロダクトならこの前提は崩れる可能性がありますが、大規模なプロダクトでは間違いなくこうだと思います。)
自分たちさえ良ければ主義
と揶揄されていますが、それはbugzillaをサポートとして見ている証拠ではないでしょうか? 前から何度も書いていますが、bugzillaは開発現場です。その場がオープンになった途端、サポートとして機能しないのはおかしいという発想は間違いであると私は信じています。そして、多くの企業がbugzillaのようなオープンなバグ報告システムを採用しないのは、その誤解を懸念しているということが少なからずあるのではないか、という気がします。
という訳で、新しいバグは一部の「超」固定メンバーですることがお望みらしい！
というのは全面的に否定しておきます。開発現場は純粋にクオリティが低くないバグ報告を望んでいます。バグ報告のクオリティによって処理を選択することはありますが、報告者を見てそれを選択するようなことはありません。
テストケースを作る人が居ない
初回投稿日時: 2007年02月24日06時58分06秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022401
SNS:
(list)
ついでにbugzilla-jpの現状の問題として考えてるポイントを一つ。
私はパッチを書き出す前は報告されたバグのテストケースを作り込んだり、HTML/CSSを個人的にがしがしとコード書きまくってバグを報告したりしていた。(レイアウト/描画のバグ件数が774件で、うち203件が私の報告。意外と割合が高い。もちろんこれはよくない傾向だ。)
で、共に後継者が不在なのであまり問題は表には出ていなかったが、reflowリファクタリングでregressionが多いにも関わらずbugzilla-jpにはほとんどその報告が無いというのは問題だと思う。またあったとしてもそのテストケースを作って再現状況を絞り込む人も居ない。
再現状況を絞り込もうとすると、処理を知らなくても仕様を熟知して、コードの有る程度の設計を推測してバグが発生する条件としない条件の境目を考えなくてはいけない(それを推測できない場合は当たりが付けられない分、テストケースの作成が難しくなる)。また、出来る限り一目で理解可能なシンプルで有用なソースを書くコツがあるのだが、それを掴まなくてはいけない。だが、考えてみればこれって結構特殊な能力かもしれない。だって、そもそもそんな能力、bugzillaでしか役に立たない訳だから。
一応、参考のために作成のコツを列挙しておくと、
- 再現するために必要な要素、プロパティを徹底的に必要最小限まで絞り込む。無駄があればそれは原因推測の邪魔になる。
- ボックスモデルのバグの場合、borderを利用して分かりやすく作る。ボックス毎に色やスタイルを変える等。もちろん、インラインボックスのテストの場合テキストの色を変えるのも手。ただし、目が痛くなるようなきつい配色にはならないようにだけ注意。
- 複数示したい状態がある場合、可能な限りスクロールせずに比較できるようにコンパクトにまとめる。
- テストケースに関する説明を丁寧にする。理想はテストケース内に見出しで入れれること。もしくは、テストの内容によってはボックスのコンテンツとして。また、仕様上どうあるべきかをシンプルに説明する。説明が長い場合は素直にテストケースを添付する際にコメントとして付け加える。
- zip圧縮のようにブラウザから手軽に見ることのできない形式では添付しない。
- コメント欄にソースを貼り付けるというのも駄目。
- とことんシンプルなテストケースで済むならURL欄にdataスキームで書き込むのもアリ。
過去の私の添付したテストケースがこれに従っていないものも多いが、そこはそれ。そういった失敗から学んでのことである。進歩するから黒歴史があるということで。
Bugzilla-jpは回っていない訳ではない
初回投稿日時: 2007年02月24日08時02分26秒
カテゴリ: Bugzilla-jp
固定リンク: id=2007022402
SNS:
(list)
あまり、人手が足りないというような話ばかりしていると外野からbugzilla-jpなんて役にたってないんではないか、なんていう誤解を受けると嫌なのでフォローを。
そもそも、もしbugzilla-jpが役に立っていないなら、私は既に見捨てているだろうし、Mozilla Japan主導で何かやるべきなんだと思う。でもそれをやらないのはbugzilla-jpというコミュニティが機能しているということだ。ここで書いたかどうか忘れたが、Mozilla Japanが出来たときにMozilla Japanでbugzillaを運用すべきかどうかという話があり、そのときに私は必要無いと答えた(当時はMozilla Japanのメンバーでは無かった)。ユーザコミュニティと違って、情報が集約されるべき開発コミュニティの分散は好ましく無いからだ。
私がbugzilla-jpが有用だと考えている点は、開発者に都合の良い日本語で運用されているバグの管理システムが他には無いということだ。英語を読み書きするのはやはりしんどい。相手が日本語の通じない相手だと仕方がないという考え方になるが、相手が日本人だとその労力は無駄でしかない。また、コミュニケーションに失敗する可能性も高くなる。ネイティブな言語で仕事をするのが一番楽なのは確かだ。
それに、私以外にも実際にパッチを書いてくれている日本人とコンタクトがとりやすくなる。本家bugzillaのバグの件数はとにかく尋常ではない。日本人でこっそり活躍されている方がいても、フルタイムで関わっている私すら、まずそれに気づくことは無いだろう。それでは支援も何もあったものではない。バグの内容によってはオール野党な状況下で話をしていかないといけないこともあるからだ(それでいて勝利しなくてはならないことも多い)。
また、パッチを書くレベルになると本家でのレビューの際に英語でのコミュニケーション能力が必要になる。だが、パッチを書く能力と、英語の能力は全く別物なので、共に無い限り開発に参加できないという状況は間口を無駄に狭めてしまうため、良くない。いくつかのバグで実際に行ったように、それを代行することが可能になるという点で、bugzilla-jpというワンクッションは非常に重要だ。
そして日本語で運用されているので、本家とは違うバグで盛り上がったりする。日本語処理固有のバグだったり、日本のメジャーサイトでの問題だったり、民族性の違いだったり、理由は多々あるだろうが、実際にパッチを書く者にとっては修正の優先順位の参考としてこれは非常に重要な情報となる。
最後にそのシステムが非常に良くできているという点。バグを愚痴のように書いているだけのコミュニティがあったとしても、それでは何の役にも立たない。バグの存在を知ることは大切だが、存在だけが分かってもそれを検証したり管理したりする機能が無いとただのノイズでしかない。そういう点でbugzillaは非常に出来がよく、使いやすいシステムである。それを更に優秀な管理者がメンテナンスしてくれているという点も見逃せない。おかげで私は不満を言える立場にあるぐらい、その作業には関わらなくて済んでいる。
もずはっく日記にはコメントもトラックバックも機能を実装していません。スパム対策やるのが面倒なのと、主張したいことがあるならなりすましが容易なコメント欄ではなくblogでも使って主張して欲しいと考えているからです。同様に重要な主張を私は余所のコメント欄で済まそうとは考えていませんのであしからず。それはさておき本題へ。
Bugzilla が開発現場だからといって開発者だけに門を開くというのは何とも誤った論理だと思います。
前提として書いておきますが、先のレスの中で開発者と書いた部分は原則的にbugzilla-jpで検証作業等を行っているテスタの方々も含めてのことです。パッチを書く人だけをbugzillaでの開発者と言うつもりはありません。
私だって開発者ではありません。
ですから、報告に来られた時点で開発者だと考えています。そして開発者には一定のクオリティを要求したい訳です。
重要なことは『「バグと思しき物」を見つけるのは開発者とは限らない』ということです。
おっしゃるとおりです。でもそれは有用な報告がbugzillaを通してあった場合にのみ価値が出てくることです。不満に思った、どこかのフォーラムで愚痴った、bugzillaにクオリティの低い報告をしたために理解してもらえなかった、この状態ではその事実に価値は無い訳です。
Amiさんの理屈だと、その価値が出るように開発者が努力すべきだとおっしゃるようですが、それにあたる私たちの活動は、報告者に対して不明な点を問いかけたりする、という行為がそれにあたると思います。もちろん、それは実行されています。しかし現実問題としてそのような処理を現在報告されている全てのバグにおいて完全に完了できている訳ではありません(UNCOのバグがあるということはそういうことです)。では、これ以上何をすべきでしょうか?
本当に重要なバグを見つけた人までも城の周りのお堀に落としていないか。私は何回か報告ないしコメントしましたけれど毎回、思ってきたことがこれなわけです。
と、理想は高いところを示されています。そんなことは当然分かっています。ですが実行できない理想はただの妄想でしかありません。
それに、私以外の方々はbugzilla-jpでの活動を生業としている訳ではありません。ボランティアとして活動されています。しかし、もっと今以上に努力と呼べる、ユーザへの無償での奉仕活動を行えという要求だと思います。ですが、その発想はbugzilla-jpをサポートとして考えているとしか思えません。開発者はユーザの奴隷ではないのです。
私もMozilla Japanのメンバーになるまではボランティアとしてbugzilla-jpで活動していました。本業の残業で22時、23時に帰ってきて、それから作業を行って寝るという日々を繰り返していましたが、決して楽ではありませんでした。好きでやっていたこととはいえ、その過酷さは身にしみて分かっています。でも好きでやっていたから出来たことだと思います。ですので、ボランティアの方々が自発的にそれを必要だと考え、行動をおこさない限り、誰にもその活動内容が不十分だなどとは言って欲しくはありません。
Bugzilla-jpの運営がベストの状況であるとは私も思いません。問題は多々あるでしょう。しかし、出来ることを可能な限り続けていると思います。もし改善したい点、すべき点があるなら是非中からそれを改善してもらいたいです。それが出来ないというのであれば、自分が出来ないことを他人に押しつけるべきではないと私は思います。