このスレは「P2P型の完全匿名掲示板はまだ出来ないの?」スレからforkして生まれました
2ちゃんの代替となる2ちゃん型掲示板をP2Pで実装してみようぜ、なスレです
名前が長いので若干スレタイは変えましたファイル共有ソフト等の話題はスレ違いなのです
origin:P2P型の完全匿名掲示板はまだ出来ないの?その4
http://toro.2ch.net/test/read.cgi/tech/1390486453/
wiki
http://www34.atwiki.jp/p2p-anon/
[参考]
Tor(The Onion Router)のHidden Service(onionドメイン)Onionちゃんねる
http://xiwayy2kn32bo3ko.onion/ (Tor経由でのみアクセス可能)
Syndie - distributed forums
http://syndie.i2p2.de/
Freenet - P2Pコミュニケーションフレームワーク
https://freenetproject.org/
[関連するP2P掲示板ソフトウェア等]
新月 - P2P匿名掲示板
http://shingetsu.info/index.ja
P2P2ch
http://p2p2ch.web.fc2.com/
ちらしの裏
http://chiraura0.web.fc2.com/
alias
https://code.google.com/p/alias/
o2on
https://github.com/o2on/o2on
探検
2ちゃんねる互換P2P匿名掲示板の実装を考える 1
■ このスレッドは過去ログ倉庫に格納されています
2014/04/23(水) 23:29:44.09ID:k48oXhUz
124デフォルトの名無しさん
2014/05/08(木) 14:12:32.37ID:tK+74K/E >>123
P2Pというか、分散DBの類だからこそACID意識するんじゃないの?
P2Pというか、分散DBの類だからこそACID意識するんじゃないの?
125デフォルトの名無しさん
2014/05/08(木) 14:29:26.84ID:aLJM5gos126デフォルトの名無しさん
2014/05/08(木) 14:41:08.06ID:aLJM5gos レス1の次に書き込まれたレスは、必ずレス2にならなくてはならない。
これを保証するにはどういう設計にすればよいのだろう。
これを保証するにはどういう設計にすればよいのだろう。
127デフォルトの名無しさん
2014/05/08(木) 14:45:19.56ID:rrq/Td9f128デフォルトの名無しさん
2014/05/08(木) 14:53:49.00ID:5NN0m/yU レスが改竄されないことを前提とすると
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんw
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー
まあ、多少順番が狂っても別にいいと思うけど
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんw
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー
まあ、多少順番が狂っても別にいいと思うけど
129デフォルトの名無しさん
2014/05/08(木) 15:30:16.25ID:lBa33A+E 必ず分岐が起こるがその場合どうするのか?
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる
130デフォルトの名無しさん
2014/05/08(木) 20:32:46.09ID:oHeX29Ky レスの順番なんてどうでもいいだろ
本当に必要な場面になったら、後から安価して順序を説明すりゃいい
本当に必要な場面になったら、後から安価して順序を説明すりゃいい
131デフォルトの名無しさん
2014/05/08(木) 20:42:45.56ID:Lwvjy9Um 順序の制御は無理だろう
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね
132デフォルトの名無しさん
2014/05/08(木) 21:07:16.40ID:lBa33A+E レス順が変わるのはスレッドが分岐したときの副作用で、この分岐には適切に対処しないと改竄スレッドを流されてしまう穴になる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる
133デフォルトの名無しさん
2014/05/08(木) 21:12:09.26ID:oHeX29Ky 改竄は防げない前提で考えたほうがいいんじゃないの?
された場合にどうするかを考えたほうが現実的な気がする
例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない?
された場合にどうするかを考えたほうが現実的な気がする
例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない?
134デフォルトの名無しさん
2014/05/08(木) 21:16:48.49ID:JZCmTzL0 内容に不一致があればそれ以降はフォークとみなすしかないんじゃね
135デフォルトの名無しさん
2014/05/08(木) 21:23:14.60ID:oHeX29Ky ワーキングディレクトリに他のノードからの更新を受けておいて、
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない?
プル地獄になりそうだけど
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない?
プル地獄になりそうだけど
136461 ◆Of8OpFdQADOA
2014/05/08(木) 22:04:50.39ID:fes617/2 私の実装ではレスごとに固有のIDを与えて内部で自動変換していますね。
見た目が変わらなければどうということはないです。
見た目が変わらなければどうということはないです。
137デフォルトの名無しさん
2014/05/09(金) 09:39:28.91ID:b6QXm0aH レス番は投稿情報のハッシュ(仮にレスIDとする)とかにしとくと楽だわな
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か?)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね?ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる
>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か?)さえ防げればいい。
>>129>>132
直線構造に拘る必要はなくね?ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる
138デフォルトの名無しさん
2014/05/09(金) 11:03:34.80ID:NbpGrdz5 特定のレスをNGにして、自分ノードではやりとりしないっていう機能も必要だね
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか?
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ
手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか?
139デフォルトの名無しさん
2014/05/09(金) 15:06:49.62ID:gsXjT/a8140デフォルトの名無しさん
2014/05/09(金) 15:09:17.80ID:gsXjT/a8 なんつーかツリー型サーバーでしか出てこない様な概念を持ち出してくる奴なんなの?
141デフォルトの名無しさん
2014/05/09(金) 18:37:25.91ID:+yL8uyYO レス順が変わることの本質はスレッドの分岐で、それをマージするときにノーチェックでやるのか?ってところがポイント
ノーチェックだとレスを自由に増やせると思うけどね
ノーチェックだとレスを自由に増やせると思うけどね
142461 ◆Of8OpFdQADOA
2014/05/10(土) 02:49:08.11ID:wuv9w3Kh そもそもどうして投稿をマージして、しかもそらを再送出する必要があるんですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。
143デフォルトの名無しさん
2014/05/10(土) 03:10:36.81ID:qPsk9Q0C >>140
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく?
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね?
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく?
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね?
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。
144デフォルトの名無しさん
2014/05/10(土) 10:02:50.39ID:oq9GBtii 総論の話中だが、
要素技術にWebRTCのプラットフォームを使うのはどうだろう?
skyway
http://nttcom.github.io/skyway/
javascriptで開発できるから、web系の人も開発に参加できる。
要素技術にWebRTCのプラットフォームを使うのはどうだろう?
skyway
http://nttcom.github.io/skyway/
javascriptで開発できるから、web系の人も開発に参加できる。
145デフォルトの名無しさん
2014/05/10(土) 10:41:46.80ID:qPsk9Q0C >>144
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。
146デフォルトの名無しさん
2014/05/10(土) 11:17:44.29ID:oq9GBtii 課題はあるけど、WEB系の技術を使うことができれば、
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
(暗号化すれば内容によるブロックもできない)
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
(暗号化すれば内容によるブロックもできない)
147デフォルトの名無しさん
2014/05/10(土) 12:15:33.26ID:m9xHqVTZ ほう、それでWEB系の技術だけで
暗号化するにはどうしたらいいのかね?
暗号化するにはどうしたらいいのかね?
148デフォルトの名無しさん
2014/05/10(土) 12:43:23.93ID:oq9GBtii >>147
jsライブラリならいっぱいあるだろ。
jsライブラリならいっぱいあるだろ。
149デフォルトの名無しさん
2014/05/10(土) 14:43:55.94ID:qPsk9Q0C150デフォルトの名無しさん
2014/05/10(土) 14:53:52.12ID:m9xHqVTZ つまりはWEB系の技術というのは
要するに既存技術をJavaScriptで実装したものって
だけの話だな
要するに既存技術をJavaScriptで実装したものって
だけの話だな
151デフォルトの名無しさん
2014/05/10(土) 15:18:11.43ID:qPsk9Q0C WEB系の技術って既存技術の内WEB系の物って意味じゃねーの?
あと「JavaScriptで実装したもの」って制限はどっから出てきたん?
あと「JavaScriptで実装したもの」って制限はどっから出てきたん?
152デフォルトの名無しさん
2014/05/10(土) 15:18:41.10ID:cY+uAlOa WebRTC使うならOpenPeerがあるってだいぶ前に書いたよな
http://openpeer.org
http://openpeer.org
153デフォルトの名無しさん
2014/05/10(土) 17:45:32.03ID:D1xN7jn3 >>143
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな?
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは?
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか?
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは?
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな?
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは?
それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか?
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが
とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは?
154デフォルトの名無しさん
2014/05/11(日) 09:02:01.38ID:HBJbY+fy >>153
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい
スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと
155デフォルトの名無しさん
2014/05/11(日) 09:41:42.34ID:z48caAbF え?DDoS?
156デフォルトの名無しさん
2014/05/11(日) 10:28:28.25ID:MfUQ5tqR 確定投稿と未確定投稿に分けて考えればいいんだよ。
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を2ch互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと?
特にフラグ設けなくてもレス番の有無で判断がつくし。
未確定投稿を2ch互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと?
157デフォルトの名無しさん
2014/05/11(日) 18:29:50.66ID:HBJbY+fy158デフォルトの名無しさん
2014/05/18(日) 19:40:42.92ID:oxq+ikAO >>48
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html
tor 規制も遠くない
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html
tor 規制も遠くない
159デフォルトの名無しさん
2014/05/19(月) 07:33:43.51ID:xEeDrkw/ 記事の内容読んだか?
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない
160デフォルトの名無しさん
2014/05/19(月) 17:58:41.42ID:WT1tTslw アノニマスが開発した「AirChat」が凄い!インターネットなしでデータ通信
http://blog.livedoor.jp/itsoku/archives/38902170.html
http://blog.livedoor.jp/itsoku/archives/38902170.html
161デフォルトの名無しさん
2014/05/19(月) 21:46:42.22ID:lhsjIgd7 >>160
読んでないけど、手旗信号と見た
読んでないけど、手旗信号と見た
162デフォルトの名無しさん
2014/05/19(月) 22:31:10.57ID:zujUZLqg 最終的にはインターネットに繋がるらしいが、
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。
-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。
-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。
163デフォルトの名無しさん
2014/05/19(月) 23:14:38.92ID:rPuNmFhW だから、DSの擦れ違い通信だって
164デフォルトの名無しさん
2014/05/20(火) 03:58:15.26ID:XZ8PbsoH いつのまにか Vidalia 単体のダウンロードができなくなった‥
ブラウザででしか使用できない‥
ブラウザででしか使用できない‥
165デフォルトの名無しさん
2014/05/20(火) 06:54:05.58ID:gZsncm2t 素人には危険だからかな
166デフォルトの名無しさん
2014/05/20(火) 10:24:43.89ID:PJc6Nn45 https://github.com/gitchain/gitchain
これまんま掲示板に転用できないか?
これまんま掲示板に転用できないか?
167461 ◆Of8OpFdQADOA
2014/05/24(土) 18:37:39.78ID:OAvaL96R 開発者向けの話題を提供しましょう。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか?
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか?
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。
168デフォルトの名無しさん
2014/05/24(土) 19:40:20.45ID:uWBH7T6t そんなのどっちでもよい
169デフォルトの名無しさん
2014/05/24(土) 19:59:57.61ID:jYoMAPG8 >>167
こっちでは今PDですら遮断される状況だから偽装してほしいな
こっちでは今PDですら遮断される状況だから偽装してほしいな
170デフォルトの名無しさん
2014/05/24(土) 20:32:26.64ID:7m1F5+NU 今迄のは開発者の話題ではないと思ってたのか。なんかこいつにイラっとくるのってオレだけかな
171デフォルトの名無しさん
2014/05/24(土) 20:33:42.07ID:9qFFfmjf >>170
アスペかよ
アスペかよ
172デフォルトの名無しさん
2014/05/24(土) 20:35:25.26ID:8L8QZ0Si >>167
扱いやすいしバイナリ一択だな
扱いやすいしバイナリ一択だな
173デフォルトの名無しさん
2014/05/24(土) 20:44:07.64ID:uWBH7T6t そんなのどうでもいいって言った理由は、
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。
174デフォルトの名無しさん
2014/05/24(土) 21:07:02.75ID:8L8QZ0Si 機能面ではそうだが、テキストはパースにも構築にも、バイナリに比べて数十倍数百倍の時間が掛かるからなぁ
比較とかもバイナリの方が簡単だし
比較とかもバイナリの方が簡単だし
175デフォルトの名無しさん
2014/05/24(土) 21:13:01.28ID:uWBH7T6t それは全体の1%にも満たない部分だから
時間がかかっても問題ない。
時間がかかっても問題ない。
176デフォルトの名無しさん
2014/05/24(土) 21:15:21.89ID:oWuOT6f1 どうでもいいことに拘ってないで、まずは要件定義をしろw
177デフォルトの名無しさん
2014/05/24(土) 22:08:44.78ID:7CvGDBUR >>167
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える
178デフォルトの名無しさん
2014/05/24(土) 22:48:03.61ID:oWuOT6f1 要素技術なんぞ詳細設計の段階の話だろうがw
まずは要件定義しろw
まずは要件定義しろw
179デフォルトの名無しさん
2014/05/24(土) 23:07:23.72ID:rfdD6r00 Unicodeをデフォルトにしようず。
UTF-8が無難だが日本的にはUTF-32にも惹かれる
UTF-8が無難だが日本的にはUTF-32にも惹かれる
180Unicodeキボンヌ
2014/05/25(日) 00:00:09.81ID:wqNjSVko 書込時の匿名性はP2Pによって実現するといっても、
閲覧時にP2Pは不要(cf.新月ネットワークの場合は閲覧用にもP2Pを利用する)。
サーバーは有志の運営に委ねる(中央集権的管理の完全否定)。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。
閲覧時にP2Pは不要(cf.新月ネットワークの場合は閲覧用にもP2Pを利用する)。
サーバーは有志の運営に委ねる(中央集権的管理の完全否定)。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。
181デフォルトの名無しさん
2014/05/25(日) 02:30:20.38ID:UOeAOsx2 >180
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか?w
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか?w
182Unicodeキボンヌ
2014/05/25(日) 04:05:32.41ID:wqNjSVko 意味不明。
サーバーに反映されないと誰も見れないのに、なぜそうなるの?
サーバーに反映されないと誰も見れないのに、なぜそうなるの?
183デフォルトの名無しさん
2014/05/25(日) 04:51:54.21ID:dtutVys2 >>180
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ?
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと?
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ?
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと?
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。
184デフォルトの名無しさん
2014/05/25(日) 05:24:34.63ID:NeNyrW9A185デフォルトの名無しさん
2014/05/30(金) 00:54:12.35ID:wHSl8lb9 そもそも匿名が何故必要かってところを勘違いしてないか?
186デフォルトの名無しさん
2014/05/30(金) 01:26:19.48ID:SDqP+4IS 冤罪逮捕を防止するためだよ
187デフォルトの名無しさん
2014/05/31(土) 15:35:19.94ID:QHlXh24u そもそも逮捕されるような事が出来るツールという時点であまり説得力がないんだよな
普通に健全な内容であれば特別匿名性が高い必要もない
普通に健全な内容であれば特別匿名性が高い必要もない
188デフォルトの名無しさん
2014/05/31(土) 16:13:40.81ID:sWppcuRc インターネット自由宣言に則ったネットワークを構築するため
189デフォルトの名無しさん
2014/05/31(土) 16:39:38.30ID:eTy5fHBW つ外患罪・内乱罪
そういうものに対応できるシステムがあってもいいという立場もないわけではない,ああこれって予備・陰謀になりうるのか?
日本は主に島原の乱以来の営々たる血と汗の努力により現在は稀にみる平穏な土壌が育っているので必要性は感じられないのかもしれない
そういえば何かのアニメに自主すれば無罪とかいっていたが‥@アニメーションはなんだったか?A本当か?
そういうものに対応できるシステムがあってもいいという立場もないわけではない,ああこれって予備・陰謀になりうるのか?
日本は主に島原の乱以来の営々たる血と汗の努力により現在は稀にみる平穏な土壌が育っているので必要性は感じられないのかもしれない
そういえば何かのアニメに自主すれば無罪とかいっていたが‥@アニメーションはなんだったか?A本当か?
190デフォルトの名無しさん
2014/05/31(土) 17:06:46.63ID:VTj4ztuh こっちはもう匿名性は放棄したんじゃないの?それともP2Pにすれば自動的に匿名になるとでも思ってる?
191デフォルトの名無しさん
2014/05/31(土) 17:17:05.44ID:QdYI2yy/ どこかにこのスレの公式仕様みたいのでもあるのかね。
192デフォルトの名無しさん
2014/05/31(土) 17:30:37.03ID:QKYyOmO8 >>1に「2ちゃんの代替となる」とあるだろう。
一般の2ちゃんユーザーが納得する程度の匿名性があれば十分だということなんだよ。
匿名性の技術的保証の辺りをグダグダ言う奴用には、もう一つのフォーク元のスレが用意してある。
一般の2ちゃんユーザーが納得する程度の匿名性があれば十分だということなんだよ。
匿名性の技術的保証の辺りをグダグダ言う奴用には、もう一つのフォーク元のスレが用意してある。
193デフォルトの名無しさん
2014/05/31(土) 18:45:31.68ID:PqKUKu7D >>189
多分アニメは「攻殻機動隊 Stand Alone Complex 2nd GIG」
罪状は「内乱の予備・陰謀、外国に対し私的に戦争をする目的の予備・陰謀」
でもこれ架空の近未来日本を舞台にした作品だからこれを参考にするのは間違ってる。
第三次非核大戦後だの自衛軍だの電脳化率9割超だの難民わらわらだのだし…
プログラマを武器と見做して武器禁輸措置を適用しちゃうような世界。
まぁこういう言うのはアレだ、誤用じゃない方の確信犯として突き進む類の話じゃね?
言論の自由とか人権レベルで正しい行為だと確信しての行いが犯罪になるケース。
だけど真面目な話、憲法で保証されてる権利の行使だと、刑法はひっくり返る場合がありうる。
明確な外患誘致や内乱の意図がなければ最高裁まで引っ張って勝てる可能性がある話かと。
多分アニメは「攻殻機動隊 Stand Alone Complex 2nd GIG」
罪状は「内乱の予備・陰謀、外国に対し私的に戦争をする目的の予備・陰謀」
でもこれ架空の近未来日本を舞台にした作品だからこれを参考にするのは間違ってる。
第三次非核大戦後だの自衛軍だの電脳化率9割超だの難民わらわらだのだし…
プログラマを武器と見做して武器禁輸措置を適用しちゃうような世界。
まぁこういう言うのはアレだ、誤用じゃない方の確信犯として突き進む類の話じゃね?
言論の自由とか人権レベルで正しい行為だと確信しての行いが犯罪になるケース。
だけど真面目な話、憲法で保証されてる権利の行使だと、刑法はひっくり返る場合がありうる。
明確な外患誘致や内乱の意図がなければ最高裁まで引っ張って勝てる可能性がある話かと。
194デフォルトの名無しさん
2014/05/31(土) 20:22:55.65ID:LCfd5xM6 ぼくのかんがえたさいきょうの掲示板(笑)
195デフォルトの名無しさん
2014/05/31(土) 21:29:14.84ID:F4zWTlG/ >>194
それを大真面目に考えるのがこのスレなわけだがw
それを大真面目に考えるのがこのスレなわけだがw
196デフォルトの名無しさん
2014/05/31(土) 21:37:02.40ID:Q4fGK0zf このスレだと茶化しで済むが、向うのスレだとマジで噛み付いてくる奴がいるぞ。
>>193
おお,thx なんのアニメだったか思い出せなかったんだ,神山氏は神だね‥‥
おお,thx なんのアニメだったか思い出せなかったんだ,神山氏は神だね‥‥
198デフォルトの名無しさん
2014/06/01(日) 13:14:29.54ID:ahYmPm0r ネットワーク上の第三者から、書き込み主を物理的に(ここではIPアドレスが)特定できてはいけない
同一人物からの複数書き込みの、書き込み主が同定できなければならない
これの両立が必要?
同一人物からの複数書き込みの、書き込み主が同定できなければならない
これの両立が必要?
199デフォルトの名無しさん
2014/06/01(日) 13:42:27.05ID:nKywzM47 2つ目は1つ目を守りながら実現するのが難しいし、
自主的にID振って他人のID詐称できない程度
(一人で複数IDを使用を阻止できなくても良い)
にしておいたほうが実現しやすいと思うけど。
どうせ2chだってID変えれる環境の奴は変えれる程度のものだし、
完全に阻止するためにはIPアドレス以上の同定能力が必要になる。
そこまでの同定能力は現実的じゃない、と思うんだが。
自主的にID振って他人のID詐称できない程度
(一人で複数IDを使用を阻止できなくても良い)
にしておいたほうが実現しやすいと思うけど。
どうせ2chだってID変えれる環境の奴は変えれる程度のものだし、
完全に阻止するためにはIPアドレス以上の同定能力が必要になる。
そこまでの同定能力は現実的じゃない、と思うんだが。
200デフォルトの名無しさん
2014/06/01(日) 14:17:33.73ID:OFREtEr0 童貞能力なら…
201デフォルトの名無しさん
2014/06/01(日) 15:13:18.34ID:ahYmPm0r 変えれるけど、それなりに面倒なものをキーとして不可逆変換でIDを生成し
書き込み時の通信経路を不定にする
たとえばキー候補
・グローバルIPアドレス
・MACアドレス
・OSのプロダクトID(Windowsなら)
・OSのユーザーID
・システムドライブのハードID
キーから生成したユーザID、書き込み時刻、スレIDをネットワークに放流。
受信したノードは、自身がスレを保持しかつ未書き込みなら、確率でスレを更新する。
更新確率は放流寿命(TTLみたいなもの、加えて時間的な寿命も含む)が長いほど低く、短いほど高い。
そしてTTLを(確率で)デクリメントして、さらに放流。寿命が尽きたら再放流しない。
書き込みデータは、時間的寿命が尽きるまではキャッシュに保管。キャッシュデータのTTLは0にする。
書き込み以外にも、自ノード他ノード関わりなく最近更新されたスレデータもポツポツと放流する。
他ノードから流れてきたスレデータと自身が保持するスレデータ・キャッシュ上の書き込みデータを比較し差分がある場合は
マージしてから、そのスレを過去に送った先に送信、今回の送信元に返信する。
その際のタイムスタンプは、最後の書き込み時刻。
書き込みの時系列とレス順が一致しないので、レス番に変わるレスIDの仕様を盛り込む。
リーダーがレスIDをレス番に変換しても良いが、明示的に「>」をつけない書き込みがあり得るので
レス番は廃止したいとこだな。
うーん、スレデータが爆発するのと、改ざんをどうやって防ぐかが問題だな。
あとレス削除の仕様も必要。
ユーザIDに対して第三者が信用ポイントを加算していく、ってアイディアをベースにすると
なにか出来そうなんだけどな。
書き込み時の通信経路を不定にする
たとえばキー候補
・グローバルIPアドレス
・MACアドレス
・OSのプロダクトID(Windowsなら)
・OSのユーザーID
・システムドライブのハードID
キーから生成したユーザID、書き込み時刻、スレIDをネットワークに放流。
受信したノードは、自身がスレを保持しかつ未書き込みなら、確率でスレを更新する。
更新確率は放流寿命(TTLみたいなもの、加えて時間的な寿命も含む)が長いほど低く、短いほど高い。
そしてTTLを(確率で)デクリメントして、さらに放流。寿命が尽きたら再放流しない。
書き込みデータは、時間的寿命が尽きるまではキャッシュに保管。キャッシュデータのTTLは0にする。
書き込み以外にも、自ノード他ノード関わりなく最近更新されたスレデータもポツポツと放流する。
他ノードから流れてきたスレデータと自身が保持するスレデータ・キャッシュ上の書き込みデータを比較し差分がある場合は
マージしてから、そのスレを過去に送った先に送信、今回の送信元に返信する。
その際のタイムスタンプは、最後の書き込み時刻。
書き込みの時系列とレス順が一致しないので、レス番に変わるレスIDの仕様を盛り込む。
リーダーがレスIDをレス番に変換しても良いが、明示的に「>」をつけない書き込みがあり得るので
レス番は廃止したいとこだな。
うーん、スレデータが爆発するのと、改ざんをどうやって防ぐかが問題だな。
あとレス削除の仕様も必要。
ユーザIDに対して第三者が信用ポイントを加算していく、ってアイディアをベースにすると
なにか出来そうなんだけどな。
202デフォルトの名無しさん
2014/06/01(日) 15:34:19.39ID:iF6nhgL2 >>198-199
オニオンルーティングで経路を隠しつつ,P2Pネットワークの入り口で IP アドレスを同定して ID を振ることは可能だよ.
ただ IP アドレス空間が狭すぎてレインボーテーブル手法が可能であることが問題なだけ.
ソルトを工夫すればいけるんじゃないかとおもうが,具体的手法は思いつかない
オニオンルーティングで経路を隠しつつ,P2Pネットワークの入り口で IP アドレスを同定して ID を振ることは可能だよ.
ただ IP アドレス空間が狭すぎてレインボーテーブル手法が可能であることが問題なだけ.
ソルトを工夫すればいけるんじゃないかとおもうが,具体的手法は思いつかない
203デフォルトの名無しさん
2014/06/01(日) 15:35:13.55ID:iF6nhgL2204デフォルトの名無しさん
2014/06/01(日) 16:10:14.70ID:nKywzM47 >>201
その辺の値は生の値を改竄無く提供できないなら検証も出来ないのがなぁ…
一人が複数の値を名乗れる問題と、一人が他人の値を名乗れる問題は異なる。
前者はまぁ程々にするしかないけど(極論、協力者に代理頼めば別人になれる)、
後者は明らかに色々と問題が起きるから防がないと不味い。>>203
確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
>>202
入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する?
というかその辺の問題にぶち当たる部分は程々にしとくのがコッチのスレでは?
その辺の値は生の値を改竄無く提供できないなら検証も出来ないのがなぁ…
一人が複数の値を名乗れる問題と、一人が他人の値を名乗れる問題は異なる。
前者はまぁ程々にするしかないけど(極論、協力者に代理頼めば別人になれる)、
後者は明らかに色々と問題が起きるから防がないと不味い。>>203
確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
>>202
入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する?
というかその辺の問題にぶち当たる部分は程々にしとくのがコッチのスレでは?
205デフォルトの名無しさん
2014/06/01(日) 16:34:00.28ID:iF6nhgL2 >>204
>入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
>架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する?
まず架空のIPアドレスというのは存在しない
接続された方が取得する(直接の)IPアドレスは本物だ,そうでなければ IPが成立しない.したがって「架空のIPアドレス」という文言自体がでることからして >>204 の文言は一切がっさい疑わしい
(たぶんバークレーソケットを触ったことがないんだろう‥)
ただし投稿者を特定できなくするオニオンルーティングを通過した後は,いずれ匿名掲示板ノードに到達するわけだが,このレベルの偽装はどうするべきか.
個人的には,DHT 実装でもない限り,ルーティング情報を盛り込んでユーザー側の判断にゆだねるのが妥当だと思う
fj で path: aaaa!bbbb! cccc! というヘッダがあったがあれは以外と有用だった>>628
>入り口での生成だと、投稿者が投稿者ノードではなく入り口のノードとして振る舞う事で、
>架空のIPアドレスを持った投稿者ノードからの投稿に偽装出来てしまうのはどう対策する?
まず架空のIPアドレスというのは存在しない
接続された方が取得する(直接の)IPアドレスは本物だ,そうでなければ IPが成立しない.したがって「架空のIPアドレス」という文言自体がでることからして >>204 の文言は一切がっさい疑わしい
(たぶんバークレーソケットを触ったことがないんだろう‥)
ただし投稿者を特定できなくするオニオンルーティングを通過した後は,いずれ匿名掲示板ノードに到達するわけだが,このレベルの偽装はどうするべきか.
個人的には,DHT 実装でもない限り,ルーティング情報を盛り込んでユーザー側の判断にゆだねるのが妥当だと思う
fj で path: aaaa!bbbb! cccc! というヘッダがあったがあれは以外と有用だった>>628
206デフォルトの名無しさん
2014/06/01(日) 16:38:51.48ID:nKywzM47 コッチのスレ的にはIDはとりあえず1日使い捨てのオレオレ証明書でいいと思う。
あと、ちょっと向こうのスレ的なネタになるけどIDの生成方法として、
出力ビット数を極端に落としたハッシュ関数ってのは使えないかな?
板ないしスレッドに相当する情報と日付から適当な式でN個(100個位)のID発行ノード用ハッシュ値を生成する。
投稿を行う前に、それらのハッシュ値を保持するノードに直接接続して1ビットID(IPアドレスベース)を発行してもらう。
表示の際は、投稿に含まれるNビットの生IDを適当なエラー訂正アルゴリズムに通してMビットのIDを表示する。
IDシード用ハッシュ値を保持するノードはその日のID=0用電子署名とID=1用電子署名とソルトを用意しておき、
ID発行依頼があればアクセス元IPアドレスとソルトで発行したID側の秘密鍵と、両IDの公開鍵をアクセス元に返す。
数ビット分のハッシュ関数を知ってもIDを逆算は出来ないし、ID発行ノードも1ビットでは誰に発行したIDか判別できない。
ID発行ノードが変動したり消えたりした分はエラー訂正アルゴリズムである程度は吸収できる。
普通のDHT同様、その日の署名+ソルトのセットを切断前に他人に引き継ぐ仕組みも頑張れば実現できる…かな?
問題は投稿ごとのメタデータのサイズと処理で、N*2個の公開鍵とN個の署名をIDのためだけに付加しなければならない。
あと、ちょっと向こうのスレ的なネタになるけどIDの生成方法として、
出力ビット数を極端に落としたハッシュ関数ってのは使えないかな?
板ないしスレッドに相当する情報と日付から適当な式でN個(100個位)のID発行ノード用ハッシュ値を生成する。
投稿を行う前に、それらのハッシュ値を保持するノードに直接接続して1ビットID(IPアドレスベース)を発行してもらう。
表示の際は、投稿に含まれるNビットの生IDを適当なエラー訂正アルゴリズムに通してMビットのIDを表示する。
IDシード用ハッシュ値を保持するノードはその日のID=0用電子署名とID=1用電子署名とソルトを用意しておき、
ID発行依頼があればアクセス元IPアドレスとソルトで発行したID側の秘密鍵と、両IDの公開鍵をアクセス元に返す。
数ビット分のハッシュ関数を知ってもIDを逆算は出来ないし、ID発行ノードも1ビットでは誰に発行したIDか判別できない。
ID発行ノードが変動したり消えたりした分はエラー訂正アルゴリズムである程度は吸収できる。
普通のDHT同様、その日の署名+ソルトのセットを切断前に他人に引き継ぐ仕組みも頑張れば実現できる…かな?
問題は投稿ごとのメタデータのサイズと処理で、N*2個の公開鍵とN個の署名をIDのためだけに付加しなければならない。
207デフォルトの名無しさん
2014/06/01(日) 16:46:20.09ID:nKywzM47 >>205
すまん、「架空のIPアドレスを持った(架空の)投稿者ノードからの投稿」だ。
2つ目の架空が抜けた。本当の投稿者が架空の投稿者をでっち上げて
「(架空の)投稿者から接続を受けた入り口ノード(本当は投稿者)です」
って振る舞う場合の話だから、(架空の)投稿者との間のIP接続なんて存在しない。
すまん、「架空のIPアドレスを持った(架空の)投稿者ノードからの投稿」だ。
2つ目の架空が抜けた。本当の投稿者が架空の投稿者をでっち上げて
「(架空の)投稿者から接続を受けた入り口ノード(本当は投稿者)です」
って振る舞う場合の話だから、(架空の)投稿者との間のIP接続なんて存在しない。
208デフォルトの名無しさん
2014/06/01(日) 17:13:12.29ID:la9nfNtQ >>206
投稿のたびに百個くらいのノードにIPアドレスを伝えちゃうと、あまり匿名にならない気がする。
投稿のたびに百個くらいのノードにIPアドレスを伝えちゃうと、あまり匿名にならない気がする。
209デフォルトの名無しさん
2014/06/01(日) 18:01:01.28ID:ahYmPm0r >>204
> 確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
> 根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
そもそも観測網を設置されないと絞り込めないなら匿名性としては十分ではないのか?
匿名性の目的は、身を守ることであると思うが
ネットワークが犯罪の温床となり、余計な捜査をされないように、との意図なら
「自分が書き込んだものではない」ことが証明出来ればよい。
そういう意味で匿名性を犠牲にしても、改ざんや成りすましを防ぐ方が重要。
加えて、確実なデータ削除の仕組みが必要。
スレ趣旨の「2ちゃん互換」は、プロトコル互換でもデータ互換でもなく
安心して楽しめる「コミュニティ形成の場」としての互換なんだろ?
> トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
十分なユーザー数に増えればオニオン系の方が良いとは思うが
ユーザーが増えなければ?
結局arpanetイメージに近いものになるのではないか?
> 確率的書き込みは投稿ルートが不定だと観測網を設置することで絞り込めるし、
> 根本的に物理ネットワーク上の近隣で盗聴されると一発で特定されちゃうから不便。
そもそも観測網を設置されないと絞り込めないなら匿名性としては十分ではないのか?
匿名性の目的は、身を守ることであると思うが
ネットワークが犯罪の温床となり、余計な捜査をされないように、との意図なら
「自分が書き込んだものではない」ことが証明出来ればよい。
そういう意味で匿名性を犠牲にしても、改ざんや成りすましを防ぐ方が重要。
加えて、確実なデータ削除の仕組みが必要。
スレ趣旨の「2ちゃん互換」は、プロトコル互換でもデータ互換でもなく
安心して楽しめる「コミュニティ形成の場」としての互換なんだろ?
> トラフィック効率的にも、素直にオニオンルーティング系使ったほうが良いと思う。
十分なユーザー数に増えればオニオン系の方が良いとは思うが
ユーザーが増えなければ?
結局arpanetイメージに近いものになるのではないか?
210デフォルトの名無しさん
2014/06/01(日) 18:46:07.18ID:gcY8NZuj 無限ループですな。
211デフォルトの名無しさん
2014/06/01(日) 18:46:13.59ID:iF6nhgL2 >>209
>結局arpanetイメージに近いものになるのではないか?
ま,そういうことだね
折れのイメージは arpanet + onion-routing + 通信文は一応の暗号化(鍵交換くらいでいいかと)
最後のはわりと重要で,ny がこれを実装しておれば寿命は数倍に延びたはず
>結局arpanetイメージに近いものになるのではないか?
ま,そういうことだね
折れのイメージは arpanet + onion-routing + 通信文は一応の暗号化(鍵交換くらいでいいかと)
最後のはわりと重要で,ny がこれを実装しておれば寿命は数倍に延びたはず
212デフォルトの名無しさん
2014/06/01(日) 18:48:02.28ID:nKywzM47 >>208
1日1回見に行けば十分だし、投稿しない人も見に行くようにすれば十分紛れると思う。
>>209
> 観測網を設置されないと絞り込めないなら匿名性としては十分
nyの例を見ればわかるが、ある程度普及すれば観測網が形成される。
観測網を設置すれば誰でも特定できる可能性があるってのは2chよりも弱くてちょっと痛い。
> 「自分が書き込んだものではない」ことが証明出来ればよい。
確率書き込みだとそれが証明できるっていう仕組みが分からんのだけど。
全員がリレーログを保持して提出できるようにするってことだとちょっと怖いな。
> 十分なユーザー数に増えればオニオン系の方が良いとは思うが
逆じゃね?確率書き込みだとユーザが少ないほうが観測ノードの効率が上がる。
オニオン系の場合も観測ノードの効率が上がるけど、中身は見えないからゴミ流したり時差つければOK。
1日1回見に行けば十分だし、投稿しない人も見に行くようにすれば十分紛れると思う。
>>209
> 観測網を設置されないと絞り込めないなら匿名性としては十分
nyの例を見ればわかるが、ある程度普及すれば観測網が形成される。
観測網を設置すれば誰でも特定できる可能性があるってのは2chよりも弱くてちょっと痛い。
> 「自分が書き込んだものではない」ことが証明出来ればよい。
確率書き込みだとそれが証明できるっていう仕組みが分からんのだけど。
全員がリレーログを保持して提出できるようにするってことだとちょっと怖いな。
> 十分なユーザー数に増えればオニオン系の方が良いとは思うが
逆じゃね?確率書き込みだとユーザが少ないほうが観測ノードの効率が上がる。
オニオン系の場合も観測ノードの効率が上がるけど、中身は見えないからゴミ流したり時差つければOK。
213デフォルトの名無しさん
2014/06/01(日) 18:48:38.24ID:tFz+suGd214デフォルトの名無しさん
2014/06/01(日) 18:51:52.51ID:gcY8NZuj 永久機関を開発しようとしてる感じ。
「匿名だけど固有のIDを振ろう」
おかしいでしょ?
「匿名だけど固有のIDを振ろう」
おかしいでしょ?
215デフォルトの名無しさん
2014/06/01(日) 19:07:21.01ID:iF6nhgL2216デフォルトの名無しさん
2014/06/01(日) 19:07:40.29ID:M8F9cK7q bitcoinってどういう仕組みなの?
217デフォルトの名無しさん
2014/06/01(日) 19:09:11.74ID:iF6nhgL2218デフォルトの名無しさん
2014/06/01(日) 19:37:58.08ID:BBvkueq8 匿名性も何もないテスト版でもいいから
実際に作って動けばもっと活発になるんじゃないか?
ブラウザ経由で書き込めるようにすればtorで書き込めばいいんで
これだけでも一応使い物になりそう
実際に作って動けばもっと活発になるんじゃないか?
ブラウザ経由で書き込めるようにすればtorで書き込めばいいんで
これだけでも一応使い物になりそう
219デフォルトの名無しさん
2014/06/01(日) 19:46:47.92ID:teanJBM8220デフォルトの名無しさん
2014/06/01(日) 19:50:12.14ID:G4lH3drR ここにいる人たちは>>1にあるp2p2chとかちらしの裏だとダメなの?
使ったうえで改良について話しているのか、それとも1から作り直すために話しているのか気になる
匿名性を気にしないってことならこれを改善していくってのが一番いいと思うんだけど
使ったうえで改良について話しているのか、それとも1から作り直すために話しているのか気になる
匿名性を気にしないってことならこれを改善していくってのが一番いいと思うんだけど
221デフォルトの名無しさん
2014/06/01(日) 20:14:39.39ID:nKywzM47222デフォルトの名無しさん
2014/06/01(日) 20:58:37.07ID:UK4nHX3P223デフォルトの名無しさん
2014/06/01(日) 22:08:41.46ID:juN6KTI5 >>221
×難読化リレ
○公開鍵暗号
残念だがK氏著書にもあるとおりが一度は検討したDH鍵共有は、単なる難読化ではない。
いわゆる公開暗号系に属するものであり、第三者には解読不可能
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89
クローラには弱い手法だから、あくまでも「遅らせるだけ」であったかもしれない。
クローラ対策は今のところチューリングテストしか思いつかない
×難読化リレ
○公開鍵暗号
残念だがK氏著書にもあるとおりが一度は検討したDH鍵共有は、単なる難読化ではない。
いわゆる公開暗号系に属するものであり、第三者には解読不可能
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89
クローラには弱い手法だから、あくまでも「遅らせるだけ」であったかもしれない。
クローラ対策は今のところチューリングテストしか思いつかない
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 小野田紀美・経済安保担当相「何か気に入らないことがあればすぐに経済的威圧をする国への依存はリスク」 ★2 [Hitzeschleier★]
- 日本行き空路49万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約32%に相当 ★2 [ぐれ★]
- 【中国局長】両国関係に「深刻な影響」 首相発言の撤回要求 [蚤の市★]
- 外務省局長は無言で厳しい表情…日中の高官協議終了か 高市首相“台湾”発言で中国が強硬対応 発言撤回求めたか…★3 [BFU★]
- 【インバウンド】中国人観光客の日本での消費額は年間約2兆円超…中国政府は公務員の出張取り消し [1ゲットロボ★]
- 日経平均の下落率3%超す、財政懸念で長期金利上昇 ★2 [お断り★]
- 【実況】博衣こよりのえちえち歌枠🧪
- 【高市速報】日本人の3割「中国への武力行使に踏み切る必要がある」ANN世論調査 [931948549]
- 高市早苗「支持者の理解を得られないので台湾発言を撤回できない」 [931948549]
- 外務省局長、よくわからないまま帰国へ [834922174]
- 中国外務省「日中関係の悪化は高市早苗首相が原因」と名指しで強く非難。キタ━(゚∀゚)━! [153490809]
- 【雑談】暇人集会所part18
