アカウント名:
パスワード:
携帯電話からの接続なんて携帯事業者のサーバーが間にプロキシみたいに入ってるんだし、送信するのを「契約者ＩＤ」じゃなくて「契約者ＩＤと送信先ドメインを足した値のハッシュ」にすればいいのに、と思うんだけど、面倒だからやらないのかしらね。もちろんハッシュ値が全ユーザーの間で一意になるような仕掛けは必要だから、インフラ側の構築はちょっと工夫が必要にはなりそうだけど。 これなら特定のドメインにアクセスした時の契約者ＩＤが他ドメインに漏洩したところで困らないし、特定ドメインの範疇であればユーザーとの紐付けは従来通り可能だからコンテンツビジネスにも殆ど影響を及ぼさないはず。少なくともユーザー情報をこっそり売り飛ばすところまで「ビジネス」としているようなところ以外は。
ハッシュはアルゴリズムによっては衝突することがありますよ。逆に、「一意でない値を何らかの方法でハッシュにかけたら必ず一意でなくなる」ことが保証されている場合、そのハッシュ関数は可逆性があることになるので親トピのような用途には不向きです。
固定長のハッシュは有限個のハッシュ値（2^ハッシュ長）しかもてないのに対し、ハッシュをかけるべきデータは理論上無限なのですからハッシュの衝突はどのようなアルゴリズムを用いても避けられないでしょう。# 固定長じゃないものをハッシュって言うんですかね?
送信先はIPアドレス空間全部より広い可能性はありますよ。ネームベースのバーチャルサーバはあるし、サーバ単位で送信先のドメインを切っていいとは限らない（rakuten.co.jp内に無数のショップがあるように）。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
対案というか…… (スコア:2)
携帯電話からの接続なんて携帯事業者のサーバーが間にプロキシみたいに入ってるんだし、送信するのを「契約者ＩＤ」じゃなくて「契約者ＩＤと送信先ドメインを足した値のハッシュ」にすればいいのに、と思うんだけど、面倒だからやらないのかしらね。もちろんハッシュ値が全ユーザーの間で一意になるような仕掛けは必要だから、インフラ側の構築はちょっと工夫が必要にはなりそうだけど。
これなら特定のドメインにアクセスした時の契約者ＩＤが他ドメインに漏洩したところで困らないし、特定ドメインの範疇であればユーザーとの紐付けは従来通り可能だからコンテンツビジネスにも殆ど影響を及ぼさないはず。少なくともユーザー情報をこっそり売り飛ばすところまで「ビジネス」としているようなところ以外は。
Re: (スコア:0)
そんなのいらないよ。ハッシュすれば一意。
Re: (スコア:0)
ハッシュはアルゴリズムによっては衝突することがありますよ。
逆に、「一意でない値を何らかの方法でハッシュにかけたら必ず一意でなくなる」ことが保証されている場合、そのハッシュ関数は可逆性があることになるので親トピのような用途には不向きです。
Re: (スコア:0)
いいえ。暗号学的ハッシュ関数は、衝突しません。
（まさかハッシュテーブル用のハッシュ関数を使うわけがないですよね。）
Re: (スコア:0)
固定長のハッシュは有限個のハッシュ値（2^ハッシュ長）しかもてないのに対し、ハッシュをかけるべきデータは理論上無限なのですからハッシュの衝突はどのようなアルゴリズムを用いても避けられないでしょう。
# 固定長じゃないものをハッシュって言うんですかね?
Re: (スコア:0)
Re:対案というか…… (スコア:0)
送信先はIPアドレス空間全部より広い可能性はありますよ。
ネームベースのバーチャルサーバはあるし、サーバ単位で送信先のドメインを切っていいとは限らない（rakuten.co.jp内に無数のショップがあるように）。