アカウント名:
パスワード:
動いて居るものが公開されて居るものと確実に一致しているって確認方法が確立されてからの話。サービスだけを使っていると厳密な確認は出来ない。それとも、「政府用バックドア付きバージョン」とか、ちゃんと表示してくれると思って居るのだろうか?ソースを取り寄せた所で、相手は元々超法規的にやっている訳で何の保証にもならないだろうに。
実は政府機関への営業のつもりなんだろうか?
ソースを取り寄せて、自分でコンパイルすればおk。
そりゃ、自分の家でサーバたちあげて自分と知人だけ使うメールサービスにするなら構いませんけどね。
だから併せて、プライベートクラウドを提案しているんでしょう。自分の社内でサーバたちあげて、社員と客先だけ使うメールサービスにしよう、と。
個人や自社で政府からの要求を断るのは相当に難しいのでは?大会社がプロバイダとしてプライバシーを盾にしても断れないのを自社で断れるとは思えないのだけど。挙句、接続プロバイダは信用できない情況で使わざるを得ないのですが。
「政府からの情報提供要求を拒めるか?」に、使用しているソフトがOSSであるかどうかは関係無い。必用なのは「法的に開示を行わないで良い名目」だろ。その名目が立たなきゃ個人や中小企業なんて何も抵抗は出来ないよ。
単純に、こちら側にソースコードがあれば、そういうバックドアとかサーバサイドでの情報収集を回避する手段は色々あると思うんですが(´・ω・`)
例えば、クラウドの場合なら、スマートカードとか手元の何か(場合によっては秘密鍵を入れたメモリカードでもよい)がないと復号ができないような暗号手順や擬似乱数によるダミーデータをサーバが要求するものに上乗せしてからサーバに送信するような独自のプロトコルを構築できたりもしますよ。
# これだけでも完璧ではないけど、P2Pと組み合わせたら結構面白いことになりそう。
そもそも、バイナリだけの供給の場合にはバックドアは避けられない(例えば、スマートフォン版のFacebookクライアントとか完全にそういう挙動だし)し、コードが暗号化などの難読措置をされてる上にリバースエンジニアリングがライセンス違反になる場合が大半じゃないですかね。
要は、ユーザなどの第三者によるクライアントサイドの監査や修正が働かない。この監査が働くだけでも、オープンソースのアドバンテージはあると思いますよ。
当人の預り知らぬところで開示されるからスパイ行為なんでしょ?見せろって言われて見せるのとは訳が違う。見せろって言われる場合はその理由を聞いたりできるだろうし。なんの容疑もかかってないのに開示されていい気はしない。
必用(sic)なのは「法的に開示を行わないで良い名目」だろ。
これはアメリカの話なのかもしれませんが、日本国では憲法第二十一条に反する法律はあり得ないという建前なので、それで十分な気がしますが、いかがでしょうか。
そういう意味では、FSF的に正しいソフトウェア利用の形というものは、オンプレミスで動作しなければ(できなければ)いけないというのはもちろん、運用面でもオンプレミスで行われるべき、ということなんでしょうなぁ。SaaSなんて以ての外。# そうでないと、根本的な目的である「ソフトウェアをユーザーのコントロール下に置く」事ができないから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
それは (スコア:0)
動いて居るものが公開されて居るものと確実に一致しているって確認方法が確立されてからの話。
サービスだけを使っていると厳密な確認は出来ない。
それとも、「政府用バックドア付きバージョン」とか、ちゃんと表示してくれると思って居るのだろうか?
ソースを取り寄せた所で、相手は元々超法規的にやっている訳で何の保証にもならないだろうに。
実は政府機関への営業のつもりなんだろうか?
Re: (スコア:0)
ソースを取り寄せて、自分でコンパイルすればおk。
Re: (スコア:0)
そりゃ、自分の家でサーバたちあげて自分と知人だけ使うメールサービスにするなら構いませんけどね。
Re:それは (スコア:0)
だから併せて、プライベートクラウドを提案しているんでしょう。
自分の社内でサーバたちあげて、社員と客先だけ使うメールサービスにしよう、と。
Re: (スコア:0)
個人や自社で政府からの要求を断るのは相当に難しいのでは?
大会社がプロバイダとしてプライバシーを盾にしても断れないのを自社で断れるとは思えないのだけど。
挙句、接続プロバイダは信用できない情況で使わざるを得ないのですが。
「政府からの情報提供要求を拒めるか?」に、使用しているソフトがOSSであるかどうかは関係無い。
必用なのは「法的に開示を行わないで良い名目」だろ。
その名目が立たなきゃ個人や中小企業なんて何も抵抗は出来ないよ。
Re:それは (スコア:1)
単純に、こちら側にソースコードがあれば、そういうバックドアとかサーバサイドでの情報収集を回避する手段は色々あると思うんですが(´・ω・`)
例えば、
クラウドの場合なら、スマートカードとか手元の何か(場合によっては秘密鍵を入れたメモリカードでもよい)がないと復号ができないような暗号手順や擬似乱数によるダミーデータをサーバが要求するものに上乗せしてからサーバに送信するような独自のプロトコルを構築できたりもしますよ。
# これだけでも完璧ではないけど、P2Pと組み合わせたら結構面白いことになりそう。
そもそも、バイナリだけの供給の場合にはバックドアは避けられない(例えば、スマートフォン版のFacebookクライアントとか完全にそういう挙動だし)し、コードが暗号化などの難読措置をされてる上にリバースエンジニアリングがライセンス違反になる場合が大半じゃないですかね。
要は、ユーザなどの第三者によるクライアントサイドの監査や修正が働かない。
この監査が働くだけでも、オープンソースのアドバンテージはあると思いますよ。
Re: (スコア:0)
当人の預り知らぬところで開示されるからスパイ行為なんでしょ?
見せろって言われて見せるのとは訳が違う。
見せろって言われる場合はその理由を聞いたりできるだろうし。
なんの容疑もかかってないのに開示されていい気はしない。
Re: (スコア:0)
Re: (スコア:0)
必用(sic)なのは「法的に開示を行わないで良い名目」だろ。
これはアメリカの話なのかもしれませんが、日本国では憲法第二十一条に反する法律はあり得ないという建前なので、それで十分な気がしますが、いかがでしょうか。
Re: (スコア:0)
そういう意味では、FSF的に正しいソフトウェア利用の形というものは、
オンプレミスで動作しなければ(できなければ)いけないというのはもちろん、
運用面でもオンプレミスで行われるべき、ということなんでしょうなぁ。SaaSなんて以ての外。
# そうでないと、根本的な目的である「ソフトウェアをユーザーのコントロール下に置く」事ができないから。