アカウント名:
パスワード:
Android OS では、位置情報だけでなく、あなたの SNS アプリの通知 / 個人的な DM を含む、その他のプッシュメッセージを Google がスパイしています。また、Google が取得した情報は NSA の監視下にあります。このストーリーでは位置情報だけが触れられていますが、それだけではないのです。
この記事は、よくあるアメリカを批判し、中国政府を正当化するための工作活動ではありません。アレゲな技術サイトスラドに相応しく、根拠となる技術的な説明をきちんとするので最後まで読んでください。
メールの自動受信、通知欄への広告表示、お知らせなどを目的とするプッシュ通信は
>これは、TCP というプロトコルの本来の使い方ですらありません。
これだけでGoogle関係者全員死ねばいいのにと思った。あらゆる倫理を踏みにじった上に技術にまで不誠実になったらテクノロジー企業でさえなくなり犯罪者集団でしかなくなる。
> これだけでGoogle関係者全員死ねばいいのにと思った。> あらゆる倫理を踏みにじった上に技術にまで不誠実になったらテクノロジー企業でさえなくなり犯罪者集団でしかなくなる。
完全に間違いだね
ロングポーリング自体はGoogle以外でも普及していて、RFCにも記載がある（6202あたり）
RFCを否定してるアホなアンチGoogle様は今すぐRFCまみれのインターネット切って脳内に引きこもっててくれや
「これは、TCP というプロトコルの本来の使い方ですらありません」という私の書き込みが誤解を招いてしまったのは遺憾です。
ロングポーリングという手法は、TCP というプロトコルが標準化された時点では全く想定されておらず、IPv4アドレスの枯渇によるNAT普及でNATの穴あけのために用いられた姑息な手法であり、「TCP というプロトコルの本来の使い方ではない」と誤解を招かないようにしっかりと書くべきでしたね。
仰せの通り。 RFC 6202 [ietf.org] だと、S. Loreto, Ericsson, P. Saint-Andre, Cisco, S. Salsano, University o
ロングポーリングを持ち出したACさんも勘違いしてそうですが、
> ロングポーリングなんていうのは、NATに穴あけする NAT traversal 技術
COMET(ロングポーリング)は、HTTPにおいて、WebブラウザというLISTENできないクライアントに対してWWWサーバからリアルタイムなデータ送信を実現するための方法論。NATとは無関係というか、COMETにとってNATはむしろ敵ですよ。(NAT無しに直接通信している場合、コネクションを張ったまま無通信状態で何時間でもコネクションを張りっぱなしにできますが、NAT越しで無通信が続くと、NATテーブルがタイマー切れ破棄されてコネクションが途切れてします。そのため、COMETするときは、一定時間おきにダミーデータを流すなどといったNAT対策が必要。)
で、HTTPに限定しない、一般論的なTCP/IPにおける通信では、「コネクションを張りっぱなしにしてデータ発生を待つ」なんてのは、名前すら付けられてない、ごく一般的なTCP/IPの利用ケースです。わかりやすいところでは、VPN接続とか、SSHログインで、相手側からの応答を待ってる状況、とかですね。
HTTPとはまったく無関係な、独自のプログラムが独自プロトコルで通信を行う「Android端末とGoogleのサーバーとのGCMのためのコネクション」は、ロングポーリングでもないし、TCP/IPの特殊な使い方でもなんでもない、ごく普通のTCPコネクションなんですよ。非難できるところなど何もありません。
で、HTTPに限定しない、一般論的なTCP/IPにおける通信では、「コネクションを張りっぱなしにしてデータ発生を待つ」なんてのは、名前すら付けられてない、ごく一般的なTCP/IPの利用ケースです。わかりやすいところでは、VPN接続とか、SSHログインで、相手側からの応答を待ってる状況、とかですね。HTTPとはまったく無関係な、独自のプログラムが独自プロトコルで通信を行う「Android端末とGoogleのサーバーとのGCMのためのコネクション」は、ロングポーリングでもないし、TCP/IPの特殊な使い方でもなんでもない、ごく普通のTCPコネクションなんですよ。
HTTPとはまったく無関係な、独自のプログラムが独自プロトコルで通信を行う「Android端末とGoogleのサーバーとのGCMのためのコネクション」は、ロングポーリングでもないし、TCP/IPの特殊な使い方でもなんでもない、ごく普通のTCPコネクションなんですよ。
冷静に考えると TCP/IP の使い方としては SSH でクライアントがNATタイマーが切れないように SSH_MSG_IGNORE を定期的に送り続けて TCPコネクションをキープし続けてるのと似たようなもんでした
今後は落ち着いてからカキコするよう留意します
そもそもプッシュ配信のためにコネクションを維持するってのは
昔はそれぞれのアプリがアプリ提供元のサーバに定期的に HTTPS でセッションを張るという、End-to-End 暗号化がなされる安全な方式で取得されていました。
↑これの時点で使われていたからGoogleがなんかやったわけではないんだよなぁ……
コネクションはりっぱで必要時に応答返すってのはHTTPでは特殊だっただけで、TCPとしてはレガシーなFTPやTELNET、SSHとそこらじゅうで使われているし。Google準拠の技術に強制的に揃えさせられはするけどそこは問題じゃなく。
問題なのは、全部入りになってGoogleの管理下に置かれたっていう点なわけで。
コネクションが存在することが問題なんじゃなくて、「サーバからアプリへのプッシュ通知を GCM経由にすることを強制することでプッシュ通知の中身を見ている」のが非難の対象でしょ。
コネクションの話は、プッシュ通知が GCM経由で行われているということを示すためにでてきた話だし、「TCP本来の使い方」という言い回しだって、本来の使い方をしていないとしても、それだけなら非難の対象になるようなことではありません。
> コネクションが存在することが問題なんじゃなくて、> 「サーバからアプリへのプッシュ通知を GCM経由にすることを強制することでプッシュ通知の中身を見ている」> のが非難の対象でしょ。
見ているというソースをどうぞあらかじめ言っとくけど、ソースも持たずにそんなこと言ってるならマジで裁判沙汰になるから覚悟してたほうがいいよ
これは、Googleもそうだし、Apple Push Notificationサービスを持つAppleについてもそうだからね
私は中立の立場から、個々の主張を検討しているだけなので、私がソースを提出する必要は存在しません。
で、Googleがプッシュ通知の中身を見ていないというソースはあるのですか？ソースが提出されないどころか、プッシュ通知を暗号化しろという意見さえあるではないですか。見てなければ暗号化の必要なんかないはずなのに、なぜ暗号化の話になるんでしょうね。見ているのが前提の意見ではないですか。
プッシュ通知がGoogle経由で行われているというソースは提出されている。Google はその内容を見ていないというソースは誰も提出しない。しかも、エン
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
GoogleはGCMであらゆるアプリのプッシュ通知の中身 (SNSのDM等) までスパイしている (スコア:4, 参考になる)
Android OS では、位置情報だけでなく、あなたの SNS アプリの通知 / 個人的な DM を含む、その他のプッシュメッセージを Google がスパイしています。また、Google が取得した情報は NSA の監視下にあります。このストーリーでは位置情報だけが触れられていますが、それだけではないのです。
この記事は、よくあるアメリカを批判し、中国政府を正当化するための工作活動ではありません。アレゲな技術サイトスラドに相応しく、根拠となる技術的な説明をきちんとするので最後まで読んでください。
メールの自動受信、通知欄への広告表示、お知らせなどを目的とするプッシュ通信は
Re: (スコア:0)
>これは、TCP というプロトコルの本来の使い方ですらありません。
これだけでGoogle関係者全員死ねばいいのにと思った。
あらゆる倫理を踏みにじった上に技術にまで不誠実になったらテクノロジー企業でさえなくなり犯罪者集団でしかなくなる。
Re: (スコア:0)
> これだけでGoogle関係者全員死ねばいいのにと思った。
> あらゆる倫理を踏みにじった上に技術にまで不誠実になったらテクノロジー企業でさえなくなり犯罪者集団でしかなくなる。
完全に間違いだね
ロングポーリング自体はGoogle以外でも普及していて、RFCにも記載がある（6202あたり）
RFCを否定してるアホなアンチGoogle様は今すぐRFCまみれのインターネット切って脳内に引きこもっててくれや
NAT traversal は美しくない (スコア:2)
「これは、TCP というプロトコルの本来の使い方ですらありません」という私の書き込みが誤解を招いてしまったのは遺憾です。
ロングポーリングという手法は、TCP というプロトコルが標準化された時点では全く想定されておらず、IPv4アドレスの枯渇によるNAT普及でNATの穴あけのために用いられた姑息な手法であり、「TCP というプロトコルの本来の使い方ではない」と誤解を招かないようにしっかりと書くべきでしたね。
仰せの通り。 RFC 6202 [ietf.org] だと、S. Loreto, Ericsson, P. Saint-Andre, Cisco, S. Salsano, University o
Re:NAT traversal は美しくない (スコア:3, 興味深い)
ロングポーリングを持ち出したACさんも勘違いしてそうですが、
> ロングポーリングなんていうのは、NATに穴あけする NAT traversal 技術
COMET(ロングポーリング)は、HTTPにおいて、WebブラウザというLISTENできないクライアントに対してWWWサーバからリアルタイムなデータ送信を実現するための方法論。NATとは無関係というか、COMETにとってNATはむしろ敵ですよ。
(NAT無しに直接通信している場合、コネクションを張ったまま無通信状態で何時間でもコネクションを張りっぱなしにできますが、NAT越しで無通信が続くと、NATテーブルがタイマー切れ破棄されてコネクションが途切れてします。そのため、COMETするときは、一定時間おきにダミーデータを流すなどといったNAT対策が必要。)
で、HTTPに限定しない、一般論的なTCP/IPにおける通信では、「コネクションを張りっぱなしにしてデータ発生を待つ」なんてのは、名前すら付けられてない、ごく一般的なTCP/IPの利用ケースです。わかりやすいところでは、VPN接続とか、SSHログインで、相手側からの応答を待ってる状況、とかですね。
HTTPとはまったく無関係な、独自のプログラムが独自プロトコルで通信を行う「Android端末とGoogleのサーバーとのGCMのためのコネクション」は、ロングポーリングでもないし、TCP/IPの特殊な使い方でもなんでもない、ごく普通のTCPコネクションなんですよ。非難できるところなど何もありません。
Re:NAT traversal は美しくない (スコア:1)
冷静に考えると TCP/IP の使い方としては SSH でクライアントがNATタイマーが切れないように SSH_MSG_IGNORE を定期的に送り続けて TCPコネクションをキープし続けてるのと似たようなもんでした
今後は落ち着いてからカキコするよう留意します
Re: (スコア:0)
そもそもプッシュ配信のためにコネクションを維持するってのは
↑これの時点で使われていたからGoogleがなんかやったわけではないんだよなぁ……
コネクションはりっぱで必要時に応答返すってのはHTTPでは特殊だっただけで、
TCPとしてはレガシーなFTPやTELNET、SSHとそこらじゅうで使われているし。
Google準拠の技術に強制的に揃えさせられはするけどそこは問題じゃなく。
問題なのは、全部入りになってGoogleの管理下に置かれたっていう点なわけで。
Re: (スコア:0)
コネクションが存在することが問題なんじゃなくて、「サーバからアプリへのプッシュ通知を GCM経由にすることを強制することでプッシュ通知の中身を見ている」のが非難の対象でしょ。
コネクションの話は、プッシュ通知が GCM経由で行われているということを示すためにでてきた話だし、「TCP本来の使い方」という言い回しだって、本来の使い方をしていないとしても、それだけなら非難の対象になるようなことではありません。
Re: (スコア:0)
> コネクションが存在することが問題なんじゃなくて、
> 「サーバからアプリへのプッシュ通知を GCM経由にすることを強制することでプッシュ通知の中身を見ている」
> のが非難の対象でしょ。
見ているというソースをどうぞ
あらかじめ言っとくけど、ソースも持たずにそんなこと言ってるならマジで裁判沙汰になるから覚悟してたほうがいいよ
これは、Googleもそうだし、Apple Push Notificationサービスを持つAppleについてもそうだからね
Re: (スコア:0)
私は中立の立場から、個々の主張を検討しているだけなので、私がソースを提出する必要は存在しません。
で、Googleがプッシュ通知の中身を見ていないというソースはあるのですか？ソースが提出されないどころか、プッシュ通知を暗号化しろという意見さえあるではないですか。見てなければ暗号化の必要なんかないはずなのに、なぜ暗号化の話になるんでしょうね。見ているのが前提の意見ではないですか。
プッシュ通知がGoogle経由で行われているというソースは提出されている。Google はその内容を見ていないというソースは誰も提出しない。しかも、エン