仰せの通り。RFC 6202 [ietf.org] だと、S. Loreto, Ericsson, P. Saint-Andre, Cisco, S. Salsano, University of Rome "Tor Vergata", G. Wilkins, Webtide が関わっているし Google 以外にも普及しているから Google の陰謀とはいえませんね
RFC が大好きな RFC 信者であっても、普通は経典として有難がるのは IETF の査読を経てオープン標準として承認した標準化された Internet Standard (STD) やその準備段階の Proposed Standard (PS) の方です。
ロングポーリングなんていうのは、NATに穴あけする NAT traversal 技術の1つであって、ゴミみたいなパケットをまき散らしルーターに過剰な負荷をかける、インターネットの美しさを台無しにする姑息な手法です。だから、こんな手法が美しさを重視する RFC の Internet Standard (STD) となることは未来永劫ないでしょう。
GoogleはGCMであらゆるアプリのプッシュ通知の中身 (SNSのDM等) までスパイしている (スコア:4, 参考になる)
Android OS では、位置情報だけでなく、あなたの SNS アプリの通知 / 個人的な DM を含む、その他のプッシュメッセージを Google がスパイしています。また、Google が取得した情報は NSA の監視下にあります。このストーリーでは位置情報だけが触れられていますが、それだけではないのです。
この記事は、よくあるアメリカを批判し、中国政府を正当化するための工作活動ではありません。アレゲな技術サイトスラドに相応しく、根拠となる技術的な説明をきちんとするので最後まで読んでください。
メールの自動受信、通知欄への広告表示、お知らせなどを目的とするプッシュ通信は
Re:GoogleはGCMであらゆるアプリのプッシュ通知の中身 (SNSのDM等) までスパイしてい (スコア: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 of Rome "Tor Vergata", G. Wilkins, Webtide が関わっているし Google 以外にも普及しているから Google の陰謀とはいえませんね
なんか RFC ならなんでも正しいというような言い方ですね。RFC 信者の方は、RFC同士が矛盾している場合、どうするんでしょうか? これは単なる仮定じゃなくて、矛盾するRFCなんて山のようにあります
それに RFC 6202 は、RFC は RFC でも単なる Informational な RFC で標準化されたものですらありません。Informational はベンダー独自の仕様をまとめたものや大手ベンダーが勝手に決めた独自仕様がde facto標準となってしまったものを広く公知するためのカテゴリーなので、オープン標準の RFC とは違います
RFC が大好きな RFC 信者であっても、普通は経典として有難がるのは IETF の査読を経てオープン標準として承認した標準化された Internet Standard (STD) やその準備段階の Proposed Standard (PS) の方です。
ロングポーリングなんていうのは、NATに穴あけする NAT traversal 技術の1つであって、ゴミみたいなパケットをまき散らしルーターに過剰な負荷をかける、インターネットの美しさを台無しにする姑息な手法です。だから、こんな手法が美しさを重視する RFC の Internet Standard (STD) となることは未来永劫ないでしょう。
ポーリングで無駄なパケットを定期的に何度も何度も送り続けるのではなく、プッシュ通知を受信したいなら、受信側がサーバーとなるべきです。それができない根本的な理由はNAT機器の存在であり、それが存在する理由は IPv4 アドレスの枯渇です。これは、素直に IPv6 へ移行で解決すべきなのです。IPv6 は IETF で標準化されている [geekpage.jp](ロングポーリングより遥かに格上の偉いRFC)ことから、「RFCを否定」を許せないような RFC 信者の貴方であるならば、ロングポーリングによる NAT traversal より IPv6 への移行で解決する方が良いと、ご納得いただけると存じます
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 はその内容を見ていないというソースは誰も提出しない。しかも、エン