アカウント名:
パスワード:
どうせスラドはtype="text" でお茶を濁すんやろ？
いちおう、https://m.srad.jp を見る限り、とっくに証明書を取得しているみたいなんですけどねぇ。なぜ本サイトをなかなかHTTPSに移行しないのか。それとも将来的にm.sradに一本化する予定なんだろうか。
契約している広告主や広告配信事業者に、https (TLS) な広告コードを提供していない会社（リンク先ページが 平文HTTPで、Referer でクリック解析をしたい事業者を含む）が存在するからではないでしょうか。ざっと見た限り、スラド（PC版）は、広告コードが HTTPS に対応してなかったと思われる広告配信事業者とも提携しているようです（最新の状況を確認したわけではなく確証がないので、業者名は書かないでおきます）。
なお、以前は Google AdSense も https だと広告収入がだいぶ減ってしまった（HTTPS非対応の広告がオークションにかけられず、広告単価が下がってしまうため）のですが、最近では状況がかなり改善されてきています。
# 私のとあるサイトも、月極広告の広告主のサイト（リンク先）が 平文HTTPで、かつ広告主が Google アナリティクス を使って Referer をもとにクリック数や広告成果の解析をしているので、https に移行できないでいます（HTTPS → HTTP では原則 Referer が飛ばないため）。 # meta name="referrer" [impressrd.jp] に IEが対応してくれていれば、状況は違ったのですが……。
なるほど、納得です。解説ありがとうございます。そういえば先日、広告のネタでこんなツリー [it.srad.jp]がありましたが、腑に落ちました。「Refereでの情報収集をやめる」と言わずに「広告を暗号化する」と表現するとは、なにか姑息ですね。
仮に通常状態ではHTTPのままにしたいのだとして、ならば、ログインページだけHTTPSにして、セッションクッキーをHTTPに取り回すのではだめなのでしょうか。
ログインページだけHTTPSにして、セッションクッキーをHTTPに取り回すのではだめなのでしょうか。
その方式であれば、広告が制約されるのはログイン画面（やパスワード変更画面など）だけになるので、「広告主も対応してくれないと https への移行は難しい」という問題は生じません。
ID（メールアドレス）とパスワードを入力するページとフォームの送信先を HTTPS にしておけば、ID（メールアドレス）とパスワードを守ることができるので、ユーザーがそれらを使いまわしした場合の危険性が軽減するというメリットがあります。
# 当然ですが、守れるのはIDとパスワードだけなので、通信が傍受・改竄可能な場合、セッションが乗っ取られる危険があります。
そこは実装である程度回避できる。
ログイン時に発行するcookieに、secure属性を持たせたセッションIDだけでなく、secure属性を持たせないセッションIDの代替になるトークンも同時に書き込めばいい。通常画面はトークンを使ってユーザーを認証し、書き込み時のpost先やユーザー情報編集ページはhttps必須にしてそこだけセッションIDを認証すれば乗っ取りは防げる。トークンは平文で流れるから盗聴可能だけど、センシティブな部分に使わないようきちんと実装すればユーザーセッションを乗っ取ることを防ぎつつメイン画面はhttpで取り回せる。
サイトによっては使えない方法だけど、スラドとかならそれでいいんじゃないかな。
いや、スラドでもダメだろ。メアドとかが漏れる問題は解決できない。個人情報を普通にGETしてるんだから、そんな幻想は捨てた方がいいよ。
すべてのページに(非表示の)ログインフォームがあるのでトップページから警告が出てるんだよね。そのプランで行くならログインページ以外からログインフォームを撤去する必要がある
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
どうせスラドは (スコア:0)
どうせスラドは
type="text" で
お茶を濁すんやろ？
Re:どうせスラドは (スコア:1)
いちおう、https://m.srad.jp を見る限り、とっくに証明書を取得しているみたいなんですけどねぇ。
なぜ本サイトをなかなかHTTPSに移行しないのか。
それとも将来的にm.sradに一本化する予定なんだろうか。
広告主も対応してくれないと https への移行は難しい (スコア:4, すばらしい洞察)
契約している広告主や広告配信事業者に、https (TLS) な広告コードを提供していない会社（リンク先ページが 平文HTTPで、Referer でクリック解析をしたい事業者を含む）が存在するからではないでしょうか。ざっと見た限り、スラド（PC版）は、広告コードが HTTPS に対応してなかったと思われる広告配信事業者とも提携しているようです（最新の状況を確認したわけではなく確証がないので、業者名は書かないでおきます）。
なお、以前は Google AdSense も https だと広告収入がだいぶ減ってしまった（HTTPS非対応の広告がオークションにかけられず、広告単価が下がってしまうため）のですが、最近では状況がかなり改善されてきています。
# 私のとあるサイトも、月極広告の広告主のサイト（リンク先）が 平文HTTPで、かつ広告主が Google アナリティクス を使って Referer をもとにクリック数や広告成果の解析をしているので、https に移行できないでいます（HTTPS → HTTP では原則 Referer が飛ばないため）。
# meta name="referrer" [impressrd.jp] に IEが対応してくれていれば、状況は違ったのですが……。
Re:広告主も対応してくれないと https への移行は難しい (スコア:2)
なるほど、納得です。解説ありがとうございます。
そういえば先日、広告のネタでこんなツリー [it.srad.jp]がありましたが、腑に落ちました。
「Refereでの情報収集をやめる」と言わずに「広告を暗号化する」と表現するとは、なにか姑息ですね。
Re:広告主も対応してくれないと https への移行は難しい (スコア:2)
仮に通常状態ではHTTPのままにしたいのだとして、ならば、ログインページだけHTTPSにして、セッションクッキーをHTTPに取り回すのではだめなのでしょうか。
Re:広告主も対応してくれないと https への移行は難しい (スコア:2)
その方式であれば、広告が制約されるのはログイン画面（やパスワード変更画面など）だけになるので、「広告主も対応してくれないと https への移行は難しい」という問題は生じません。
ID（メールアドレス）とパスワードを入力するページとフォームの送信先を HTTPS にしておけば、ID（メールアドレス）とパスワードを守ることができるので、ユーザーがそれらを使いまわしした場合の危険性が軽減するというメリットがあります。
# 当然ですが、守れるのはIDとパスワードだけなので、通信が傍受・改竄可能な場合、セッションが乗っ取られる危険があります。
Re: (スコア:0)
そこは実装である程度回避できる。
ログイン時に発行するcookieに、secure属性を持たせたセッションIDだけでなく、secure属性を持たせないセッションIDの代替になるトークンも同時に書き込めばいい。
通常画面はトークンを使ってユーザーを認証し、書き込み時のpost先やユーザー情報編集ページはhttps必須にしてそこだけセッションIDを認証すれば乗っ取りは防げる。
トークンは平文で流れるから盗聴可能だけど、センシティブな部分に使わないようきちんと実装すればユーザーセッションを乗っ取ることを防ぎつつメイン画面はhttpで取り回せる。
サイトによっては使えない方法だけど、スラドとかならそれでいいんじゃないかな。
Re: (スコア:0)
いや、スラドでもダメだろ。メアドとかが漏れる問題は解決できない。個人情報を普通にGETしてるんだから、そんな幻想は捨てた方がいいよ。
Re: (スコア:0)
すべてのページに(非表示の)ログインフォームがあるのでトップページから警告が出てるんだよね。そのプランで行くならログインページ以外からログインフォームを撤去する必要がある