■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

【2ちゃんねるビューア】 巡回機能の巻。Part3

789 :名無しさん@お腹いっぱい。 :02/03/26 23:02 ID:???
>>784
影響があったが、バージョンアップにて対応可能なもの: (追加
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

あと、Mac用ツールはどうなってんだろう、
・iTteyoshi
・マクモエ
・Ahyazilla
・Fuuun
・CocoMonar

790 :Dream ★ :02/03/26 23:02 ID:???
ていうか、サイト設計として、datやsubject.txtやSETTING.TXTっていうものは、
一般ユーザが容易に接触できるところにおいてあるべきものかという話も、
どこかにあってしかるべきじゃないでしょうか?

これは、純粋に私の私感なんですけどね。

791 :名無しさん@お腹いっぱい。 :02/03/26 23:02 ID:???
想定する近未来:
・「串制限中」などと同じように「ツール制限中」などの言葉が普通に使われるようになる。
・●持ちの人は、串制限が緩和されるように、ツール制限も緩和される。
・「2ちゃんねるを便利に見たい場合はコレ!」「混雑時間帯でもスイスイ巡回。面倒な操作は不要」

792 :Dream ★ :02/03/26 23:03 ID:???
>>789
ありがとうございますです

793 :西安(UCK 1.3.2) ◆CYANh33g :02/03/26 23:03 ID:???
>>790
腹が腹痛、私の私感(ぼそっ

794 :西安(UCK 1.3.2) ◆CYANh33g :02/03/26 23:04 ID:???
>>791
ガクガク(((((((( ;゚Д゚)))))))ブルブル

795 :Dream ★ :02/03/26 23:05 ID:???
>>791さんは、転送量の問題と、サーバの負荷の問題は、
どうやって解決するべきだと思ってらっしゃいますか?

796 :疑問 :02/03/26 23:06 ID:???
>>776
鯖の負荷を低く抑えるためには、やたらめったら巡回する人たちを
どうにかするのが近道なんじゃないの?

まあいいや、みんなあんまり興味ないみたいだから
この話はやめる お邪魔さま


797 :Dream ★ :02/03/26 23:07 ID:???
この変更によって影響がでる可能性のあるツールは、以下の通り
現在も影響があるツール:

●MapleSyrup Ver.0.05g (read.cgiを使っているためレス取得不可)
●Gickoブラウザ改良版 スレリスト取得不可(read.cgi使用)

影響があったが、バージョンアップにて対応可能なツール:

●A Bone Ver.1.23 (V1.23bで対応)
●かちゅ〜しゃ+kage (Ver.0.99.1.2で対応済)
●ホットゾヌVer.1.0 β2.1.4以下でスレリストを取得できない (β2.1.5で対応済)
●えまのん (3/24版で暫定対応、ただし差分DAT転送に対応していないので要注意)
●マカー用。エレメンツ (Ver0.992β で暫定対応)
●jane 低速回線・ダイアルアップ設定でレス取得不可 (高速回線設定に変更すればok)
●navi2ch (read.cgiを使わない設定にすればok)
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

なお、この負荷低減実験は、今後順次、ほかのサーバに拡大していく予定。

※上記以外のツールの情報をお持ちの方は、
 【2ちゃんねるビューア】 巡回機能の巻。Part3
 http://pc.2ch.net/test/read.cgi/software/1016905060/l50
までお知らせ下さい。


798 :名無しさん@お腹いっぱい。 :02/03/26 23:08 ID:???
日本国全てで常時接続が実現してないのが現況のようなので。

799 :名無しさん@お腹いっぱい。 :02/03/26 23:13 ID:???
規制して数を減らす、という政治的な話ばっかりだな。
httpd.conf触らしてもらえるようにするとか、そっちの話のほうが
てっとりばやくて効果絶大なんだけど、それは
政治的な話なのかい?それとも技術的な話なのかい?

800 :791 :02/03/26 23:14 ID:???
>>795
巡回・更新チェックといった見方ではなく、ツールによるDATへのアクセスを
一旦すべて遮断した上で、●持ちの優遇策を取る。

●持ちの人の絶対数は将来に渡っても○の人より少ないわけだから、
read.cgiでsidを判定した上でのDAT転送といった、重めの処理も許容できると考える。

ここでのポイントは、すべて鯖側でアクセス可否が判断されるということ。
UAを偽装しようが、クライアントのソースを書き換えようが、有償ID/PASSを
盗まない限りはどうしようも無い。

また、一律全サーバ・全時間帯で同じ仕様にするわけではなく、時間帯ごと・鯖ごとに
制限をかけわけることで、ある程度リソース(この場合DAT)をフリーで解放する。

つまり、実況版は別に見ないから無料ユーザのままでいいや、みたいな逃げ道を
確保しておくことで「運営側からの強い圧力」といった印象を抑える心理的効果も期待する。
(この場合の対象はツールユーザ・ツール作者・クラッカー)

801 : ◆JOKESIZE @JOKESIZE ★ :02/03/26 23:14 ID:???
>>791
串無しでIEを使ってる人(想定している通常ユーザ)
は何の変化もないでしょうね。

802 :Dream ★ :02/03/26 23:17 ID:???
>>799
がいしゅつです

803 :名無しさん@お腹いっぱい。 :02/03/26 23:19 ID:???
>>799
 >>308 >>314

804 :Dream ★ :02/03/26 23:20 ID:???
>>803
Thx!

805 :名無しさん@お腹いっぱい。 :02/03/26 23:30 ID:???
Dreamさんにsubjext.txtを隠すことの利点を解説して欲しい人の数→(1001)


806 :名無しさん@お腹いっぱい。 :02/03/26 23:34 ID:???
>>805 夜勤さんに聞くのが筋と思われ。
 もっとも答えない気がする。

807 :名無しさん@お腹いっぱい。 :02/03/26 23:36 ID:???
>>803
そうでしたか。
今議論されてるレベルなら、どうころんでも規制をすり抜けられます。
結局性善説の上での話ですから。
性悪説で話を進めるならサーバ側での対処が必要なのに・・・

これじゃなにゆってもだめぽ

808 :名無しさん@お腹いっぱい。 :02/03/26 23:38 ID:???
>>807のラインでいくと、性悪というより最早敵対視してると思われ。

809 :名無しさん@お腹いっぱい。 :02/03/26 23:42 ID:???
逆にいえば、今の話がまとまってほしいとも思う。
だって規制が無いようなもんだからね。

810 :名無しさん@お腹いっぱい。 :02/03/26 23:44 ID:???
>>793
気分転換に煽っていい?
「彼の私感」という言葉も存在するので、「私の私感」というのはおかしくない。
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%8E%84%8A%B4&sw=2

811 :Dream ★ :02/03/26 23:48 ID:???
>>805
こまったなぁ。
ある程度、このスレと、批判要望の方の発言読めば、夜勤さんとトオルさんとひろゆ子さんが
隠したがっているという意向が伺えると思う。
だから盲目的に「隠そうよ」っていうわけじゃないけど、
一つは、イリーガルなツールに、ある程度責任を負わせられるって事。
二つ目は、Monazillaつーる(便宜的にたとえているだけですけど)みたいな、
2ちゃんの負荷とかの事を考えて下さる作者さんのグループに、
認証手順とかを提供することで、ほかのツールとの差を発生させることが出来て、
その差の部分で、そうじゃないツールと、サーバ的に区別する手段が
得られるような方策が将来的に取れるか、ということ。

ここまで書いて思ったんだけど、どうして、subject.txtが隠れてしまうことに
拘泥するのでしょうか?拘泥する必要がないと思うのですけれど。
Webでも、ツールでも、通常使用の範囲では今まで通り提供されるのに。

812 :名無しさん@お腹いっぱい。 :02/03/26 23:49 ID:???
>800
dat遮断したらread.cgiへのアクセスが集中して全鯖即死です。


813 :西安(UCK 1.3.2) ◆CYANh33g :02/03/26 23:49 ID:???
>>810
また一つ賢くなったよ。
ありがとう。

814 :Dream ★ :02/03/26 23:51 ID:???
>>812
そうなるのかなぁ。
read.cgiへの呼び出しは、localhostからのもの以外弾いてみたらどうでしょう?

815 :名無しさん@お腹いっぱい。 :02/03/26 23:52 ID:???
別に「フツーのユーザー」(←大事)が困らないんだったら隠しちゃえ、隠しちゃえw

816 :西安(UCK 1.3.2) ◆CYANh33g :02/03/26 23:52 ID:???
>>811
現状では私もある種非Monazillaツール扱いなのよね(^^;
(すでに monzilla.org で紹介されてはいるが)
開発始めるにあたって隠れてたらやる気なくしただろうねえ。
まあ、そこらへんは感情論であって、正規の手段で取得できるなら問題はないかな。

817 :名無しさん@お腹いっぱい。 :02/03/26 23:52 ID:???
>811
subject.txt隠したら負荷が増大するだけで軽減にはならない。
subject.txtを隠す云々は荒らし対策なだけで、今回の件とは関係無い。

818 :名無しさん@お腹いっぱい。 :02/03/26 23:56 ID:???
>>812
現在呼び出しの50%以上を占めるというツールユーザが全員
負荷の軽いdat読みをやめてIEなどのブラウザでread.cgiを呼ぶことになるわけだからなぁ。

819 :名無しさん@お腹いっぱい。 :02/03/26 23:58 ID:???
>>816
そうなんだよね、結局、monazillaツールって何?ってなっちゃう
んだよね。
別に2chがライセンスしてるわけじゃないし、著作権持っている
わけじゃないんだよ。
そういうのに乗っかって規制する事が出来るのかと言うと、不
可能とは言わないけど、かなり難しいんだよね。

820 :名無しさん@お腹いっぱい。 :02/03/26 23:58 ID:???
>>818
ぎゃー

821 :名無しさん@お腹いっぱい。 :02/03/26 23:58 ID:???
>>812
だから全鯖にはせずに一部の鯖・一部の時間帯だけにする。
read.cgi HTMLパースするツールが現れたら作者に警告する。

822 :Dream ★ :02/03/26 23:59 ID:???
>>817
その積算根拠があるとうれしいんですよ。

823 :名無しさん@お腹いっぱい。 :02/03/26 23:59 ID:???
>>821
作者がソースを垂れ流して改造版が出回ったら?

824 :名無しさん@お腹いっぱい。 :02/03/27 00:00 ID:???
>811
とりあえず、gikozillaプロジェクトの発足と
その現状については関知している?
#今はgikozillaもたいがい氏んでるけどな。

825 :Dream ★ :02/03/27 00:02 ID:???
>>819
いえね、そういう意味では、いわゆる2ちゃんねる側の人たち、
夜勤さんとかひろゆきとか、トオルさんもかも知れないけど、
気を使っていると思いますけどね。
ただ、サーバが破綻している現状があって、この現状をおかしい、
って思わない人がいるんならしょうがないでしょうけど、
おかしい、とおもって、協力しよう、って思う人がいたら、
単純に私は可能だと思いますけどね。
●機能の実装だって、そういう経緯でされたんじゃないんですか?

826 :Dream ★ :02/03/27 00:02 ID:???
>>824
不勉強ですいませんです。

827 :Dream ★ :02/03/27 00:03 ID:???
>>816
ちょっと、その辺は私の感知できる部分ではないし、
私自身Monazilla不参加なので、まずいっすかねぇ?参加しないと・・・
どうなんでしょ?

828 :名無しさん@お腹いっぱい。 :02/03/27 00:03 ID:???
>>819
現時点でのmonazillaツールの定義は「有償IDの認証機能を備えている2chブラウザ」
だと思われ

そして有償IDはクライアントの特定や制限に利用できる有効な手段と思う

829 :名無しさん@お腹いっぱい。 :02/03/27 00:04 ID:o8ZVbcMf
subject.txtのアクセスに、なんらかのパスワードが必要なようにしておけば、
それを正規に得ていないツール/会社からのアクセスを「不正アクセス」と
して、罪に問うことができますね。
管理者がパスワードを「みだりに知らせてはならない」としておけば、あとは
実際にその機密性が保たれているかどうかは問題ではない。

日本の法律が、米国に所在する2chのサーバに適用されればですけど。

830 :名無しさん@お腹いっぱい。 :02/03/27 00:05 ID:???
一番簡単なのは、2chが自分の責任でツールを提供する事なんだけど
(monazillaのツール作者にお任せでなく)
でも、現状ではそこまで出来ない。
結局、ツールで規制する事には限界がある(溜息

831 :Dream ★ :02/03/27 00:06 ID:???
単純明快に
「subject.txtもdatも基本認証の中に隠しちゃえ」
みたいなことが言えるのは、私がニュートラルな場所にいるからだと思ってるんですけどね。
夜勤さんは、このスレッドのどこかで、
「私からそういうことを言えた義理はないです」みたいな事いってましたし。
「管理者以外の人間が批判されたりしませんか?」って気を使ってましたし。

832 :名無しさん@お腹いっぱい。 :02/03/27 00:06 ID:???
>>829
だからsubback.html(またはそれに相当するもの)を使うだけだってのに..

833 :Dream ★ :02/03/27 00:07 ID:???
>>829
運用会社が日本にあるのだから、専管裁判所は札幌地裁になるんじゃないっすか?

834 :Dream ★ :02/03/27 00:07 ID:???
>>832
この話回ってますね、四週目くらいです

835 :Dream ★ :02/03/27 00:08 ID:???
>>832
subback.htmlにアクセスしてきたIPを弾く機能って、実装難しいですかねぇ?

836 :名無しさん@お腹いっぱい。 :02/03/27 00:10 ID:???
IPによりアク禁をかけるのは、それじたいは難しくないが、
そのIPリストを誰が管理するのかということと、
レイヤー8以降の問題が山積みではある。


837 :名無しさん@お腹いっぱい。 :02/03/27 00:13 ID:???
>>836
2ちゃんねるの場合 political layer の所が難しいよな。
Big-Server はサーバの表面程度しかいじれない。
ひろゆきはやる気もスキルもない。

838 :名無しさん@お腹いっぱい。 :02/03/27 00:15 ID:???
>>835
subback.htmlにどういうアクセスをしてきたものを弾くんでしょう?
通常使用でも見ることがあると思いますが

839 :名無しさん@お腹いっぱい。 :02/03/27 00:15 ID:???
gikozilla騒動について知らない、歴史を軽視するような
香具師は、monazilla part2の、、、あ、offaw落ちか、、、
http://www.google.com/search?q=cache:EU7vRQnwjxQC:pc.2ch.net/test/read.cgi/tech/1005282763/+&hl=ja
140〜を参照セヨ


840 :Dream ★ :02/03/27 00:19 ID:???
>>838
その辺は今話し手も仕方ないと思いますし、実装するとしたらなおさらいわないと思います。
私実装する人間ではありませんし、どんな権限もないです。

841 :Dream ★ :02/03/27 00:22 ID:???
ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→http://pc.2ch.net/test/read.cgi/software/1016905060/671
西安さん →http://pc.2ch.net/test/read.cgi/software/1016905060/672

842 :AJA6H/Ws ◆MPnX7dHA :02/03/27 00:29 ID:???
過去ログを縦読みしたけど、
昨日からなーんも進展がないような気がするんだけど・・・^^;

843 :名無しさん@お腹いっぱい。 :02/03/27 00:35 ID:???
>>842
現状の2ちゃんねるの問題が、それだけ深刻だと言う事

844 :名無しさん@お腹いっぱい。 :02/03/27 00:38 ID:???
>831
転送量や負荷を抑えるために
subback.htmlより小さいsubject.txtを読んだりread.cgiより負荷の小さいdat直読みしたりするツール
の使用が推奨されてるわけで、
subject.txtやdatを隠して誰が得するのか説明しろゴルァ(゚д゚)

ゲイツか?

845 :名無しさん@お腹いっぱい。 :02/03/27 00:39 ID:???
subject.txtを使った荒らしが減る。

846 : ◆hAnYaNVA :02/03/27 00:40 ID:???
TCPの3-Way-Handshakeは重い、という話をきいた
ことがあったので、あちしのツールではKeep-Aliveによる
Persistance-Connectionがなるべく途切れないように
しているわけだですけども、intervalがあるなら、当然
Connectionは毎回切れるわけで、そういうものなのか、と。

intervalを間に挟んだり、複数の鯖を交互に使用したりして
軽減される負荷というのは、Keep-AliveしてHandshakeを
削減するのよりも大きいのかな?という疑問はありますです。

847 :Dream ★ :02/03/27 00:41 ID:???
>>844
一定の枠を用意して、みたいないいカタすると官僚のようだけど、
ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
ツール作者さんには、subject.txtやdatを公開するって形だと、どうなんでしょね?

#ずっと私は、それを提案してきているんですけど
#誤解されていますか?

848 :名無しさん@お腹いっぱい。 :02/03/27 00:42 ID:???
公式発表的には、subject.txtは隠されているのですが。
つか、あなた、ブラウザから取得できますか。

849 :名無しさん@お腹いっぱい。 :02/03/27 00:42 ID:???
>>847
それなら隠すといわずに取得に制限を加えると言った方がいいのでわ

850 :Dream ★ :02/03/27 00:44 ID:???
>>846
インターバルを挟む、という思想は、ツールによる断続的で集中的な
リクエストを防ぐ、という視点に大きく立脚しちゃっているものだと思います。
作者さんの視点で、どういう方法が、サーバの負荷と転送量という問題に対して
効果的である、という、啓蒙というか、教育というか(私みたいなのに対して)
をしていただけると、とてもうれしいです。

851 :名無しさん@お腹いっぱい。 :02/03/27 00:45 ID:???
>>846
>>725-726 ではとっとと切断、って言って終わってるけど、
もうちょっと考えるべき事だと思う。

「じゃあ Keep alive せずに Rapid fire しろっていうことか?」
と誤解する人が出るのが怖い。

852 :Dream ★ :02/03/27 00:46 ID:???
>>849
ああなるほど。

#ここまでに、このスレッドでも前スレでもしつこくさんざん書いてたから了解済みだ
#という思いこみでした。
#すみませんでした

853 :Dream ★ :02/03/27 00:48 ID:???
>>851
是非お願いします。
SYN ACKの認証が正直きつい、というのがそもそも、dat直取りで巡回を
されたくない、という話の始点だったと思うんです。
私自身は、その程度の認識しかなく、
「だったらどうやるのが効果的なのか?」
については、是非お聞かせいただきたいと思っております。

854 :Dream ★ :02/03/27 00:52 ID:???
もちろん、dat直取りのもう一つの要因としては
転送量に影響する、というところもありますけど、これは、
要求されるのはHEAD情報だけで、datを直に取ってるわけではない、
というお話だと思いましたが・・・・
その場合でも、SYN←→ACKのハンドシェイク的に、サーバ負荷につながっていないのか?
とか、いろいろ、お聞きしたいことがありますです。

あと夜勤さんに、
http://www.yakin.cc/pv200201.html
には、HEAD要求は含まれていますか?というのを確認させていただきたいと思います。
PVという言い方の印象では、GETのみ、で、ページ単位のカウントのような気がします。
(イメージファイルとかそういう者を除いている、という意味で)
お願いします。

855 :AJA6H/Ws ◆MPnX7dHA :02/03/27 00:53 ID:???
>>843
なるほど

856 :名無しさん@お腹いっぱい。 :02/03/27 00:58 ID:???
場合わけをきちんとしようや。
・更新があるばあい
 ・Head(stat) [+ Get(read)]
 ・ims-Get(stat&read)
・ない場合。
 ・Head(stat)
 ・ims-Get(stat)
で、どっちにしろ、更新があれば中身をみたくなるわけで、
むしろIf-Modified-SinceをつけたGetの方が軽いのでは?
というのがすくなくとも8ヶ月前の結論だったわけですが。

857 :名無しさん@お腹いっぱい。 :02/03/27 00:59 ID:???
>>854
あの〜普通に巡回といわれるものはすべてIf-Modified-Since付きのGETですよ。
巡回時に自動でHEAD→GETとわざわざ無駄なことやってるものは即刻修正すべし、です。

858 :Dream ★ :02/03/27 01:01 ID:???
>>857
ああ、はい。
巡回じゃなくて、更新チェックですよね。はい・・・

859 : ◆hAnYaNVA :02/03/27 01:04 ID:???
>ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
>ツール作者さんには、subject.txtやdatを公開するって形だと、
>どうなんでしょね?

ところで、これは現在のsubject.txtの状態と具体的に
どのあたりが異なるのでしょうか?


860 :Dream ★ :02/03/27 01:07 ID:???
>>859
いまはhtaccessやcgi内部で判別してアクセス受け付けてるようですが、
たとえば、基本認証使ってリクエスト受ける、というイメージです。
イメージ的には。

861 :名無しさん@お腹いっぱい。 :02/03/27 01:08 ID:???
>>859
ぎこはにゃ〜ん作者登場。


862 :名無しさん@お腹いっぱい。 :02/03/27 01:13 ID:???
>>860
ナニを認証するのさ?●?

863 :名無しさん@お腹いっぱい。 :02/03/27 01:15 ID:???
>>860
それが何の解決になるの?鯖負担が増えるだけでは?
荒らしツールはどれかのツールに簡単になりすましができるけど。

864 :名無しさん@お腹いっぱい。 :02/03/27 01:16 ID:???
>862
ツール(と作者)、じゃないかな。
セキュリティ的にはヨワヨワでないも同然だけど、
そこを不正アクセス禁止法で補助するような感じがする。


865 :名無しさん@お腹いっぱい。 :02/03/27 01:16 ID:???
>>863 荒らし対策の話をするスレなのか?

866 :名無しさん@お腹いっぱい。 :02/03/27 01:17 ID:???
>>865
違うはずなんだけど、まとめ役がそっちに話を持っていくんだもの。

867 :名無しさん@お腹いっぱい。 :02/03/27 01:19 ID:???
>>860
イメージとか、イメージ的では正直意味がとれないよ。
具体的な説明求む。

868 :Dream ★ :02/03/27 01:22 ID:???
>>867
すいません。イメージなイメージ的にエクスキューズな単語ですけど、
>たとえば、基本認証使ってリクエスト受ける
これそのものずばりではないかと愚考します。

869 :名無しさん@お腹いっぱい。 :02/03/27 01:22 ID:???
>>866 責任転嫁すな。

870 :名無しさん@お腹いっぱい。 :02/03/27 01:24 ID:???
ん、だから普通にsubject.txtをGETしても
HTTP/1.1 401 Authorization Required
が帰ってきて、ちゃんとパス送らないと
受信できねって事だろ。
で、このパスを勝手に解析すると不正アクセス防止法に触れる可能性があると。

871 :Dream ★ :02/03/27 01:25 ID:???
>>865
荒らしが過負荷の要因になっていない、または、別の手段で対応が出来る、
ということであれば、そういう仕組みは一切要らないかと思います。
たとえば、特定の業者がdatクロールして利益を得ようとしているわけです。
たとえば、全くランダムなdatから書き込みを抽出して、それを、
subject.txtで特定のスレッド拾って、bbs.cgiにPOSTしたりしているわけです。
そういう行為を、負荷低減策として検討する必要がないのであれば、
datもsubjectも、現行のままでよろしいのではないかと思います。

872 :名無しさん@お腹いっぱい。 :02/03/27 01:27 ID:???
>>870
法律なんか気にするな!

873 :名無しさん@お腹いっぱい。 :02/03/27 01:29 ID:???
>>871
それが問題なんだからそっちを対処しようよ。

手に入れたデータまたはその統計を商業利用しようとしている
ところから金を取れるように何か利用規定を設ければいい。

具体的には抜き打ちでIP統計とって、異常に多いところの
IPがどっかの会社だったら 「金払え」 って言えばいいよ。

抜け道はあるかもしれないけど、それはそれで
バレた日にはその会社は2ちゃんねらに潰される

874 :873 :02/03/27 01:31 ID:???
抜け道はあるかも → 抜け道はたくさんあるけど
だった。

少なくともちょっとは金取れるようになるよ。
そしてその金で回線増強なりなんなりできる、と。

875 :Dream ★ :02/03/27 01:32 ID:???
>>873
でもですね、やっぱしあれなんですよ。
荒らしが発生していない日でも、厳然としてサーバはぱんぱん
帯域かつかつ。なんだそうです。

876 :867 :02/03/27 01:32 ID:???
>>868
いや、基本認証使ってリクエスト受けると、基本認証する分だけ
負荷が増すと思うんで、その辺どう考えてるのか知りたいなと。

877 :名無しさん@お腹いっぱい。 :02/03/27 01:33 ID:???
現状だとUAをモナジラと詐称するだけで、
荒らしツールだろうとなんだろうとsubject.txtは受信できちゃうわけで、
しかもそれは法にはふれない。犯罪じゃない。
(UAを偽る=鯖を騙す=詐欺罪って話もなきにしもあらずって感じらしいが)

そこを認証にすれば、不正アクセス防止法違反という立派な犯罪にできる。
だから荒らしツールを抑制できる。
悪質なら訴えれば逮捕される。
って事だな。

まぁ、俺ならそんな事されたらsubback.htmlで同じ事するけどね。
それもなくなったとしてindex.htmlから生成すればいいし、
それもだめだったら
http://pc.2ch.net/test/read.cgi/software/1016905060←ここのキーを
現在時刻からさかのぼって存在をチェックしてランダムに荒らすようにだってできる。
ブラウザで見れてカキコできる時点で、なんでもできるわな、そりゃ。

つか、むしろそういう規制された方が燃えるね。
なんとしても荒らしてやろう!ってな。

878 :873 :02/03/27 01:34 ID:???
>>875
この話は批判要望に書くべき内容だった。すまんこ。

荒らしが原因の日もあるだろうけど問題なのは
慢性的にクロールしてる企業がいるで重い
ってとこかと

879 :名無しさん@お腹いっぱい。 :02/03/27 01:35 ID:???
かちゅーしゃのアクセスが多い、ってのはそういう企業が作ったツールが
とりあえず有名なかちゅーしゃのUAを偽ってる、ってパターンが多かったりしてね

880 : ◆hAnYaNVA :02/03/27 01:36 ID:???
でもそれは、オープンソースの死だよね。
dat、subject.txtのgetにpassが必要で、
それをツールに埋め込んでしまう時点で。


881 :Dream ★ :02/03/27 01:38 ID:???
なにか起死回生の良いアイデアありませんでしょうか?

882 :名無しさん@お腹いっぱい。 :02/03/27 01:38 ID:???
>>880 >>768 で一度指摘されたが、返答なし
オープンソースの場合、隠しているとはどう考えても言えないから
法に頼るのも難しいと思われるが

883 :877 :02/03/27 01:38 ID:???
>>880
パス埋め込んでもかんけねーよ。
認証なんてなんの暗号化もされてないんだから、
ローカルでプロクシ立てて通信内容のぞき見れば、
すぐにパスなんて分かるっつーの。
仮にプロクシ立てられなくてもTCP/IP通信内容をのぞき見るツールだってあるんだし。


884 :名無しさん@お腹いっぱい。 :02/03/27 01:41 ID:???
というか自分がなにを発信しているか、受信しているかはすぐわかる。


885 :Dream ★ :02/03/27 01:42 ID:???
>>882-883
なんか代替案がありましょうか?

886 : ◆hAnYaNVA :02/03/27 01:43 ID:???
BASIC認証はたとえなので、Digest認証くらいは
使うものだと当然思っていましたが、、、
別にこれがSSLのClient Certificationでもそんなに
話は変わらないと思うのですが。

887 :Dream ★ :02/03/27 01:45 ID:???
誰かの書いた内容について、批判したり、だめな面を指摘するのは
すごく簡単だと思うんですよね

でも、ここ重役会議やっているわけじゃないんですよ。
どうしようかね?って話してるつもりなんです。

私の提案に不具合や不足があったらとっとと引っ込めます。
良い案を考えていただけるととてもうれしいんです。
(否定すんなよ、ていうんじゃないですよ、もちろん(笑))

888 :名無しさん@お腹いっぱい。 :02/03/27 01:46 ID:???
だから平凡なパスを埋め込むというのは愚行。
送信内容の一部を暗号化して・・・ってのなら効果はあるけどね。
一部にPGPを使うとか。(遅そー)

283KB
新着レスの表示

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30