アカウント名:
パスワード:
フィッシングドメインからのホモグラフ電子メールアドレスとアドレス帳のホモグラフ対象メールアドレスとを文字列判定をせず画像判定していますってことなんですかね？
# なかのこびとさんもたいへんだんだよー
正規化処理を挟んでるんじゃないかと思うけど、なぜそこに入れた? という疑問が。
そりゃ、例えば日本だとメールアドレスを全角で登録するような人がいるから、でしょ。
たとえメールアドレスに全角を入れたとしても、よく似た文字を使った別のメールアドレスを同じものとして扱う必要は一切ないんだが。同一視するのがうれしいケースがあるとすれば、手入力した文字列でメールアドレスを検索するときくらい。文字列検索用のロジックをメールアドレスの同一判定にまで適用する意味があるのはどういう時なのか知りたい。
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。だから、校合はともかく必要なの。
で、受信者の正規化のアルゴリズムと送信者の正規化のアルゴリズムが違っている場合は、このストーリーみたいな話が起こりうる。手書きとかOCRとか、そういう問題ではないと思うよ。
必要なのはそうだけど、どうなってたら一致と見做すかはメールの規格で決まってるんだから、それ用のアルゴリズムを使ったら良い話ですよね。やり方は、メールサーバを作ったことがあるような企業だったらどこでも知ってるはず。
あるいは元々そうしてたけど、アホなユーザから「アドレス帳に(全角英数字で)入れてるのが候補に出ないんだけど!」とクレームが来て、ユーザ本位な企業体質から言われるままに対応しちゃったとかですかね。
…それよりは、最初からメールアドレスの仕様も何も考えず、とりあえず何かやるときは使うことになってる「アプリ組み込みタイプのAccessDBライブラリ」をそのまま持って来ちゃってて、その万能過ぎる検索性能のせいでやらかす仕様になってたのが後々問題になって来た、という方がありそうですかね。
まぁこの件はMSの実装がオカシイだけですね。
なんというか iso-8859 系話者は case-insensitive な文字列比較が好きなんだけど、それと同様に似た文字を合致させる(ウムラウトを無視してヒットさせたりする）機能をドメイン名にまで何も考えずに適用してしまっているんでしょうね。
Google検索でもウムラウトとか無視して検索してくれますからね。我々みたいなウムラウトってどうやって入力するんだ、みたいな人からすると便利っちゃあ便利な時はあるんだけども。
個人的にこれ系の実装でいままで一番びっくりしたのは寿司＝ビール問題とかよりもOracle のパスワード比較で case-insensitive だったところですね…
Oracle使うユーザーは昔のやつ一切手を入れずそのまま動かせるのが条件みたいなのが多いから…
一文字でも変更必要だと、それにかかる費用を請求するから担当呼べ！とマジで逝ってると思えるヤツも実際いたし。
セキュリティ的な問題を無視して互換重視みたいなのは設定で切り替えできるようになってると良いな。
Oracleについては、いまはそうなってますね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
すげー実装だ (スコア:1)
フィッシングドメインからのホモグラフ電子メールアドレスと
アドレス帳のホモグラフ対象メールアドレスとを
文字列判定をせず
画像判定しています
ってことなんですかね？
# なかのこびとさんもたいへんだんだよー
Re: (スコア:0)
正規化処理を挟んでるんじゃないかと思うけど、なぜそこに入れた? という疑問が。
Re: (スコア:0)
そりゃ、例えば日本だとメールアドレスを全角で登録するような人がいるから、でしょ。
Re: (スコア:0)
たとえメールアドレスに全角を入れたとしても、よく似た文字を使った別のメールアドレスを同じものとして扱う必要は一切ないんだが。
同一視するのがうれしいケースがあるとすれば、手入力した文字列でメールアドレスを検索するときくらい。
文字列検索用のロジックをメールアドレスの同一判定にまで適用する意味があるのはどういう時なのか知りたい。
Re: (スコア:2, 参考になる)
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。だから、校合はともかく必要なの。
で、受信者の正規化のアルゴリズムと送信者の正規化のアルゴリズムが違っている場合は、このストーリーみたいな話が起こりうる。手書きとかOCRとか、そういう問題ではないと思うよ。
Re: (スコア:0)
必要なのはそうだけど、どうなってたら一致と見做すかはメールの規格で決まってるんだから、それ用のアルゴリズムを使ったら良い話ですよね。
やり方は、メールサーバを作ったことがあるような企業だったらどこでも知ってるはず。
あるいは元々そうしてたけど、アホなユーザから「アドレス帳に(全角英数字で)入れてるのが候補に出ないんだけど!」とクレームが来て、
ユーザ本位な企業体質から言われるままに対応しちゃったとかですかね。
…それよりは、最初からメールアドレスの仕様も何も考えず、
とりあえず何かやるときは使うことになってる「アプリ組み込みタイプのAccessDBライブラリ」をそのまま持って来ちゃってて、
その万能過ぎる検索性能のせいでやらかす仕様になってたのが後々問題になって来た、という方がありそうですかね。
Re: (スコア:2)
まぁこの件はMSの実装がオカシイだけですね。
なんというか iso-8859 系話者は case-insensitive な文字列比較が好きなんだけど、
それと同様に似た文字を合致させる(ウムラウトを無視してヒットさせたりする）
機能をドメイン名にまで何も考えずに適用してしまっているんでしょうね。
Google検索でもウムラウトとか無視して検索してくれますからね。
我々みたいなウムラウトってどうやって入力するんだ、
みたいな人からすると便利っちゃあ便利な時はあるんだけども。
個人的にこれ系の実装でいままで一番びっくりしたのは寿司＝ビール問題とかよりも
Oracle のパスワード比較で case-insensitive だったところですね…
[Q][W][E][R][T][Y]
Re:すげー実装だ (スコア:0)
Oracle使うユーザーは昔のやつ一切手を入れずそのまま動かせるのが条件みたいなのが多いから…
一文字でも変更必要だと、それにかかる費用を請求するから担当呼べ！とマジで逝ってると思えるヤツも実際いたし。
Re: (スコア:0)
セキュリティ的な問題を無視して互換重視みたいなのは設定で切り替えできるようになってると良いな。
Re:すげー実装だ (スコア:1)
Oracleについては、いまはそうなってますね
[Q][W][E][R][T][Y]