アカウント名:
パスワード:
SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけでいきなり廃止というわけにはいかない事情もあったと思います。私が関わった部分だけでもサイトの改修だけでなく紐付けられているDBとの内容(アドレスがかわることで取得できるIDやなんかがかわったりとか)とか、経路を構築している場合はネットワークの改修も必要になったりかなり多岐に渡ります。比較的新しいものであればいいのですが、老舗のサイトとかになると一から作り直したほうが早いくらいというところもあったりもしました。
実際問題として諸事情によりこの改修に対応出来ないサイトもあり、申請をすれば継続して従来の方式を取ることも出来たと思います。
一度定着してしまったものを改修するとなるとそれなりのスパンが必要になるのは致し方ないことかと思います。
>SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけで>いきなり廃止というわけにはいかない事情もあったと思います。
今回の場合、課金・決済において致命的な問題であったうえ、利用者への案内なども非常に少ない(ゼロ?)ものでした。利用者は自衛手段を取る権利も自己チェックを行う権利も与えられなかったわけです。それを「いきなり廃止というわけにはいかない事情も」で擁護するのは厳しいでしょう。
少なくとも、ソフトバンクの公式発表として「詳しくは公開できないが、現時点でソフトバンクの回線には脆弱
CP向けの情報なので公にはできないのでここでいうことはできないのですが・・・。確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは認証の関連からそれはありえないです。
この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、既存のIDやアカウント情報や課金情報を全て使えない状態になることが考えられます。キャリアの事情を察する必要はありませんが、コンテンツプロバイダー側としてはこれらを含めてすぐに変更というのは厳しいのはお分かりいただけるのではないかと思います。利用者への
>どうせどんな対策取ったって文句はいうんでしょ?
不備の責任がある主体にはクレームが入ります。それは当たり前でクレーム自体ゼロを前提にするなんてほうが異常です。その上で、不備への対応のやり方でクレームの度合いは大きく変わりますよね。今回の件は最悪の一つでしょう。
>確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは>認証の関連からそれはありえないです。>>この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、>既存のIDやアカウント情報や課金情報を全て使えない状態になることが考え
ところで、Softbankのデコードしたサーバーから、自前のコンテンツを置いているサーバーは、専用線ではなく、INTERNET接続だって前提は、本当なのでしょうか。
文句言っている人は確信があるみたいな書き方だけど、専用線で他から見られないなら、httpsをデコードしても何の問題もないはずですよね?
専用線で他から見られないなら、httpsをデコードしても何の問題もないはずですよね?
何の脆弱性だったのか、まるで理解してないのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
確かに時間はかかったかもしれませんが (スコア:5, 興味深い)
SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけで
いきなり廃止というわけにはいかない事情もあったと思います。
私が関わった部分だけでもサイトの改修だけでなく紐付けられているDBとの内容(アドレスがかわることで取得できるIDやなんかがかわったりとか)とか、
経路を構築している場合はネットワークの改修も必要になったりかなり多岐に渡ります。
比較的新しいものであればいいのですが、老舗のサイトとかになると一から作り直したほうが早いくらいというところもあったりもしました。
実際問題として諸事情によりこの改修に対応出来ないサイトもあり、申請をすれば継続して従来の方式を取ることも出来たと思います。
一度定着してしまったものを改修するとなるとそれなりのスパンが必要になるのは致し方ないことかと思います。
Re: (スコア:3, すばらしい洞察)
>SoftBankなどで公式の課金や認証を運営しているサイトはこちらのアドレスを経由するようになっているわけで
>いきなり廃止というわけにはいかない事情もあったと思います。
今回の場合、課金・決済において致命的な問題であったうえ、
利用者への案内なども非常に少ない(ゼロ?)ものでした。
利用者は自衛手段を取る権利も自己チェックを行う権利も与えられなかったわけです。
それを「いきなり廃止というわけにはいかない事情も」で擁護するのは厳しいでしょう。
少なくとも、ソフトバンクの公式発表として
「詳しくは公開できないが、現時点でソフトバンクの回線には脆弱
Re: (スコア:1, 興味深い)
CP向けの情報なので公にはできないのでここでいうことはできないのですが・・・。
確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは認証の関連からそれはありえないです。
この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、既存のIDやアカウント情報や課金情報を全て使えない状態になることが考えられます。
キャリアの事情を察する必要はありませんが、コンテンツプロバイダー側としてはこれらを含めてすぐに変更というのは厳しいのはお分かりいただけるのではないかと思います。
利用者への
Re: (スコア:1, 興味深い)
>どうせどんな対策取ったって文句はいうんでしょ?
不備の責任がある主体にはクレームが入ります。
それは当たり前でクレーム自体ゼロを前提にするなんてほうが異常です。
その上で、不備への対応のやり方でクレームの度合いは大きく変わりますよね。
今回の件は最悪の一つでしょう。
>確かにキャリアの事情を考慮する必要はないですが、httpsを使わないようにするというのは
>認証の関連からそれはありえないです。
>
>この場合の防御策としてSoftBankのhttpsを使用しないようにするということであれば、
>既存のIDやアカウント情報や課金情報を全て使えない状態になることが考え
Re: (スコア:0)
ところで、Softbankのデコードしたサーバーから、自前のコンテンツを置いているサーバーは、専用線ではなく、INTERNET接続だって前提は、本当なのでしょうか。
文句言っている人は確信があるみたいな書き方だけど、専用線で他から見られないなら、httpsをデコードしても何の問題もないはずですよね?
Re: (スコア:0)
何の脆弱性だったのか、まるで理解してないのでは?
Re:確かに時間はかかったかもしれませんが (スコア:0)