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