ネットワークの仕組みにピュアP2Pを採用し、匿名性を保ったままファイルの共有を行うソフトである。
2ちゃんねるを発祥としている。
事前にファイルをキャッシュと呼ばれるデータに変換を行い、それを事前に確保したキャッシュ領域に保存しておき、各ノードのキャッシュ同士を交換することで効率の良いファイル共有を実現させている。
現在はキャッシュからファイルをアップロードしているいわゆる一次放流者のIPアドレスを、専門の解析ソフトウェアを通して特定することができるようになっている。
類似のソフトウェアにWinnyとperfect darkがある。
現在Shareには、通信にTCP/IPを使用した通常版と、UDP/IPを使用したUDP版が存在する。両者は基本的に同じであるが、ネットワーク・設定ファイルに互換性は無い。UDP版は若干古い通常版をベースにしているためプラグインの互換性に難がある。
多言語に対応しており言語ファイルの交換も容易であるため、海外の有志により各国語の言語ファイルが作成されている。
基本的に最新版はShareネットワーク内でのみ公開されるが、Winny等の他のP2Pネットワークにも存在し、また一部のウェブサイトでも配布されていた。
Winnyと同様、ウイルス感染者によるShareネットワークへの情報漏洩が社会問題となりつつある。詳細については、Winnyの項も参照。
主要ファイル共有ソフトとの比較
|
|
Share
|
Winny
|
LimeWire
|
StealthNet
|
| バージョン
|
1.0 ex2
（2006/4/1）
|
2.0 β7.1
（2003/11/11）
|
4.12.11
（2007/2/2 ?）
|
0.8.7.9
（2011/3/13）
|
動作
プラットフォーム
|
Windows 2000/XP/Vista/7
|
Windows 95 以降
|
Java が動作するシステム
|
.NET 2.0以降/Mono
|
| 日本国内シェア [1]
|
11.8%
|
33.3%
|
19.8%
|
?
|
最大
ファイルサイズ
|
32GB
|
2GB
|
4GB?
|
4GB
|
| NAT, ファイアウォール越え
|
難 （要ポート開放設定）
|
易 （ポート0モード）
|
易 （UPnP / UDP Hole Punching搭載）
|
難
|
| 匿名性確保の方法
|
拡散アップロード
|
転送の中継
|
無し
|
転送の100%中継
|
| 開発
|
作者
|
（村長）
|
金子 勇（47氏）
|
Lime Wire LLC
|
Lars Regensburger
|
| 開発開始
|
|
2002/4/1
|
2001/1 以前
|
|
| 開発方針
|
Winnyの後継
|
匿名性と効率の両立
|
効率的な共有
|
完全な匿名性確保
|
ネ
ッ
ト
ワ
ー
ク
|
プロトコル
|
独自
|
独自
|
Gnutella
|
RShare
|
| 概要
|
ファイル検索用接続とファイル転送用接続に分かれている。
検索用接続は常時、転送用接続は必要に応じて行われる。
|
一律だが通信形式は確認できない仕様。
通信確認、検索接続は常時。
転送接続は必要に応じて行われる。
|
| トポロジー
|
メッシュ
|
階層付メッシュ
|
メッシュ
|
メッシュ
転送時に条件が整った場合はその転送に限り条件付きでスター
|
繋ぎ換え
頻度
|
頻繁
|
時々
|
かなり少なめ
|
かなり少なめ
|
クラスタ
構築
|
キーワード（最大5つ）
ノード優先度
|
キーワード（最大3つ）
ノード優先度
|
無し
|
無し
|
| 暗号方式
|
RSA+RC6
|
RC4
|
TLS
|
RSA1024bit AES128bit (Rijndael)
|
検
索
|
ファイル情報
の収集・拡散
|
隣接ノードと交換・選別
|
上流ノードに集約
|
何もしない。
|
ファイル情報
の検索
|
自身のノード内から検索
|
上流ノードにクエリを送信
|
周辺ノードにクエリを送信
|
不完全な
ファイルの情報
|
公開
|
非公開（スワムダウンロード用断片ソースとしては公開）
|
転
送
|
概要
|
ファイルからキャッシュに変換しながら、
あるいはキャッシュをそのまま転送。
|
ファイルをそのまま転送。
|
| 接続
|
保持側から要求側に接続
|
要求側から保持側に接続
|
| 最小単位
|
1MB
|
64KB
|
1B
|
ファイル提供者
の匿名性
|
解析可能
（Retina Sharebot等）
|
解析可能
（Poeny、Nyzilla等）
|
なし
|
解析不可能（現実的方法では）
|
通信内容
の秘匿性
|
傍受可能（プロトコルに脆弱性あり）
|
?
|
傍受不可能（現実的方法では）
|
Winnyを意識して作られている為、Winnyと同様ないし酷似している部分が多い。一方Winnyに対して主に以下の改良点・変更点がある。
拡散アップロード機能
ファイル保持ノードが適当に選んだ相手に対して能動的にアップロードを行うため、監視ノードがファイル保持ノードと狙って接続しにくくする効果があり、匿名性を確保している。Shareは拡散アップロードに関しては一定確率で中継も行い、流通能力の向上と匿名性の強化を図っている。また、充分な拡散アップロードを行った後であれば、一次配布ノードがShareネットワークに接続していなくてもファイルは流通するため、一次配布ノードの負担を減らす効果がある。一次配布は基本的に拡散アップロードで行われる。
専用プラグインによる拡張性
多数のプラグインが開発されているため、さまざまな機能を追加することができる。Shareが抱える欠点や問題点をカバーするために少なくともDiffusionProClone, RegExpFilter, NoSpam等の導入が推奨される。プラグインの開発はSharePDKと呼ばれるプラグイン開発キットを使用しDelphiで開発する。
クラスタの簡易切り替え機能
最大5個のクラスタ・キーワードを使用可能で、専用メニューを利用して事前に登録した最大255個のキーワードから選択できる。クラスタ・キーワードの一括切り替えを行うプラグイン(ClusterChanger)も存在する。
キャッシュ領域の容量制限に対応
任意の容量︵但し最低4GiB以上︶に制限できるためHDDを使い切る心配が無い。また、必要性の少ないファイルから自動的に削除されるため、管理の手間が省ける。手動で管理したい場合は密告を利用する。
大容量のファイルに対応
最大32GiBまでのファイルに対応している。
Unicodeに対応している
内部では文字列をUTF-16で管理している。そのため、異なる言語が混ざったファイル名も問題なく扱え、またローカライズのしやすさに繋がっている。ただし、Share本体はUnicodeに対応しているが、プラグインがUnicodeに対応しているとは限らない点は注意を要する。
暗号・署名の強化
暗号・署名に関する処理についてはWinnyより丁寧に実装されている。ShareのIDは、IDシステムを現在のものに一新して以来、今のところ偽装の被害は報告されていない。尚、通信の暗号化は本質的には匿名性の向上の効果が無いことが後に示されている。
バージョンアップ告知
新しいバージョンのノードは古いバージョンのノードに対してバージョンアップ告知を送ることができる。Shareでは加えて、指定より古いバージョンのノードを一定時間後に終了させることができ、古いバージョンのノードがいつまでもShareネットワークに残ることを防いでいる。この機能はクラックされるとP2Pネットワークが壊滅させられる恐れがあるため、Winnyではあえて搭載されなかった。
クラック対策
クラック対策の一環としてメモリ上のプログラム本体及びデータを検査しており、ハードウェアの異常でメモリ上のデータが化けた場合でも終了してしまう。そのため、Shareを動作させるパソコンは安定性が高いことが求められる一方、潜在的な不具合を発見できる利点もある。
フィルタ機能
条件に当てはまるファイルを表示しないようにするだけではなく、Shareでは加えて、条件に当てはまるクラスタ・キーワードを持つノードとの接続を拒否する。また、条件に当てはまるファイルについて、他のノードからの拡散アップロードも拒否する。Winnyより弱体化している点もあり、﹁捏造警告﹂は他のノードに知らせるだけで該当ファイルの流通に影響を与えない他、﹁キーを削除﹂や﹁捏造警告を追加﹂を指定してフィルタを行っても該当ファイルのキャッシュは削除されない、そもそも﹁キーを削除﹂や﹁捏造警告を追加﹂は自身がキャッシュを持っているファイルに対しては無効、という違いがある。
BBS機能を持たない
Winnyでは重点が置かれていたが、ShareではBBS機能を持たない。過去にプラグイン(ShareNNTP)でShareにニュースグループ機能を追加する試みはあった。
ポート0モードを持たない
ルーターの設定変更が必須であるためハードルは高い。UPnPで自動設定を行うプラグイン(UPnP)は存在するが確実ではない。ポート0モードの実装は多くの手間が掛かる割に、共有効率や匿名性に貢献せず足を引っ張る傾向にあるためサポートされなかったと見られる。
二次配布の時にファイル転送は中継しない
二次配布の時にファイル転送の中継は行わない代わりに拡散アップロードで匿名性の確保を行う。尚、拡散アップロードの時には中継を行う。
クエリの送信の廃止
Shareは元々は、﹁検索﹂ボタンを押すと周辺ノードに﹁クエリ﹂を送信してファイル情報を探す仕様であった。しかしShareは、Winnyの様にネットワークを階層化していないため、クエリの送信はネットワークにとって大きな負担となっていた。このため Ver1.0 A77 で廃止された。この仕様の変更により、目的のファイル情報が自身のノードに辿りつくのを待つしかなくなったため、クラスタ・キーワードやトリガの設定が重要となった。
ファイルについて需要が多ければ多いほど流通が早くなるのはWinnyと同様である。
Shareは全体的に見て一次配布者側が有利な作りとなっている。
Shareはネットワークにおいて、ファイル要求側は受動的に、ファイル保持側は能動的に振る舞う。これは、Winnyなどの他のファイル共有ソフトとは逆になっている。
Shareは、Winnyと比較して一次配布開始からファイルが流通する速度が早い傾向に有る。
これは、Winnyが完全なファイル以外はアップロードしないのに対し、Shareはファイルの一部を受け取った時点でアップロードに参加するため二次配布が早めに開始されるためである。
また、Shareは一次配布の時点で複数のノードに分割してアップロードするため、多くのノードが早い段階で二次配布に参加できることも理由の一つである。
その他の理由として、他のノードとファイル情報を交換する際に、Winnyは常にランダムに選んだファイル情報を交換するのに対して、Shareはランダムに選びつつも一次配布された日付が新しいファイル情報を優先的に残す性質があるため、新しいファイル情報が求めるノードに素早く行き渡る事も挙げられる。
これらの性質は後述するキャッシュ即消しの影響を軽減する追加効果もある。
なぜなら、キャッシュ即消しを行うノードもダウンロードが完了するまでの間は二次配布に参加するからである。
一方でShareは、一次配布開始から時間が経ったファイルは次第にデータが部分的に欠落した「歯抜け」と呼ばれる状態になり、ダウンロードしにくくなる傾向に有る。素早い流通を助けた上記の性質が、このShare最大の欠点の原因となっている。
Shareネットワーク上に完全なファイルを再構築するだけの部分キャッシュが存在しなくなった後も、部分キャッシュのアップロードが行われるため、いつまでも不完全なファイルが流通することになり、それらがShareネットワークに蓄積されていく。また、完全なファイルが大量の不完全なファイルに紛れることで検索しにくくなる問題もある。
Winnyでは歯抜けで悩まされることはあまり無い。Winnyは不完全なファイルの配布を行わないため、不完全なファイルはWinnyネットワークから自然と消滅していくためである。
Winnyユーザーに逮捕者が出た時、Winnyの作者が家宅捜索を受けたため、Winnyの開発は事実上 停止した。
これを受けて、Winnyネットワークの将来に危機感を覚えたShareの作者によってShareの開発が開始され2004年1月5日に初めて公開された。
当時、Winnyの匿名性は絶対の信頼を得ており、逮捕者が出たことは利用者達に非常に大きな衝撃を与えた。そのため、利用者達の間では様々なテーマで多くの議論が行われ、また後継となるソフトが望まれていたこともあって、WinnyからShareに乗り換えるユーザーが多くいた。尚、当時はShareの他にFreenet+FrostやWinOZ︵後に実在しないことが判明した。WinMX→Winnyの流れを汲むような名前だけが一人歩きしたものと思われる︶が注目された。
Shareのバージョンについて、Ver1.0 CT (Connection Test Release) #1〜#21 → Ver1.0 DT (Diffuse Test) 1〜41 → Ver1.0 A (Alpha) 1〜82 → Ver1.0 EX (Extream) 1〜?と移り変わっている。UDP版では Ver1.0 NT (Net Test) 1〜5となっている。
Shareは当初、正式名称が決まっておらず﹁Share(仮称)﹂と表記されていた。それがそのまま定着したため、Ver1.0 A75 以降は﹁Share﹂と表記するようになった。
当初はWinnyの後継を目指して開発されたShareであるが、Winnyネットワークが予想に反して現在も順調に稼働していることから、今では共存関係となっている。大容量のファイルの扱い・新しいファイルの素早い配布が得意なShareと、長期間の安定した配布が得意なWinnyの住み分けが行われている。また、ShareネットワークとWinnyネットワークとperfect darkネットワークの間でファイルの移植を行っている者がいる。
2005年2月23日に初めて公開されたUDP版は当初から余り普及せず、TCP版より遅れたまま更新が止まっている。しかし最近になって、プロバイダによる帯域制限を回避しやすいとの理由で一部の利用者達から見直されてきており情報交換が活発になってきている。現在、利用者が少ないことが原因である「赤スリ」（赤Sleep）に悩まされている。
Share作者は、法に抵触する利用は控えるようにと言っている。だが、違法な目的による利用者が大半を占めているのが現状である。
マスコミ報道等では「シェア」と報道される事が多いが、ユーザー間では「シャレ」という呼称が一般化している。
最初は「Share（仮称）」として公開され、同時に名前とアイコンが公募された。
ほぼ同時期に有志の手により「Share(仮称)仕様村」と名づけられたWikiが立ち上げられ、不具合点や仕様等が討議された。
名前についても色々な名前が候補に上がったが、公開当初より「シャレ（洒落）」と呼ぶものが多く、
人気投票でも「シャレ」が一番人気であった為、シャレに落ち着いた。
この節の出典は、 Wikipedia:信頼できる情報源に合致していないおそれがあります。 そのガイドラインに合致しているか確認し、必要であれば改善して下さい。（2010年3月） |
Shareは開発当初からWinnyの問題を意識しつつ、一次配布ノードの匿名性確保に重点を置かれて設計されている。Winnyネットワーク解析の結果、一次配布ユーザーが著作権侵害の罪で逮捕された当時、一次配布ノードと監視ノードの直接接続が一次配布ノードの特定に繋がったと考えられていたため、Shareではそれを阻止するために拡散アップロード方式（プッシュ型）を導入している。拡散アップロードは同時に多数の中継転送を行うため、一次配布ノードと監視ノードが直接繋がることがあっても、一次配布ノード特定の決め手にはならないとされた。ファイルの一次配布には主に拡散アップロード方式のほか、通常のアップロード方式（プル型）も選択できる。
ファイルのハッシュ値やID（トリップキー）はSHA-1により生成される。IDは電子署名技術を用いているため、偽装は困難となっている。
Winnyの通信内容の暗号が解読されたのを受け、Shareでは通信の暗号化が強化され、1024ビットRSAとRC6が利用されている。
Shareの暗号化通信は解析困難とされていたが、ネットエージェントのOnePointWall等の解析ソフトにより解析可能になったほか、2007年1月にShareプロトコルの詳細が解析・公開[2]されたため、Shareの通信の秘匿性に疑問が生じた。それでも一次配布ノードの匿名性は、拡散アップロード方式の採用により、Winnyよりは高いとされる。
二次配布ノードについては、通常のアップロード方式が利用される。拡散アップロードによる中継転送をしないため、二次配布ノードの匿名性はWinnyよりも低い。現在では、SharebotやRetinaによって二次配布ノードの特定は可能であり、Shareの匿名性に疑問が生じた。
2007年3月に、Shareネットワークにおけるファイルの所有者を特定するツールSharebotが住商情報システムにより一般向けに公開された。社会問題と化している情報流出対策を目的としている。
Sharebotを利用する場合の注意点として、Sharebotは Share ver1.0 EX2 本体を要求するがそれを書き換えてしまうため、Share.exeはコピーしておく必要がある。
SharebotがCompleteキャッシュのみを収集する性質から、当初は一次配布ノードの絞り込み・あるいは特定の可能性が探られた。なぜなら、ネットワーク上で最初にCompleteキャッシュを持っているのは一次配布ノードなので、最初に観測されたノードが一次配布ノードである可能性が高いと考えられたからである。しかし、幾つかの理由で、一次配布ノードより先に二次配布ノードが観測される可能性が高いため、特定に至らないと今の所は考えられている。また、同様の理由で、観測された二次配布ノードが自分の意思でダウンロードしたとは限らないとも考えられている。
●詳細は不明であるが、Diffuseキャッシュを持つノードはたまにCompleteキャッシュとして他のノードに報告する。
●約10MiB以下のファイルのDiffuseキャッシュは、ほとんどが完全なものとなり常にCompleteキャッシュとして他のノードに報告する。
●拡散アップロード中は該当するファイルの存在を他のノードに報告しない。
上記のShareの性質を利用してSharebotによる観測を回避する方法が考案されている。
- DiffusionProCloneの設定を以下のように変更。
- 「他のクエリがアクティブな場合、一時停止」をオフに。
- 「アップロードキュー監視間隔」をなるべく短く。(100ms)
- 「アップロード登録を厳密にチェック」を有効に「アップロード後、元のクエリに復帰」を無効にした上で「クエリ検索に費やす最長時間」を最適値に。最適値は""で囲ったファイル名で検索をかけて表示されるmsec値より若干大きめの値を設定する。（環境によるが300ms以下）
- 一次配布するファイル以外のキャッシュも多く持っておく。
- 一次配布するファイルをアップロードフォルダに入れて「クイックチェック」を押すと、自動的に拡散アップロードが開始される。万全を期すなら、通信を停止した状態で、同様の作業を行い手動で拡散アップロードに登録してから、通信を再開する。
- 自分のノードの周りにCompleteキャッシュの保持を報告するノードが現れると、自動的に拡散アップロードは終了する。
また以下の回避方法も考案されている。
●一次配布するファイルAを関係の無いファイル名Bに変更してからアップロードフォルダに入れて﹁クイックチェック﹂を押す。
●BをDiffusionProCloneを利用する等して通常通り拡散アップロードを繰り返す。
●Bをアップロードフォルダから外し﹁クイックチェック﹂を押し、Bをデータベースから削除し、﹁ファイル数﹂が減らなくなるまで﹁未使用削除﹂を繰り返し押す。
●通信を停止する。
●Bのファイル名をAに戻し、Aをアップロードフォルダに入れて﹁クイックチェック﹂を押す。
●Aをアップロードフォルダから外し﹁クイックチェック﹂を押す。
●通信を再開する。
●データベースを含めてAを検索し、Aをダウンロードに登録する。
●Aのダウンロードを完了するまえにダウンロードを停止させる。
ファイル名Bは流通の成否に直結するため慎重に決める必要がある。
Winnyにおけるウイルスは社会現象にまで発展したが、Shareにおいても情報流出に結びつく恐れのあるウイルスが確認されている。
- 「Shareドクロ」というウイルスが確認された。これに感染するとShareのダウンロードリストにドクロの記号が追加される他、Share終了時にキャッシュが削除される、Share起動中はデスクトップのスクリーンショットが一定周期ごとに公開されるといった症状を引き起こす。
- 2006年2月下旬からは、感染者のパソコンをサーバ化してハードディスクの中身やデスクトップの画面を常時画像キャプチャし全てを公開、さらに感染者同士を相互にリンクする「山田オルタナティブ」というウイルスが発見された。
- 2006年4月頃にもShare上で動作する暴露ウイルスが確認されている。これで重要情報が流出した事例もある。
多くの感染方法が初歩的な手口であるのに関らず多くの感染者が居る点は注目に値する。感染は自分のみならず他の多くの人にも迷惑がかかる場合が多いので、﹁自分は大丈夫﹂と思わないことが重要である。
どうしても利用するのであれば、ウイルス対策を必ず行うこと。個人情報の流出が後を絶たないため以下に傾向と対策を示す。
WinnyやShareで流通している主なウイルスには以下の特徴や感染手口がある。
●国産のウイルスが多い。ウイルス対策ソフトの対応が遅れる傾向にあり、より危険性が高くなっている。
●プログラム上の欠陥を狙ったものが多い一般のウイルスと異なり、人間の不注意によって実行させようとするものが多い。
●長いファイル名の後半の表示が省略されることを利用して、危険な拡張子を隠して安全な拡張子への偽装を図るものが多い。
●UNICODEのRLO制御文字(U+202E)を利用してファイル名の偽装を図ったものが存在する[3]。この偽装が施されたファイルは見た目では全く区別がつかないので注意が必要である。ShareはUNICODEに対応しているため、アーカイブの中身だけでなくダウンロードしたファイルそのものが偽装されている恐れがある。Windows XP/Vistaのみ影響を受ける。
●isoイメージファイル等にウイルスを混ぜておき、DaemonTools等の仮想CDドライブソフトでマウントしたときにWindowsのオートラン機能によってウイルスが実行されるように仕掛けられたファイルも存在する。
●一次配布者の特定が難しい性質はウイルス配布者にとっても都合が良く、Webとは比べ物にならないほど積極的に配布され流通している。
●Web上でウイルスの配布を行い、それらをShareネットワーク上に再配布するよう促している者も居る。
以下に考えられる対策を挙げる。
●過信はできないがウイルス対策ソフトを導入・調整しておくことで危険性を少しでも減らすことができる。
●BitDefenderのフリー版は、比較的高い検知力を持ち様々な形式のアーカイブとISOイメージの中まで調べることができる上、多重アーカイブも対応しており、他のウイルス対策ソフトとほぼ競合しないため、併用が推奨されるソフトである。導入する際には有志が作成した﹁BitDefenderコマンドライン版 簡易インストーラ﹂を利用すると以降システムへの負荷が少なくて済む。
●実用コンピューターとは別に、ファイル共有ソフト専用として使うコンピューターを用意する。ダウンロードしたファイルの確認も用意したコンピューターで行う。
●仮想マシン上で実行し、常用環境と切り離す。
●ファイルの拡張子についての知識を持つよう努める。
●エクスプローラーの表示を﹁詳細﹂表示に切り替える。
●﹁フォルダオプション﹂→﹁表示﹂→﹁登録されているファイルの拡張子は表示しない﹂のチェックを外す。
●上記の設定を行ってもなお表示されない拡張子があるので、以下のレジストリを削除して対策する。再起動後に効果が出る。﹁スタート﹂→﹁ファイル名を指定して実行...﹂→﹁regedit﹂でレジストリエディタを起動できる。
●HKEY_CLASSES_ROOT\piffile\NeverShowExt
●HKEY_CLASSES_ROOT\ShellScrap\NeverShowExt
●HKEY_CLASSES_ROOT\SHCmdFile\NeverShowExt
●ダウンロードフォルダ及び、ダウンロードしたファイルの解凍先として使うフォルダについて、以下の手順でバイナリ・プログラムの実行を禁止する設定を施しておくことで、万が一誤って偽装されたウイルスを開いてしまっても感染を防ぐことができる。但し、スクリプトウイルスには効果は無い。この設定はNTFSでフォーマットされたボリュームにおいて可能である。
●設定を施すフォルダの﹁プロパティ﹂を開き、﹁セキュリティ﹂タブ内の﹁詳細(V)...﹂を押して﹁アクセス制御の設定﹂を開く。
●﹁アクセス許可﹂タブ内の﹁追加(D)...﹂を押して﹁ユーザーまたはグループの選択﹂を開き、"Everyone"を選択して"OK"を押す。
●﹁アクセス許可のエントリ﹂が開くので﹁適用先(O)﹂を﹁ファイルのみ﹂に変更し、﹁フォルダのスキャン/ファイルの実行﹂の﹁拒否﹂にチェックを入れて"OK"を押す。
●﹁アクセス制御の設定﹂でも"OK"を押すと、拒否エントリが優先される旨の忠告が表示されるが構わず﹁はい﹂を選ぶ。
●最後に﹁プロパティ﹂で"OK"を押すと設定完了。フォルダの中に安全なプログラムを入れて実行を試し、拒否されることを確認しておくと良い。
●以下の手順により、RLO制御文字を利用してファイル名の偽装を図ったファイルの実行を阻止することができる。但し、全ての状況で阻止できるわけではない。XP︵HomeEditionを除く︶以降のみ可能である。
●メモ帳を開き、半角アスタリスク︵*︶を二文字入力する。
●アスタリスクの間にキーボードのカーソルを置き、マウスの右クリックから﹁Unicode 制御文字の挿入﹂→﹁RLO Start of right-to-left override﹂を選択する。見た目は﹁* *﹂のようになる。
●﹁コントロールパネル﹂を開き﹁管理ツール﹂を開き﹁ローカル セキュリティ ポリシー﹂を開く。
●﹁ソフトウェア制限のポリシー﹂を開き﹁追加の規則﹂の上でマウスの右クリックを行い﹁新しいパスの規則(P)﹂を選択する。
●メモ帳に入力されている内容をコピーし、﹁新しいパスの規則﹂のダイアログの﹁パス(P):﹂に貼り付けをする。
●﹁セキュリティ レベル(S):﹂は﹁許可しない﹂を選択して、﹁説明(D):﹂には﹁RLO対策﹂等を入力を行い、﹁OK﹂を押す。
●再起動後に効果が現れる。
●アイコンを偽装する手口も多いので、システムで利用しているアイコンを標準のものから変更する。
この場合、Shareが管理する暗号化されたファイルを指す。利用者は原則としてキャッシュの中身を意識せず、また知ることもできない。
なお,手動で管理したければ密告を利用する。
Shareのキャッシュには、Localキャッシュ・Completeキャッシュ・Linkキャッシュ・Diffuseキャッシュがある。Linkキャッシュを除いて、同じハッシュを持つ（≒全く同内容の）キャッシュは同時に二つ以上を保持することは出来ない。但し、一つのキャッシュに二つ以上のファイル情報を結びつけることは可能である。キャッシュ自身もファイル情報を一つ持つ。
アップロードフォルダにファイルを入れてクイックチェックを行うと、同内容のファイルがキャッシュから自動的に削除される。そのため、ダウンロードしたファイルをアップロードフォルダに移動させるとキャッシュ領域の節約になる。その際、特定の条件を満たせばダウンロードした時のIDを維持したままアップロードすることができる（データベースによる地引を行っていない限り、大抵はその条件を満たす）。尚、強制変換によって生成したファイルをアップロードフォルダに入れるべきではない。
キャッシュ領域によってHDD容量を消費することを嫌い、目的の物のダウンロードを完了次第、全てのキャッシュを削除する行為を指す。Shareの衰退につながる望ましくない行為とされる。しかし、空き容量がないと、ファイルを変換することが出来ないため、キャッシュを削除することで適当なサイズの空き容量は常に確保する必要がある。また、数十GB程度の空きキャッシュ領域を確保しておくことで、ダウンロードが高速化されやすいため、更新日時の古くなったキャッシュから、随時削除していくことが望ましい。
Shareの仕組み上、ダウンロードしたファイルが不特定あてに送信可能な状態になる為、（送信する権利を持っていない）ファイルをダウンロードした場合、送信可能化権の侵害に抵触するため、たとえダウンロードするだけであっても、完全に合法に使うのがきわめて難しい。
- 2008年4月16日 - アニメのアップロードにより逮捕[4]
- 2009年9月30日 - ニンテンドーDSゲームのアップロードにより逮捕[5]
- 2010年10月22日 - アニメ映画「エスカフローネ」のアップロードにより逮捕[6]
- 2010年10月28日 - 「ハートキャッチプリキュア」のアップロードにより逮捕[7]
- 2010年11月2日 - ソフトウェア、ゲーム、アニメなど3TB分のファイルのアップロードにより逮捕[8]
- 著作権侵害に関するニュース - コンピュータソフトウェア倫理機構
