アカウント名:
パスワード:
メールサーバ間でのTLS通信というのは勿論やらないよりはマシですが、NSAやスパイ組織などがメールを盗み見ようとした場合、メールサーバの管理者に圧力をかけたり、スパイを紛れ込ましたり、メールサーバにバックドアをしかけたりして、メールの内容を盗み見ようとするでしょうから、根本的な対策にはなりません。また、相手がメールサーバから平文のPOP3やIMAPなどでメールを受信していたら、その部分が脆弱なことには変わりないし、メールサーバの管理者がメールを盗み見ることが可能なのには変わりありません。
従って、根本的な対策として PGP や S/MIME 対応をするべきです。しかし、フリーソフトのMUAでもPGPやS/MIME対応が数多くあるというのに、いつまでたっても Android 版 Gmail クライアントは、PGP にも S/MIME にも対応する気がないようです。
きっと、メールの内容を読み取って、それに関連した広告を表示させて金儲けをしているGoogle のことですから、PGP や S/MIME といったまともな End-To-End 暗号化を普及させてしまったら大幅な収益源となることから（メールの内容に関連した広告とそうでない広告では、明らかにクリック率に違いが出ます）、普及させる気がないんでしょうね。
2014年06月04日にメールを「End-To-End」で暗号化するGoogle公式拡張機能が開発中 [gigazine.net]だという話がありましたが、1年半近く経っているのに、未だに正式版がリリースされません（そもそも、「拡張」ではなく「標準」で Android 版 Gmail MUA などに実装すべき性質のものだと思いますが、メール内容に関連した広告を表示させたい Google には難しいのでしょう）。他社のメールサーバがメールサーバ間でのTLS通信に対応していないことに文句を言う前に、自社のクライアントアプリ（Android 版 Gmail アプリなど）を PGP や S/MIME に対応させていただきたいものです（S/MIME 署名にも対応していない現状では、フィッシング詐欺メールも見分けにくいという実害が出ていますね……）。
もし「PGPやりたくない」という本音がGoogleにあったとして、一億歩譲ってそれを認めたとしても、S/MIME署名にも対応しないことで「smime.p7sという謎のファイルが気持ち悪い」という風評被害を広めたことは許せないですな。ちなみにGMail以外のWebメールサービスがPGPやS/MIMEに対応しなかったのは怠慢以外の何者でもないのでこれも万死に値する。
S/MIME と web メールは相性が悪いのですよ。
web メールのサーバはユーザからしたら他人なので、秘密鍵を預けるわけにはいかず、つまり暗号化/復号はサーバ側ではなくブラウザ側でおこなわなければいけない。その一方で、S/MIME の名のとおり特殊な MIME フォーマットが必要とされるので、サーバ側は暗号文を適切なフォーマットに整形しなければならない。このへんの実装が超絶めんどくさいですね。
PGP は MIME を使わず、すべての処理をブラウザ側に丸投げできるので、だいぶラク。画面に表示されてるものをコピペして手元で gpg コマンドにつっこんでやれば、(めんどくさい
公開鍵は預けても大丈夫なので、署名の検証はWebメールでも可能でしょう。署名したメールを送ってくるのは銀行など公共性の高い企業だろうから、Googleがそういう企業の公開鍵を収集してGmailで署名の検証をすれば、「smime.p7sという謎のファイルが気持ち悪い」という風評被害も減るし、フィッシング被害も減ると思うんだけどなぁ。あと、署名用と暗号化用に別々の鍵ペアを作って [wikipedia.org]署名用の秘密鍵を預けずに復号も行えるようにするという案もあるようです。
そのファイルが見えないメーラーも気持ち悪いです
S/MIME対応してたらそのファイルが見えなくなる代わりに検証結果が何処かしらに表示される。これで気持ち悪いなら常時ヘッダ込みでメール表示しないメーラは気持ち悪い位いってくれないと。
PGPやS/MIMEで本文を暗号化したとしても、送り先メールアドレスは暗号化されないはずなので、メールサーバ間でのTLS通信が無いと、選択的サービス妨害が出来てしまうはず。仮にPGPやS/MIMEを使うとしても、メールサーバ間でのTLS通信は必要だと思いますよ。
各OSデフォルトのメールアプリも、S/MIMEには対応してるけど、PGP/GPGには対応してない場合が多いと思う。たしかにS/MIMEが第三者の証明や公開鍵の正当性も検証しやすいからいいんだけど、基本的に有料だから普及しにくい。
その点、鍵の検証は各自で判断しないといけないけど、狭い範囲でやるだけなら無料で実現できるGPGでいいと思うんだよね。フィンガープリントをウェブ上で公開してれば鍵の検証もしやすいだろうし。でも、最初から対応してるアプリは少ない。そこを改善してくれるだけで少しずつでも普及していくと思う。
facebookがユーザーにメール送るとき、ユーザーが事前にGPG公開鍵を登録させておくと暗号化メールを送ってくれるようになったし、そういう流れが広まるとこれまたいいんだが。ただfacebookからのメール通知はそんな重要なもんでもないし、メッセンジャーの方のEnd-To-Endな暗号化やってくれよ、と。
私も早くe2eを完成させてほしいと願う一人ではありますが、暗号とセキュリティの専門家はメールを見限っていますな。I have recently come to the conclusion that e-mail is fundamentally unsecurable. The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption. [schneier.com](最近ではメールが本質的にセキュア化不可能だという結論に到達した。人がメールに望むものは、そもそも暗号と相容れない)
Googleは偽の安心感を与えて何がしたいんだろう？
DMやMLとかでエラー出まくりにならなったらめっちゃ鬱陶しそう。
#日常Gmailで受け取ってるメールの90%以上はDM
ヘッダ偽装の問題の方は、DKIMやSPFで対処されており、既にかなり普及しています。
http://news.mynavi.jp/news/2015/11/14/066/ [mynavi.jp]>一方の認証側では、Gmailにやってくるインバウンドメッセージのうち94%が、DKIMやSPFといったメールのドメイン認証メカニズムを持っていたという。
SPFがそんなに普及しているというのは、ちょっと信じられないんだけど。試しに最近受け取った会社のメールドメインを引いても、SPFレコードない場合が多いよ。そりゃあプロバイダのメールドメインなら、ほとんど全てがSPFレコード設定してるだろうけど。
5年前の総務省の統計見ると8割で対応済みなんですが・・・http://www.soumu.go.jp/menu_news/s-news/02kiban08_02000047.html [soumu.go.jp]
標的型も散々騒がれたのに5年もたってまだ、対処していないなら取引先としてどうなのか考えちゃいますね？
中央省庁や大手企業、ISPは対処済み。自治体レベルでも概ね対処済みですね
乗っ取られたアカウントからやってくるスパムメールにもきっちり署名が入っているのはどうしたもんだろう？これも暗号化された経路だから、警告は出ないんだろうな。
タイトルは半分釣り。さて、手元のメールサーバがPostfixなら「smtp_tls_security_level = may」を設定すればとりあえずはOKになるようだが、これはデフォルトの「平文SMTPしか使わない」から「相手がオレオレだろうと暗号化できるなら暗号化する」への変更となる。これに意義があると思うかどうかはまたひと議論あるんだろうな、と。
ちなみに上記オプションはこれ以上厳しいのだと「平文SMTPを使うという選択肢がなくなる」わけで、まだ暗号化SMTPに対応してないスラドみたいなメールサーバがあちこちにある現状ではメールが送れなくなるケースも出てくる…今回のGMailの宣言でこの状況がどう変わるか…
郵便で例えると届いた葉書に「誰かが覗き見ていますよ By あなたのGoogleはーと」って追記してくれる親切設計ってことか
余計なお世話だよ！
道中が平文なので、経路ハイジャックでメール改ざんされる可能性もあるような…
そんなの葉書でも一緒でしょ。
emailが葉書より安全なものだと思ってるようなアホでない限りは何の問題もないと思いますが。
そのアホが多いから問題なんでしょ。じゃなきゃ電子署名はもっと普及してるはず。経路ハイジャックは年々増えてるらしいので、葉書よりも大分危険。
まさにそれ。そんなに気にするなら真っ先にGmailの利用を止めるだろうにね
ちがいます。
と思ったら、こんな仕組み [rakuten.co.jp]があるそうで、楽天市場に出展しているショップからユーザーに送信する独自ドメインのメールを、なんちゃら@shop.rakuten.co.jpというアドレスに変換してユーザーに送り、ユーザーがなんちゃら@shop.rakuten.co.jpにメールを送ると、ユーザーのメールアドレスをなんちゃら@dm.fw.rakuten.co.jpというアドレスに変換してショップに送るという仕組みだそうで、
「楽天あんしんメルアドサービス」
と呼んでいるそうな。
つまり、ユーザーとショップの間でやり取りされるメールのほとんどが、TLSを使った暗号化経路で送られていない、ということである。
インターネットには経路ハイジャックが可能という欠陥があってですね、割と悪用されてます。例えばこんなのとか↓
経路ハイジャックされた話http://www.janog.gr.jp/meeting/janog36/download_file/view/163/179 [janog.gr.jp]
BGPハイジャックとか経路ハイジャックはそんなに関係ないでしょ確かに不正な経路でキャプチャされたりはするかもだけどDNS偽装されたり、ドメイン乗っ取られたりする方がメールサービス的にはまずいかと
記憶によれば、検知されない程度の小規模な経路ハイジャックが問題となってたはず。それと、ドメインの乗っ取りも問題ですが、ドメインを乗っ取られたら、乗っ取られたドメインでTLS証明書を発行されてしまうような…?
名前解決した後のIPアドレスへの経路を改竄されたらDNS偽装されたりドメイン乗っ取られたりしてなくてもアウトなんですけど。名前解決した後のIPアドレスが乗っ取られてしまうのと同じ。
まぁ本来のサーバに中継(キャプチャやMITM攻撃)するのが難しいから、攻撃を仕掛けた状態を長く維持するのが難しいとは思うけどさ。(ドメイン、DNS周りの場合、本来のIPアドレスへ中継ができる)
> 確かに不正な経路でキャプチャされたりはするかもだけどというわけで、経路ジャック系の場合キャプチャだけで済ますのは逆に面倒になります。フィッシングにしてもすぐバレるからあまり長くは持たないし、短期間で完結できる攻撃が多くなるかな。経路情報を監視する団体・サービスは結構あるようだから、発覚を遅らせる小細工しても長くは持たない。
主な経路から離れた場所で仕掛ければ乗っ取れる通信の比率が減って発覚が遅れることはありそうだし、攻撃対象の近くにもう一個接点作ってそこから中継する手はあるけど、経路情報監視したらどのみちバレる。
>DNS偽装されたりドメイン乗っ取られたりしてなくてもアウトなんですけど。
「ですけど」のところでドヤ顔してそう
別にこんな雑学知らなくても問題ないんだから、そんな負け惜しみ言わなくてもいいのに。「顔真っ赤にしてそう」とか言われちゃいますよ？
Google以外の不特定な誰かですよGoogleはプライバシーポリシーを提示してこちらもそれを承認していますが、メールを傍受する可能性のある誰かとはしていませんから
> Gmail使ってる時点でGoogleに丸見えなのに> 他の誰から隠そうっていうんだろう?そんなこと言ったら全暗号化通信いらなくなるじゃん？なぜ暗号化通信が必要なのかわからない人がいまだにいるとはね。
おい、お前の書き込み、ISPから丸見えだぞ
ISPに見られて困るようなことスラドに書かないし、人に見られて困るメールをgmailで送りもしない。
つまりGoogleにもMicrosoftにもAppleにもISPにも携帯キャリアにも頼らず、実質ネットに関わることなく生きていくということですね。それも一つの選択でしょうな。
>Gmail使ってる時点でGoogleに丸見えなのに
へー、すごいね
実際規約でそうなってるんで
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
それより PGP や S/MIME に対応すべき (スコア:5, 興味深い)
メールサーバ間でのTLS通信というのは勿論やらないよりはマシですが、NSAやスパイ組織などがメールを盗み見ようとした場合、メールサーバの管理者に圧力をかけたり、スパイを紛れ込ましたり、メールサーバにバックドアをしかけたりして、メールの内容を盗み見ようとするでしょうから、根本的な対策にはなりません。また、相手がメールサーバから平文のPOP3やIMAPなどでメールを受信していたら、その部分が脆弱なことには変わりないし、メールサーバの管理者がメールを盗み見ることが可能なのには変わりありません。
従って、根本的な対策として PGP や S/MIME 対応をするべきです。しかし、フリーソフトのMUAでもPGPやS/MIME対応が数多くあるというのに、いつまでたっても Android 版 Gmail クライアントは、PGP にも S/MIME にも対応する気がないようです。
きっと、メールの内容を読み取って、それに関連した広告を表示させて金儲けをしているGoogle のことですから、PGP や S/MIME といったまともな End-To-End 暗号化を普及させてしまったら大幅な収益源となることから（メールの内容に関連した広告とそうでない広告では、明らかにクリック率に違いが出ます）、普及させる気がないんでしょうね。
2014年06月04日にメールを「End-To-End」で暗号化するGoogle公式拡張機能が開発中 [gigazine.net]だという話がありましたが、1年半近く経っているのに、未だに正式版がリリースされません（そもそも、「拡張」ではなく「標準」で Android 版 Gmail MUA などに実装すべき性質のものだと思いますが、メール内容に関連した広告を表示させたい Google には難しいのでしょう）。他社のメールサーバがメールサーバ間でのTLS通信に対応していないことに文句を言う前に、自社のクライアントアプリ（Android 版 Gmail アプリなど）を PGP や S/MIME に対応させていただきたいものです（S/MIME 署名にも対応していない現状では、フィッシング詐欺メールも見分けにくいという実害が出ていますね……）。
Re:それより PGP や S/MIME に対応すべき (スコア:1)
もし「PGPやりたくない」という本音がGoogleにあったとして、一億歩譲ってそれを認めたとしても、
S/MIME署名にも対応しないことで「smime.p7sという謎のファイルが気持ち悪い」という風評被害を広めたことは許せないですな。
ちなみにGMail以外のWebメールサービスがPGPやS/MIMEに対応しなかったのは怠慢以外の何者でもないのでこれも万死に値する。
Re: (スコア:0)
S/MIME と web メールは相性が悪いのですよ。
web メールのサーバはユーザからしたら他人なので、秘密鍵を預けるわけにはいかず、
つまり暗号化/復号はサーバ側ではなくブラウザ側でおこなわなければいけない。
その一方で、S/MIME の名のとおり特殊な MIME フォーマットが必要とされるので、
サーバ側は暗号文を適切なフォーマットに整形しなければならない。
このへんの実装が超絶めんどくさいですね。
PGP は MIME を使わず、すべての処理をブラウザ側に丸投げできるので、だいぶラク。
画面に表示されてるものをコピペして手元で gpg コマンドにつっこんでやれば、
(めんどくさい
Re: (スコア:0)
公開鍵は預けても大丈夫なので、署名の検証はWebメールでも可能でしょう。
署名したメールを送ってくるのは銀行など公共性の高い企業だろうから、Googleがそういう企業の公開鍵を収集してGmailで署名の検証をすれば、「smime.p7sという謎のファイルが気持ち悪い」という風評被害も減るし、フィッシング被害も減ると思うんだけどなぁ。
あと、署名用と暗号化用に別々の鍵ペアを作って [wikipedia.org]署名用の秘密鍵を預けずに復号も行えるようにするという案もあるようです。
Re: (スコア:0)
そのファイルが見えないメーラーも気持ち悪いです
Re: (スコア:0)
S/MIME対応してたらそのファイルが見えなくなる代わりに検証結果が何処かしらに表示される。
これで気持ち悪いなら常時ヘッダ込みでメール表示しないメーラは気持ち悪い位いってくれないと。
Re: (スコア:0)
PGPやS/MIMEで本文を暗号化したとしても、送り先メールアドレスは暗号化されないはずなので、メールサーバ間でのTLS通信が無いと、選択的サービス妨害が出来てしまうはず。
仮にPGPやS/MIMEを使うとしても、メールサーバ間でのTLS通信は必要だと思いますよ。
Re: (スコア:0)
各OSデフォルトのメールアプリも、S/MIMEには対応してるけど、PGP/GPGには対応してない場合が多いと思う。
たしかにS/MIMEが第三者の証明や公開鍵の正当性も検証しやすいからいいんだけど、基本的に有料だから普及しにくい。
その点、鍵の検証は各自で判断しないといけないけど、狭い範囲でやるだけなら無料で実現できるGPGでいいと思うんだよね。
フィンガープリントをウェブ上で公開してれば鍵の検証もしやすいだろうし。
でも、最初から対応してるアプリは少ない。そこを改善してくれるだけで少しずつでも普及していくと思う。
facebookがユーザーにメール送るとき、ユーザーが事前にGPG公開鍵を登録させておくと暗号化メールを送ってくれるようになったし、そういう流れが広まるとこれまたいいんだが。
ただfacebookからのメール通知はそんな重要なもんでもないし、メッセンジャーの方のEnd-To-Endな暗号化やってくれよ、と。
Re: (スコア:0)
私も早くe2eを完成させてほしいと願う一人ではありますが、
暗号とセキュリティの専門家はメールを見限っていますな。
I have recently come to the conclusion that e-mail is fundamentally unsecurable. The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption. [schneier.com]
(最近ではメールが本質的にセキュア化不可能だという結論に到達した。人がメールに望むものは、そもそも暗号と相容れない)
ヘッダ偽装されたらそんなのわからないじゃん (スコア:0)
Googleは偽の安心感を与えて何がしたいんだろう？
Re:ヘッダ偽装されたらそんなのわからないじゃん (スコア:1)
DMやMLとかでエラー出まくりにならなったらめっちゃ鬱陶しそう。
#日常Gmailで受け取ってるメールの90%以上はDM
Re: (スコア:0)
ヘッダ偽装の問題の方は、DKIMやSPFで対処されており、既にかなり普及しています。
http://news.mynavi.jp/news/2015/11/14/066/ [mynavi.jp]
>一方の認証側では、Gmailにやってくるインバウンドメッセージのうち94%が、DKIMやSPFといったメールのドメイン認証メカニズムを持っていたという。
Re: (スコア:0)
SPFがそんなに普及しているというのは、ちょっと信じられないんだけど。
試しに最近受け取った会社のメールドメインを引いても、SPFレコードない場合が多いよ。
そりゃあプロバイダのメールドメインなら、ほとんど全てがSPFレコード設定してるだろうけど。
Re: (スコア:0)
5年前の総務省の統計見ると8割で対応済みなんですが・・・
http://www.soumu.go.jp/menu_news/s-news/02kiban08_02000047.html [soumu.go.jp]
標的型も散々騒がれたのに5年もたって
まだ、対処していないなら取引先としてどうなのか考えちゃいますね？
中央省庁や大手企業、ISPは対処済み。自治体レベルでも概ね対処済みですね
Re: (スコア:0)
乗っ取られたアカウントからやってくるスパムメールにもきっちり署名が入っているのはどうしたもんだろう？これも暗号化された経路だから、警告は出ないんだろうな。
スラドがこの件で何か異議を唱える資格はあるのか (スコア:0)
タイトルは半分釣り。
さて、手元のメールサーバがPostfixなら「smtp_tls_security_level = may」を設定すればとりあえずはOKになるようだが、
これはデフォルトの「平文SMTPしか使わない」から「相手がオレオレだろうと暗号化できるなら暗号化する」への変更となる。
これに意義があると思うかどうかはまたひと議論あるんだろうな、と。
ちなみに上記オプションはこれ以上厳しいのだと「平文SMTPを使うという選択肢がなくなる」わけで、
まだ暗号化SMTPに対応してないスラドみたいなメールサーバがあちこちにある現状ではメールが送れなくなるケースも出てくる…
今回のGMailの宣言でこの状況がどう変わるか…
え？ (スコア:0)
郵便で例えると
届いた葉書に
「誰かが覗き見ていますよ By あなたのGoogleはーと」
って追記してくれる親切設計ってことか
余計なお世話だよ！
Re: (スコア:0)
「だれかに見られたくないなら封書を使いましょう」とか。
まあ言わずもがなだと思うけど、世の中にそういう仕組みがあると知らない人も結構いるからね。
Re: (スコア:0)
道中が平文なので、経路ハイジャックでメール改ざんされる可能性もあるような…
Re: (スコア:0)
そんなの葉書でも一緒でしょ。
emailが葉書より安全なものだと思ってるようなアホでない限りは
何の問題もないと思いますが。
Re: (スコア:0)
そのアホが多いから問題なんでしょ。じゃなきゃ電子署名はもっと普及してるはず。経路ハイジャックは年々増えてるらしいので、葉書よりも大分危険。
Re: (スコア:0)
まさにそれ。
そんなに気にするなら真っ先にGmailの利用を止めるだろうにね
Re: (スコア:0)
ちがいます。
なぜrakuten.co.jpが？ (スコア:0)
と思ったら、こんな仕組み [rakuten.co.jp]があるそうで、楽天市場に出展しているショップからユーザーに送信する独自ドメインのメールを、なんちゃら@shop.rakuten.co.jpというアドレスに変換してユーザーに送り、ユーザーがなんちゃら@shop.rakuten.co.jpにメールを送ると、ユーザーのメールアドレスをなんちゃら@dm.fw.rakuten.co.jpというアドレスに変換してショップに送るという仕組みだそうで、
と呼んでいるそうな。
つまり、ユーザーとショップの間でやり取りされるメールのほとんどが、TLSを使った暗号化経路で送られていない、ということである。
Re:意味が分からん (スコア:1)
インターネットには経路ハイジャックが可能という欠陥があってですね、割と悪用されてます。
例えばこんなのとか↓
経路ハイジャックされた話
http://www.janog.gr.jp/meeting/janog36/download_file/view/163/179 [janog.gr.jp]
Re: (スコア:0)
BGPハイジャックとか経路ハイジャックはそんなに関係ないでしょ
確かに不正な経路でキャプチャされたりはするかもだけど
DNS偽装されたり、ドメイン乗っ取られたりする方がメールサービス的にはまずいかと
Re: (スコア:0)
記憶によれば、検知されない程度の小規模な経路ハイジャックが問題となってたはず。
それと、ドメインの乗っ取りも問題ですが、ドメインを乗っ取られたら、乗っ取られたドメインでTLS証明書を発行されてしまうような…?
Re: (スコア:0)
名前解決した後のIPアドレスへの経路を改竄されたら
DNS偽装されたりドメイン乗っ取られたりしてなくてもアウトなんですけど。
名前解決した後のIPアドレスが乗っ取られてしまうのと同じ。
まぁ本来のサーバに中継(キャプチャやMITM攻撃)するのが難しいから、
攻撃を仕掛けた状態を長く維持するのが難しいとは思うけどさ。
(ドメイン、DNS周りの場合、本来のIPアドレスへ中継ができる)
> 確かに不正な経路でキャプチャされたりはするかもだけど
というわけで、経路ジャック系の場合キャプチャだけで済ますのは逆に面倒になります。
フィッシングにしてもすぐバレるからあまり長くは持たないし、短期間で完結できる攻撃が多くなるかな。
経路情報を監視する団体・サービスは結構あるようだから、発覚を遅らせる小細工しても長くは持たない。
主な経路から離れた場所で仕掛ければ乗っ取れる通信の比率が減って発覚が遅れることはありそうだし、
攻撃対象の近くにもう一個接点作ってそこから中継する手はあるけど、経路情報監視したらどのみちバレる。
Re: (スコア:0)
>DNS偽装されたりドメイン乗っ取られたりしてなくてもアウトなんですけど。
「ですけど」のところでドヤ顔してそう
Re: (スコア:0)
別にこんな雑学知らなくても問題ないんだから、そんな負け惜しみ言わなくてもいいのに。
「顔真っ赤にしてそう」とか言われちゃいますよ？
Re: (スコア:0)
Google以外の不特定な誰かですよ
Googleはプライバシーポリシーを提示してこちらもそれを承認していますが、メールを傍受する可能性のある誰かとはしていませんから
Re: (スコア:0)
> Gmail使ってる時点でGoogleに丸見えなのに
> 他の誰から隠そうっていうんだろう?
そんなこと言ったら全暗号化通信いらなくなるじゃん？
なぜ暗号化通信が必要なのかわからない人がいまだにいるとはね。
Re: (スコア:0)
おい、お前の書き込み、ISPから丸見えだぞ
Re: (スコア:0)
ISPに見られて困るようなことスラドに書かないし、
人に見られて困るメールをgmailで送りもしない。
Re: (スコア:0)
つまりGoogleにもMicrosoftにもAppleにもISPにも携帯キャリアにも頼らず、実質ネットに関わることなく生きていくということですね。
それも一つの選択でしょうな。
Re: (スコア:0)
>Gmail使ってる時点でGoogleに丸見えなのに
へー、すごいね
Re: (スコア:0)
実際規約でそうなってるんで