2010年07月15日(木)
<< 前の日記 | 次の日記 >>
これまでの07月15日
編集
■1
続・他のサイトのパスワードを聞き出すことを禁止できないものだろうか[http://www.nantoka.com/~kei/diary/?20100713S2][セキュリティ][mashup]次の記事 >>
Tweet
「さすが電通」と言っても良いだろう。件のサイトの仕様が変更されており、Twitterのホームから直接、書き込む形式になっていた。
当然、パスワードを第三者サイトで入力する必要はないし、このサービスの場合、その場限りの書き込みだから、OAuthよりも好ましいだろう。
この変更によって、第三者サイトでパスワードを入れるのに抵抗があった人も、このサービスが利用できるようになったことだろう。
この方法が、Twitterとハッシュタグを連携したキャンペーンを実装する際のデファクトスタンダードになることを期待する。
■ 関連記事
- 他のサイトのパスワードを聞き出すことを禁止できないものだろうか2010-07-13
- 帰ってきた・他のサイトのパスワードを聞き出すことを禁止できないものだろうか2011-11-24
- 日本レコード協会のフィッシングサイト「LOVE MUSIC」2010-12-24
- ユニクロのフィッシング詐欺風サイトに見る群集心理2010-05-26
- シリーズ武雄市TSUTAYA図書館(13) - Twitter #たけお問題 ハッシュタグについて2013-02-10
- Webサービスの開発者は、「多くの利用者は、どのサービスにもおんなじパスワードを使ってる。」って覚悟をもってなきゃいけないと思う。2010-06-19
- Twitterがクラック2009-12-18
- シリーズ・クロールとDoSの違いと業務妨害罪と(21) - 三菱電機ISが考える「強固なセキュリティ」2010-09-25
- 日本企業初！！フィッシング詐欺対策機能を持ったツールを導入2005-04-07
- 高知県電子申請システムはどうしてアドレスバーを隠すのか2005-02-16
- シリーズ・クロールとDoSの違いと業務妨害罪と(28) - 容易に推測可能なパスワードにリセットし利用者の個人情報を危険に晒す吉田町立図書館2010-11-04
- ウェブアプリ開発の鉄則31カ条2002-12-25
- モバイル機器とパスワード2005-12-06
- 週刊ダイヤモンドにあなたのTwitterアイコンが掲載されます2010-01-08
- エコポイント申請画面が共用SSLサイト上にある件2009-08-27
■2
シリーズ・クロールとDoSの違いと業務妨害罪と(3)[http://www.nantoka.com/~kei/diary/?20100714S1][電子自治体][DoS][mashup][セキュリティ]<< 前の記事
タイトルを付け直そうかと思ったが、まだ続くかも知れないのでシリーズ化することにした。
初出の時に
初出の時に
サーバ側から観測した時に、相手が行っているのが過剰なクロールか、あるいはDoSなのかは、Webサーバのログでも大体見当は付くと書いたが、この点を改めて強調しておきたい。
□ レガシー世界とインターネット:
インターネットでは、専用線接続やクラサバとは根本的に異なり、ネットの向こうには何があるのか分からないというのがスタートラインだ。これは、インターネット全盛の今にあっては当たり前のことだが、レガシー世界からすると、クライアントが何かも分からないというのは確かに別世界だ。
レガシー世界のサーバとクライアントは一対のものとして実装され、お互いの挙動を把握しながら動いていた。
ところが、インターネットの世界では、 RFC[http://ja.wikipedia.org/wiki/Request_for_Comments] で提案されたプロトコルを拠り所に、サーバとクライアントがばらばらに実装される。
プロトコルが決められていると言っても、 全銀協手順[http://ja.wikipedia.org/wiki/%E5%85%A8%E9%8A%80%E5%8D%94%E6%A8%99%E6%BA%96%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB] とか、ISO 8583とか、 CAFIS *1 の様な厳密さは無いし、ましてや接続のための認定等もない。
それでも動いているのは、サーバ - クライアント共に、なるべく広い相手と話せるように努力した結果だし、話せなければそれでも良いという割り切りの結果でもあるだろう。
これだけ別世界だと、レガシー世界の方から、 サービス提供側が意図しない使い方をして被害が生じれば罪になる[http://twitter.com/hatsanhat/status/18574777672] とか、 提供側が意図しない使い方を戒めて欲しい[http://twitter.com/hatsanhat/status/18575234658] といった、インターネット以降の常識からすると、首を傾げるような意見が出てくるのだが、これは、まさに世界観の違いによるものなので仕方がない。
今回の事件が、図書館に置いてある検索端末を意図しない使い方 *2 をして、検索端末が使えなくなったとか、システムが使えなくなったという話であれば、まだレガシー世界の話かも知れないが、 今回はインターネットで起きた話なので、インターネット以降の常識をベースに話を進めたい。レガシー世界の方は、別世界の話にしばしお付き合い頂きたい。
レガシー世界のサーバとクライアントは一対のものとして実装され、お互いの挙動を把握しながら動いていた。
ところが、インターネットの世界では、 RFC[http://ja.wikipedia.org/wiki/Request_for_Comments] で提案されたプロトコルを拠り所に、サーバとクライアントがばらばらに実装される。
プロトコルが決められていると言っても、 全銀協手順[http://ja.wikipedia.org/wiki/%E5%85%A8%E9%8A%80%E5%8D%94%E6%A8%99%E6%BA%96%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB] とか、ISO 8583とか、 CAFIS *1 の様な厳密さは無いし、ましてや接続のための認定等もない。
それでも動いているのは、サーバ - クライアント共に、なるべく広い相手と話せるように努力した結果だし、話せなければそれでも良いという割り切りの結果でもあるだろう。
これだけ別世界だと、レガシー世界の方から、 サービス提供側が意図しない使い方をして被害が生じれば罪になる[http://twitter.com/hatsanhat/status/18574777672] とか、 提供側が意図しない使い方を戒めて欲しい[http://twitter.com/hatsanhat/status/18575234658] といった、インターネット以降の常識からすると、首を傾げるような意見が出てくるのだが、これは、まさに世界観の違いによるものなので仕方がない。
今回の事件が、図書館に置いてある検索端末を意図しない使い方 *2 をして、検索端末が使えなくなったとか、システムが使えなくなったという話であれば、まだレガシー世界の話かも知れないが、 今回はインターネットで起きた話なので、インターネット以降の常識をベースに話を進めたい。レガシー世界の方は、別世界の話にしばしお付き合い頂きたい。
□ サーバが落ちるということ:
サーバにどれだけの能力が要求されるかについては、キャパシティプランニングとして、今も昔も上流工程で検討される事項の一つであろう。
レガシー世界では、キャパシティは絶対のスペックであって、それを超えるとシステムが動作しないというのは、望ましくは無いけれども仕方がない事だった *3 。 万が一、キャパシティをオーバーする可能性が生じたら、利用者に協力してもらって、運用で回避をするしかなかった *4 。
インターネットでは、何しろサービスの利用者はネットの向こうにいるのだから、いつ、どれだけアクセスが来るかは分からない。アクセスが集中して困ったとしても、アクセスをやめてもらう方法も無い。
処理できないほどのアクセスが来たらどうするか。 答えは簡単で、 処理できるようになるまで待ってもらうか、返事をしないか、余裕があればエラーだけ返すかだ *5 。 インターネットでは、できないときはできる範囲でやるというポリシーによって、リソースを有効活用しており、このポリシーがあるからこそ、高速なインターネット接続を、専用線とは比べ物にならないほどの低価格で利用できている。
もしも、年に一度あるかどうかのアクセス集中時にも遅延なくインターネットが使えなければならないとしたら、月額数十万円払って128Kbpsという世界で、多くの人の手元にインターネットは届いていないに違いない。 できないことはできる範囲でやる、ベストエフォートというポリシーがネットの低価格化と普及を実現し、今日のインターネットの隆盛がある。
サーバについても同様だ。 インターネットに対してサービスを提供する以上、処理能力を超えたアクセスの集中は必ず起こるとして、処理できないアクセスが来たら、待ってもらうか、返事をしないか、エラーを返し続けて、アクセスの集中が去れば定常状態に回復するというのが、インターネットに接続されるサーバとしての要件だ。
遅くなっても、返事をしなくなっても、それは処理能力の一時的な低下であり、それは「落ちた」とは言わない。一方、アクセス集中という原因が取り除かれても、なお復旧しない様な障害が発生した時に「サーバが落ちた」と言う。
今回のケースについては、報道等を通じて見る限りでは「サーバが落ちた」と言うのは事実のようだが、これまで述べたように、 アクセス集中によってサーバが落ちるのは、インターネットに向けてサービスを提供するサーバとしての要件を欠いている と言わざるを得ない。
レガシー世界では、キャパシティは絶対のスペックであって、それを超えるとシステムが動作しないというのは、望ましくは無いけれども仕方がない事だった *3 。 万が一、キャパシティをオーバーする可能性が生じたら、利用者に協力してもらって、運用で回避をするしかなかった *4 。
インターネットでは、何しろサービスの利用者はネットの向こうにいるのだから、いつ、どれだけアクセスが来るかは分からない。アクセスが集中して困ったとしても、アクセスをやめてもらう方法も無い。
処理できないほどのアクセスが来たらどうするか。 答えは簡単で、 処理できるようになるまで待ってもらうか、返事をしないか、余裕があればエラーだけ返すかだ *5 。 インターネットでは、できないときはできる範囲でやるというポリシーによって、リソースを有効活用しており、このポリシーがあるからこそ、高速なインターネット接続を、専用線とは比べ物にならないほどの低価格で利用できている。
もしも、年に一度あるかどうかのアクセス集中時にも遅延なくインターネットが使えなければならないとしたら、月額数十万円払って128Kbpsという世界で、多くの人の手元にインターネットは届いていないに違いない。 できないことはできる範囲でやる、ベストエフォートというポリシーがネットの低価格化と普及を実現し、今日のインターネットの隆盛がある。
サーバについても同様だ。 インターネットに対してサービスを提供する以上、処理能力を超えたアクセスの集中は必ず起こるとして、処理できないアクセスが来たら、待ってもらうか、返事をしないか、エラーを返し続けて、アクセスの集中が去れば定常状態に回復するというのが、インターネットに接続されるサーバとしての要件だ。
遅くなっても、返事をしなくなっても、それは処理能力の一時的な低下であり、それは「落ちた」とは言わない。一方、アクセス集中という原因が取り除かれても、なお復旧しない様な障害が発生した時に「サーバが落ちた」と言う。
今回のケースについては、報道等を通じて見る限りでは「サーバが落ちた」と言うのは事実のようだが、これまで述べたように、 アクセス集中によってサーバが落ちるのは、インターネットに向けてサービスを提供するサーバとしての要件を欠いている と言わざるを得ない。
□ ブラウザとクローラとヒトとロボットとネコ:
「Webサービスとは何か」と突き詰めて行くと、究極的には「HTTPサービスです」ということになる。「Webサーバ＝HTTPサーバ」と言い直せるくらいだ。
HTTPサービスを利用するためのプログラムは、「HTTPクライアント」で、ブラウザもクローラも、HTTPクライアントであるという点に違いは無い。
当然、HTTPサービスを提供する側から見ても、HTTPクライアントである点に違いは無い。
一方、HTTPクライアントを使って、サービスを受けているのが、ヒトかロボットかネコかということも、HTTPサービスを提供からする側から見れば、みな「HTTPサービス」を受けているという点で等価だ。なおこのネコは後に重要な役目を帯びて再登場する。
サーバが提供するのは「HTTPサービス」であって、「IEサービス」でも「FireFoxサービス」でも無い。HTTPサービスを提供するということは、HTTPクライアント向けのサービスを提供するということであって、その中には、行儀が良いのも悪いのも *6 、実装にバグがあるものも、標準と違う動きをするものもあるけれど、そういう多様なクライアントからアクセスされるのが、インターネット上のサーバだ。
もちろん、一つ一つのクライアントに合わせてサーバを実装するわけではないし、そんなことができるはずもない *7 。サーバは、ただHTTPサービスを提供すれば良い。
この様に、通信プロトコルとユーザーインターフェイス等の表現を分離したところも、Webが広く普及した理由の一つであると考えられるが、とにかく、ここで理解して頂きたいのは、 Webサーバ(=HTTPサーバ)は、HTTPサービスを提供するサーバである ということに尽きる。
従って、 Webサービス(=HTTPサービス)を提供することは、HTTPサービスを提供すること になる。
そもそも「HTTPサービス」を提供しているのだから、HTTPクライアントからアクセスされることが想定されていて、 同じHTTPクライアントである、ブラウザとクローラを分けて考えることには無理がある。 この問題には、ヒトとロボットを判断する際にも直面して、その技術的な解決の一つとして CAPTCHA[http://ja.wikipedia.org/wiki/CAPTCHA] が使われているが、これも前述したように、ブラウザとクローラを判断するのが難しいからこそ利用されている技術である。
HTTPサービスを利用するためのプログラムは、「HTTPクライアント」で、ブラウザもクローラも、HTTPクライアントであるという点に違いは無い。
当然、HTTPサービスを提供する側から見ても、HTTPクライアントである点に違いは無い。
一方、HTTPクライアントを使って、サービスを受けているのが、ヒトかロボットかネコかということも、HTTPサービスを提供からする側から見れば、みな「HTTPサービス」を受けているという点で等価だ。なおこのネコは後に重要な役目を帯びて再登場する。
サーバが提供するのは「HTTPサービス」であって、「IEサービス」でも「FireFoxサービス」でも無い。HTTPサービスを提供するということは、HTTPクライアント向けのサービスを提供するということであって、その中には、行儀が良いのも悪いのも *6 、実装にバグがあるものも、標準と違う動きをするものもあるけれど、そういう多様なクライアントからアクセスされるのが、インターネット上のサーバだ。
もちろん、一つ一つのクライアントに合わせてサーバを実装するわけではないし、そんなことができるはずもない *7 。サーバは、ただHTTPサービスを提供すれば良い。
この様に、通信プロトコルとユーザーインターフェイス等の表現を分離したところも、Webが広く普及した理由の一つであると考えられるが、とにかく、ここで理解して頂きたいのは、 Webサーバ(=HTTPサーバ)は、HTTPサービスを提供するサーバである ということに尽きる。
従って、 Webサービス(=HTTPサービス)を提供することは、HTTPサービスを提供すること になる。
そもそも「HTTPサービス」を提供しているのだから、HTTPクライアントからアクセスされることが想定されていて、 同じHTTPクライアントである、ブラウザとクローラを分けて考えることには無理がある。 この問題には、ヒトとロボットを判断する際にも直面して、その技術的な解決の一つとして CAPTCHA[http://ja.wikipedia.org/wiki/CAPTCHA] が使われているが、これも前述したように、ブラウザとクローラを判断するのが難しいからこそ利用されている技術である。
□ アクセスとアタックと:
原点に帰ろう。「ブラウザかクローラか」は、実はどうでも良い問題で、
焦点は「アクセスかアタックか」だったはずだ。
アクセスなのかアタックなのかはサーバ側で見当が付く[http://www.nantoka.com/~kei/diary/?20100624S1] という趣旨のことを書いたが、ここをもう少し詳しく書いてみたい。
パターンとしては、大まかに次のパターンが考えられる。
実際に問題になるのは、3,4と5,6を分離することだろう。 どこに違いが生じるかと言えば、 リクエストしたデータを利用しているかどうか だ。
例えば、常識的に更新頻度が高いことが想定されない同じページを、ノーウェイトで取得していれば、これは怪しいと見ていいだろう *9 。
クローラの場合、リクエストしてくるURLが異なると判別が難しいかも知れないが、クライアントまでのRTT *10 を得て、ローカルで同じページをアクセスした時に掛かる時間と足せば、クライアントからWebページを取得したときの大まかなRTTが分かる。これより長い間隔でのアクセスであれば、迷惑ではあるかも知れないが、恐らく意図はクロールだと判断できる。
今回のケースは恐らくこのパターンだったはずで、この程度の検証もしないで攻撃だと判断したのも、それを鵜呑みにして逮捕したのもあまりにも杜撰だ。
一方、これより短い間隔でアクセスしてくるとしたら、複数プロセスあるいはスレッドを使っているか、バグっているか、アタックしようとしているかだろう。サーバの応答時間を長くして、リクエスト数が変わらない様だったら、怪しいと見て良いだろう。
怪しいケースについては、あくまで「怪しい」であって、これが直ちにアタックの証拠になるものでは無い。バグによるものだったかも知れないし、「ブラウザでF5アタック」と思ったら、キーボードの上にネコが寝ていただけかも知れない。
IPアドレスやUserAgentで弾くことができないような形で続く様だったら、アタックと見なすことになるかも知れない。
なお、専用の攻撃ツールを使うと、効率的にアタックできる分、アタックとしか考えられない挙動を示すので、この場合は一回でアタックだと判断できるだろう。
アクセスなのかアタックなのかはサーバ側で見当が付く[http://www.nantoka.com/~kei/diary/?20100624S1] という趣旨のことを書いたが、ここをもう少し詳しく書いてみたい。
パターンとしては、大まかに次のパターンが考えられる。
- ブラウザによる通常のアクセス
- クローラによる目立たないアクセス
- ブラウザによる過激なアクセス(だが、DoSではない)
- クローラによる過激なアクセス(だが、DoSではない)
- ブラウザによるDoSを意図したアクセス
- クローラによるDoSを意図したアクセス
実際に問題になるのは、3,4と5,6を分離することだろう。 どこに違いが生じるかと言えば、 リクエストしたデータを利用しているかどうか だ。
例えば、常識的に更新頻度が高いことが想定されない同じページを、ノーウェイトで取得していれば、これは怪しいと見ていいだろう *9 。
クローラの場合、リクエストしてくるURLが異なると判別が難しいかも知れないが、クライアントまでのRTT *10 を得て、ローカルで同じページをアクセスした時に掛かる時間と足せば、クライアントからWebページを取得したときの大まかなRTTが分かる。これより長い間隔でのアクセスであれば、迷惑ではあるかも知れないが、恐らく意図はクロールだと判断できる。
今回のケースは恐らくこのパターンだったはずで、この程度の検証もしないで攻撃だと判断したのも、それを鵜呑みにして逮捕したのもあまりにも杜撰だ。
一方、これより短い間隔でアクセスしてくるとしたら、複数プロセスあるいはスレッドを使っているか、バグっているか、アタックしようとしているかだろう。サーバの応答時間を長くして、リクエスト数が変わらない様だったら、怪しいと見て良いだろう。
怪しいケースについては、あくまで「怪しい」であって、これが直ちにアタックの証拠になるものでは無い。バグによるものだったかも知れないし、「ブラウザでF5アタック」と思ったら、キーボードの上にネコが寝ていただけかも知れない。
IPアドレスやUserAgentで弾くことができないような形で続く様だったら、アタックと見なすことになるかも知れない。
なお、専用の攻撃ツールを使うと、効率的にアタックできる分、アタックとしか考えられない挙動を示すので、この場合は一回でアタックだと判断できるだろう。
*1: (7月24日)PIAFSとtypoしていたのを修正。
*2: 勝手にプログラムをインストールしたとか、設定を変えたとか。
*3: 例えば、夜間バッチ処理は、翌朝の業務開始までには絶対に完了していなければいけないだろう。
*4: 極端な例を取り上げております。
*5: HTTP Error 500のInternal Server Errorだが、文字通り、内部で何らかのエラー(リソースの不足、あるはずのファイルが見つからない、内部矛盾)を検出して、詳細は伝えない(攻撃に悪用される恐れがあるから、クライアントにはあえて詳細な原因を通知しないことが多い。)ながら、エラーが発生したという事実を正しく応答している。あくまで、クライアントに向けて、期待した応答が返せない理由として通知する「エラーコード」であって、サーバの管理者に対してのエラーでは無い。致命的な障害をクライアントに通知したからと言って、クライアントにはサーバを救う手だては無い。
*6: クローラが行儀が悪い訳ではない。ブラウザが行儀が良い訳でもない。無関係に、行儀が良いのも悪いのも存在する。
*7: 細かく言えば、ブラウザ向けに最適化することはあるが、本筋ではないので割愛。
*8: 不能犯になりそうでもあるし。
*9: 一方、ある時刻に予約の受付開始を行うようなサイトでは、リロードを繰り返すのは、当然、想定される操作だろう。
*10: 目安であるから、tracerouteして、クライアントよりいくつか手前でも構わない。
*2: 勝手にプログラムをインストールしたとか、設定を変えたとか。
*3: 例えば、夜間バッチ処理は、翌朝の業務開始までには絶対に完了していなければいけないだろう。
*4: 極端な例を取り上げております。
*5: HTTP Error 500のInternal Server Errorだが、文字通り、内部で何らかのエラー(リソースの不足、あるはずのファイルが見つからない、内部矛盾)を検出して、詳細は伝えない(攻撃に悪用される恐れがあるから、クライアントにはあえて詳細な原因を通知しないことが多い。)ながら、エラーが発生したという事実を正しく応答している。あくまで、クライアントに向けて、期待した応答が返せない理由として通知する「エラーコード」であって、サーバの管理者に対してのエラーでは無い。致命的な障害をクライアントに通知したからと言って、クライアントにはサーバを救う手だては無い。
*6: クローラが行儀が悪い訳ではない。ブラウザが行儀が良い訳でもない。無関係に、行儀が良いのも悪いのも存在する。
*7: 細かく言えば、ブラウザ向けに最適化することはあるが、本筋ではないので割愛。
*8: 不能犯になりそうでもあるし。
*9: 一方、ある時刻に予約の受付開始を行うようなサイトでは、リロードを繰り返すのは、当然、想定される操作だろう。
*10: 目安であるから、tracerouteして、クライアントよりいくつか手前でも構わない。
■ 関連記事
- 続・クロールとDoSの違いと業務妨害罪と2010-07-14
- クロールとDoSの違いと業務妨害罪と2010-06-24
- 岡崎市立中央図書館事件に関する本日誌の記事一覧2010-08-17
- シリーズ・クロールとDoSの違いと業務妨害罪と(4)2010-07-18
- レガシー脳の恐怖2010-07-16
- 大学からのアタックの話1998-10-21
- シリーズ・クロールとDoSの違いと業務妨害罪と(6) - レガシーの呪縛2010-07-23
- 同種生物をペットとすることは倫理的に許されるのか2005-05-08
- HTTPS でアクセス可能なページは、HTTP でのアクセスを提供しないことが望ましい？2010-03-13
- 連休中のアタック2000-04-30
- ＜資生堂＞ＨＰに「薄毛は子孫も迷惑」 抗議殺到、おわび2005-05-12
- もぐらプロジェクト2004-12-25
- セキュリティに敏感な組織ほど・・・1998-11-05
- しまじろう自体トラなんだかネコなんだかよくわからない2005-05-14
- 某プロバイダからのアタック(1)1998-10-19
■今日のつぶやき
- そういえば、ホメオパシーに保険適用って話があったな。プロジェクトチームどうなったんだろう。 http://www.zakzak.co.jp/society/politics/news/20100215/plt1002151633004-n2.htm2010-07-15 01:51:14 Tweenで
- Browsing: 厚生労働省統合医療プロジェクトチーム資料 http://bit.ly/aGPCNe http://bit.ly/cuzg8k2010-07-15 01:53:32 Tweenで
- あるあるｗ - ツイッターなど、イタいセルフブランディングから脱却せよ！「当たり前」の積み重ねが差別化を生む http://bit.ly/cIcgwi2010-07-15 08:07:14 Tweenで
- Browsing: 情報ネットワーク法学会 - 第１回「技術屋と法律屋の座談会」 テーマ：岡崎市立中央図書館へのアクセスはDoS攻撃だったか？ http://bit.ly/9j0BYH #Librahack2010-07-15 12:44:10 Tweenで
- @minemaz @kazkun CAL周りはライセンス担当も間違うとMSのヒトが言ってたくらいですから、複雑怪奇。でも、IISを(Windows認証を使わずに)普通にインターネットサーバとして使うケースにはCAL要らないはず。2010-07-15 13:49:54 Tweenで minemaz宛て
- @gutei その論理に乗るのは危険だと思いますよ。Webを通じてサービスを提供する以上、提供側が受容しないといけないことがあるはずで、クロールも受容しなければならないのではないでしょうか。宅配業者も「善意」で提供しているのではなく、Webを使うメリットを享受している筈です。2010-07-15 14:01:00 Tweenで gutei宛て
- @gutei 「税金を払っているからOK」という主張に見えてしまう気がしたのでコメントしました。「税金を払っていない他の自治体にやったらNGだ」と主張しているとか曲解して言い出す人が出てきかねないので。2010-07-15 14:10:15 Tweenで gutei宛て
- 例えば、文庫本の切り取った表紙と100円を送ると電子版がダウンロードできるとか、雑誌を定期購読すると電子版もダウンロードできるとか、電子版の割引チケットが閉じこまれているとか、vsではなくてwithのビジネスがたくさん出てくるとうれしい。2010-07-15 14:17:43 Tweenで
- @hatsanhat なぜ「100人が同じスクリプトを流せば落ちる事は自明」なのですか？1人が流して落ちたからですか？では、落ちる前は落ちるかどうか分からないということですよね。 #librahack2010-07-15 15:01:32 Tweenで hatsanhat宛て
- @mitsugu_oyama 「以下に掲げるブラウザ以外の使用、ブラウザ設定を標準状態から変更してのアクセス、プラグイン等の利用を禁止します」ってテンプレ書くだけで良いですね！ #librahack2010-07-15 15:05:19 Tweenで mitsugu_oyama宛て
- ブラウザ技術適合認定試験制度を作って、技適を通ったブラウザでしか官公庁や自治体のサイトに接続できない様にして、ブラウザを改造する行為を違法化したら良いねという話になってる？ #librahack2010-07-15 15:10:46 Tweenで
- @mitsugu_oyama その紳士協定なるものは、無断リンク禁止教の新宗派を生みませんか？2010-07-15 15:19:47 Tweenで mitsugu_oyama宛て
- @mitsugu_oyama それなら分かります。API公開はまさにその方向で、規約を守らない場合にペナルティを与える方法もあります。ただ全てのサービスにAPIの提供を求めるのは不可能なので、その溝をクロールやスクレイピングで埋めているのが今の状況ですよね。 #librahack2010-07-15 15:23:00 Tweenで mitsugu_oyama宛て
- 紳士協定と言えば、robots.txtがあるのだけど、あれはロボットにとって立ち入り禁止の柵を作るというより、道案内を立てている感じ。ここから先に行くと、無限に動的リンクが生成されていますよ、みたいな。本当に立ち入り禁止にしたければ弾くわけで。 #librahack2010-07-15 15:33:09 Tweenで
- @tanayuki @yasunori_sugii @ennuihage @hastorang @mao3mao3 「超流通」という懐かしいキーワードが！2010-07-15 15:35:10 Tweenで tanayuki宛て
- 画期的なコンテンツ配布方法を思いついた気がしたのだけど、つぶやいて公知になる前に、念のため先行技術調査をしてみることにするなど。2010-07-15 15:40:19 Tweenで
- @yao_yokagoto @nekonyauri 昔は薬を他人に勧める困った素人がいて、本物の薬よりは、それこそ毒にも薬にもならないので安全ということでレメディーが流行ったそうなのですが、どこかから、レメディーだけで治すべきだと変な方向に発展してしまったのでしょうね。2010-07-15 15:56:58 Tweenで yao_yokagoto宛て
- @yao_yokagoto @nekonyauri お祈りやお参りが受験勉強の代わりにはならない感じで。2010-07-15 16:07:08 Tweenで yao_yokagoto宛て
- どっかのベンダーがインターネットを作っているという、すんごいレガシーな妄想を読んだ気がした。気のせい。気のせい。 #librahack2010-07-15 17:02:05 Tweenで
- どっかのベンダーがインターネットを作っているという、すんごいレガシーな妄言を読んだ気がした。気のせい。気のせい。 #librahack2010-07-15 17:03:56 Tweenで
- インターネットでは、ネットの向こうには何があるか分からないのがスタートライン。クラサバとは違うのだよ！クラサバとは！ #Librahack2010-07-15 18:33:13 Tweenで
- ネットの向こうからアクセスして来ているのが、ブラウザなのかクローラーなのか、操作しているのがヒトなのかロボットなのかを判断したり規定したりしようとするから話がおかしくなって、DoSなのかそうでないのかを判断するべき。 #Librahack2010-07-15 18:37:47 Tweenで
- @hatsanhat 落ちるか落ちないかを知ることは、実際には不可能だと思うのです。経験上は、動的ページであってもこの程度のアクセスでサーバが落ちることはまずありません。遅くなるかエラーを返し始めるかです。なぜ「自明」とされたのかをお伺いしたかったのです。 #Librahack2010-07-15 19:10:14 Tweenで hatsanhat宛て
- @hatsanhat そのISPでは、負荷が高くなるとInternal Server Errorを返すようなシステムを構築されていたのですね。そして、それを無視してアクセスを続けるとサーバが落ちると。2010-07-15 20:56:55 Tweenで hatsanhat宛て
- @hatsanhat だとすると、そのシステムは「インターネット向け」のシステムでは無いと思うのですが、インターネット向けのシステムだったのでしょうか。2010-07-15 21:00:16 Tweenで hatsanhat宛て
- 500もらったら、パラメータに起因するエラーとみて飛ばして次でしょうね。いずれにしても、500って言う応答を正しく返してくるのだから、サーバが落ちることになると判断するのは難しいでしょう。 #Librahack2010-07-15 21:07:17 Tweenで
- ひょっとして、「Internal Server Errorを発生させた＝業務妨害。何度もやったんだから悪質に決まっている。」という論理の人が他にもいないだろうなぁ。心配になってきた。 #Librahack2010-07-15 21:40:06 Tweenで
- 思いがけない人からプレゼンの極意を学んだ。「１）押し付けは良くない。事前の関係構築が大事。２）与えたいものではなく、相手が求めるものを。３）後味良く。負担ではなく感動を。」良く聞いたら、プレゼントの極意だったけども。2010-07-15 21:46:24 Tweenで
- @hatsanhat 「裁判になったら無罪になる」という判断なのに、「起訴されるはず」なのは矛盾していませんか？ #Librahack2010-07-15 23:23:56 Tweenで hatsanhat宛て
- @hatsanhat もう一点。「サービス提供者の意図しない利用方法」とありますが、利用者としては、「Webサーバとして公開されているのだから、HTTPでアクセスされることを意図しているのだろう」と言うこと以上は、通常、知りえないのではないですか。 #LifeHack2010-07-15 23:29:27 Tweenで hatsanhat宛て
- 興味深い「WEBシステムの流行が続いていますが、操作性はC/S型に分があることは確実」「通信負荷もサーバ負荷も大きいWEBにこだわる理由が本当にありますか？」「あるソフト会社が、これらを解決するフレームワークを持っています」 http://bit.ly/9tBnxM2010-07-15 23:38:13 Tweenで
