アカウント名:
パスワード:
先日下院を通過した SPY ACT法案では、このサードパーティクッキーなどによる情報収集を違法としてします。
もしセキュリティベンダーのコンピュータ・アソシエイ [mycom.co.jp]
セキュリティと利便性は相反するものですから、 良い悪いの問題とは少し違いますし、 「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
「セキュリティと利便性は常に相反する」は偽です。 なぜなら、 「セキュリティを維持したまま利便性を増大させる方法が存在する」場合もあるからです。
実際今回のケースはタレコミにあるように「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。「不作為の責任」というやつですか。
非公式サイト側のURL、ドメインやサーバ、IPアドレスその他は サイト運営側の都合でドコモが認識し得ない範囲を超えて変わりうるものです。
同一のサービスはドメイン名を変更しないべきです。ドメイン名が変わるなら、別のサービスとして登録手順からやりなおすのが元々当然です。
すべての対象サイトへのIDの全体としての唯一性は保証するの？
ID内にドメイン名を含ませればよい。インターネットのプロトコルはよくそれを採用していますね。SIPとかでもそう。
などの論議をなしに「これが解決
「べき」で言い始めたらキリがありません。 水掛け論を持ち出しても無駄でしょう。
良い悪いの問題ではないことを理解するっていつも難しい。
全く利便性を失わずに安全性を上げられる方法があるとしたらセキュリティ技術者は必要ありません。
あなたが言うのは、セキュリティ管理者のことでは？ 技術力が無くて管理するだけのセキュリティ事務員。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
要は permanent cookie ねぇ (スコア:1)
これはいわば個人情報を提供させるのだから、デフォルトで開示ではなく、事前に顧客に許可を取るのがスジでは？ それをしないという事は、やはり利用者の便宜というよりビジネス上の益になるからという判断でしょうね。
Re: (スコア:0)
Re: (スコア:2, すばらしい洞察)
その機能はプライバシーの問題があるとも思われます、
だから利用者の方には許可を取ります、
という話であれば
デフォルトではその機能はOFFにしておき利用者への周知のレスポンスとして
利用者自身の手でONにする、が基本です。
今回はそうではなくデフォルトがONのようですから、
利用者の許可を取る取らないの次元ではなく
ドコモ側の都合で可能な限り有効にする機能として導入しますと受け取るべきです。
もちろん、それが良い悪いかはまた別の問題。
Re: (スコア:3, 興味深い)
もしセキュリティベンダーのコンピュータ・アソシエイ [mycom.co.jp]
Re: (スコア:1)
良い悪いの問題とは少し違いますし、
「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
ただ、それ以前の次元で言えることとして、
たとえばサブスクライバIDというもので同列に扱われることの多いauは、
基本開けていた。その後セキュリティに配慮して閉じられるようにした。
でも基本開けていたポリシーだったし、デフォルトは開いている、閉じたい人は明示的に自分で閉じる。
これはポリシーとして一貫しており、良い悪いの問題とは別の次元で分かりやすい状況です。
(本件に限って言えば)ド
Re:要は permanent cookie ねぇ (スコア:2, すばらしい洞察)
「セキュリティと利便性は常に相反する」は偽です。
なぜなら、 「セキュリティを維持したまま利便性を増大させる方法が存在する」場合もあるからです。
実際今回のケースはタレコミにあるように「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。「不作為の責任」というやつですか。
Re:要は permanent cookie ねぇ (スコア:1)
>「送信先サイトごとに別のIDが送信されるようにする」という方法があるわけでしょ。
これがすでに「利便性を落とす」要素を含んでいることは
上で他の方が論議されているところを見ても明らかです。
非公式サイト側のURL、ドメインやサーバ、IPアドレスその他は
サイト運営側の都合でドコモが認識し得ない範囲を超えて変わりうるものです。
それらを超越して「同じサイト運営者のサイトであれば個別のIDを送信する」が実装できるでしょうか？
その負荷は？すべての対象サイトへのIDの全体としての唯一性は保証するの？
(対象サイトのURLが変わったら過去の他の利用者と重複した、なんてのも問題のタネですね)
などの論議をなしに「これが解決策だ」と言っても無意味です。
そしていくら議論しようが、実装には手間暇も負荷も面倒もかかることは事実として残ります。
>解決策があるのに対策せずに「セキュリティと利便性は相反するものですから」と
>思考停止するのは、「良い悪いの問題」で言えば、悪いことですね。
>「不作為の責任」というやつですか。
上記の通り、論議もなしに一方的に「これが解決策だ」と言っても無駄なんです。
だからこそ
>「問題が起こったらどうするんだ」「利便性が落ちたらどうするんだ」は正直水掛け論になりがちです。
と書いておきました。
実際水掛け論になってますね、私とあなたで。
良い悪いの問題ではないことを理解するっていつも難しい。
Re: (スコア:0)
「セキュリティと利便性は相反する」ってのは一番の基本だと思います。
というか、どこかを絞って安全を得るのがセキュリティなわけですから、
全く利便性を失わずに安全性を上げられる方法があるとしたらセキュリティ技術者は必要ありません。
「利便性」をユーザーの一極で考えると見た目上手間が変わらないように見えることもあるのでしょうけど、
セキュリティにおいては利便性はユーザーだけでなくサービス提供者、さらには見知らぬ第三者など考えうる全員の利便性も考慮に入れるものなのですから。
Re: (スコア:0)
同一のサービスはドメイン名を変更しないべきです。ドメイン名が変わるなら、別のサービスとして登録手順からやりなおすのが元々当然です。
ID内にドメイン名を含ませればよい。インターネットのプロトコルはよくそれを採用していますね。SIPとかでもそう。
Re:要は permanent cookie ねぇ (スコア:1)
あらかじめ「水掛け論になります」
と言った自分に対して水掛け論を持ち出しても無駄でしょう。
良い悪いの問題ではないことを理解するっていつも難しい。
Re: (スコア:0)
安全を無視するのは悪いことですよ。
ていうか「良い悪いの問題ではない」って意味不明なんですが、そう言っていると何か満足できるの？
Re: (スコア:0)
youtubeやニコニコ動画に同じ事を言えますか？
Re: (スコア:0)
2つのドメイン名を使う場合は、初回登録時に両方に対して登録処理をすればいいだけの話。
Re: (スコア:0)
Re: (スコア:0)
で、ドメイン名をいくつ使っているというのですか？
Re: (スコア:0)
Re: (スコア:0)
あなたが言うのは、セキュリティ管理者のことでは？
技術力が無くて管理するだけのセキュリティ事務員。
Re: (スコア:0)
なるほど、そういう考え方もあるのかと思った。
おそらくは、たとえば弱い暗号鍵を新しい暗号鍵で置き換えるケースなどを想定されているのかもしれませんが
実はそういう場合でも往々にして「計算速度」という形で利便性は下がっているのです。
Re:要は permanent cookie ねぇ (スコア:2, すばらしい洞察)