  |
はてなキーワード: httpsとは
MUFJのオンラインバンキングを申し込んでみたのだがそこでセキュリティーソフトを推奨された。
こいつだ。http://www.trusteer.com/ja/products/trusteer-rapport-for-online-banking-ja
残難ながらこれのダウンロードリンクはhttpsでは提供されていない。賢明な諸兄はご存知の通りhttpsで提供されていないソフトは信頼しないことが大原則だ。
ファイルがhttpsで提供されない場合はhttpsで提供されているMD5情報などを元にファイルの正当性を確認する必要がある。
何と言っても、オンラインバンキング専用セキュリティーソフトだ。最大限の注意を払う必要がある。
さて、困惑した私は会社のサポートチャットに問い合わせをすることにした。
"httpsで提供されていないソフトウェアをどうやって信頼すればいいのでしょうか？"というのが、はじめの質問である。
以下がそのログの抜粋（担当者のフルネームが表示されていた箇所を「サポート」と伏せている）
サポート: httpsで提供されていないソフトは、インストールの際にソフトウェアのデジタル署名をご確認ください。
増田: Trusteerエンドポイント保護のアンインストール.appを実行する場合はインターネットからダウンロードしたソフトですが信頼しますか？というようなことが表示されますよ。
サポート: はい。アップルストアからの提供品ではないためそのようなメッセージが表示されることもございます。
増田: また、OS Xでは署名はappleが認証したデベロッパーが開発したソフトウェアであることをを証明してもデフォルトでは提供元を表示する機能は無かった様に記憶してますが
サポート: ルート証明が正しければ正しい提供元としてTrusteerが表示されますので、ご確認いただけますでしょうか。
増田: えーと、それはどのようにすればいいのでしょうか？
サポート: 申し訳ございませんが、この内容はRapportのサポート範囲外となりますので、お答えできかねます。インターネット等でお調べいただけますでしょうか。
サポート: 正規のソフトウェアである事をご確認いただくための情報としては、組織に「Trusteer LTD」が表示されていることとなります。
増田: ではもう一点
増田: httpsで接続先が偽物というのはどのような場合でしょうか？ 考えられるのは 1.接続先の秘密鍵が漏れている場合 2.接続もと(ブラウザなど)が信頼できない認証局を信頼している 3.サイトがハックされている などのケースが考えられますがどのようなケースを想定していますか？
サポート: サイト自体がハッキングもしくは、ファーミングされたケースを想定しております。
サポート: ファーミングされた場合、偽者のSSL証明書を利用することでhttps接続となりますが、接続先は偽者、となります。
増田: 私がrapport.pkgをinstallしようとする際にはpasswordを求められるまでの間にアプリケーション提供元や署名の表示などは行われませんでしたが、これは問題ないとお考えですか？
増田: おそらくwindowsだと提供もと証明などがでてくるのでしょうけど。
サポート: 署名の表示は、お客様の操作によって表示されるものですので、Macの仕様となります。
増田: なるほど、比較的容易な攻撃方法であるDNSポイゾニングなどで間違った接続先に接続した場合、OSXユーザーは能動的に確認する以外に自衛手段はないということでよろしいでしょうか？
サポート: はい。Rapportを導入していない状況ですので、お客様ご自身の自衛手段となります。
サポート: 予定につきましてはお応え出来かねますが、ご要望として担当部署に伝えることは可能でございます。
増田: OSXユーザーがRapportインストーする際にそのような自衛手段を案内することはRapportのサポート範囲外ですか？
サポート: 申し訳ございませんが、そうなります。ただデジタル署名の情報でしたら先ほどご案内した通りでございますので、デジタル署名をご確認ください。
サポート: また、デジタル署名をご確認いただくことで、ソフトウェア自体に改竄が加えられていないこともご確認いただけますので、http/httpsに関わらず確かな方法となります。
増田: その確認方法は自分で調べないといけないということですか？
サポート: 申し訳ございませんが、ご自身でお調べしていただくようお願い申し上げます。
増田: わかりました、ありがとうございます。 予算さえあれば私でも御社のセキュリティーソフトの偽物を容易に配布できることをよく理解しました。
サポート: お客様への回答は以上となりますが、他に何かご不明な点などはございますでしょうか。
増田: いえ、ありがとうございます。
Linux Mint は、現在世界第４位で利用者が多いデスクトップOSだそうですよ。第３位はUbuntuかな。
Linux デスクトップ環境は、W******と遜色なくなってきましたね。
あとは、「ソフトウエアの管理」で RDP/VNC クライアントを探して、サーバや他のパソコンの遠隔操作にも使えるようにしようかな、Google Chromeをインストールしようかな。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。：
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね！ この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！ そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。：
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ！！！ ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
新しいはてなブックマークのデザイン，PCで観ているブクマヘビーユーザーからは概ね評判が悪い．これは一ページの情報量がごっそり減ってしまったためで理解できる．
一方，iPadで見るとこのレイアウトはかなり悪くない．エントリがタイル表示で選択できてそれなりに格好いい．PCではほとんどの人がブラウザの機能で消しているであろう広告欄ともうまくまっちしていて格好いい印象すらある．
なんだかんだで個人用のブラウザはPCという時代はもう終わってタブレットや携帯の時代になったということではないだろうか．騙されたと思って皆もタブレットで見てみるといい．けっこういけてるから．
思った改善点としては，
ニコニコの表示オプションで1 2 4とあるのが強制で3になっているようなもの．エントリの「1」列表示を選ばせて欲しい（できればそれをデフォルトに）
動画カテゴリ以外では，この二本目のカテゴリ選択はスカスカで勿体無い．ここは時系列のオプション，ブクマ数の閾値を選んだり，次ページへのリンクがあるべきであろう．
デザインは所詮はCSSの問題にすぎないし嫌なら外部でいじって変えることもできる．でもはてブの機能はすごく貧弱だし（例えば重複しているブクマをサジェストする機能がない．http/httpsでエントリが分裂する，臭いダジャレをフィルタする機能がない，etc.），デザインは機能にあわせて作られるべきだと思っている（UX）．デザインよりも大事な事，まずは作りこんだほうがいいんじゃないかな．
なんつうめんどくさい。。。
1.当然のことだが、最初に インターネットインフォメーションサービスと証明機関(WEB発行オプションも)の役割を追加
2.証明書の要求ファイルを作成(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)
3.自己署名入り証明書を作成(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)
4.サイトのDefault Siteへhttpsをバインド(IISマネージャのツリーのサイト名から Default Web Site 選択。右メニューのバインドでhttpsを追加。SSL証明書に自己署名した証明書を指定)
5.https://localhost/certSrv/ へアクセス。証明書を「詳細」要求する。ここで、要求ファイルの中身を貼り付ける。
7.https://localhost/certSrv/ へアクセス。発行された証明書をダウンロード。
8.「証明書の要求の完了」で、取り込み(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)
togetterがchromeが固まるくらい重いのと、書いてある内容に同意できてもエタ東となる4時の組み合わせは気分が悪いので、自分用に。
最初に書いておくと、これは特にpixiv擁護ではない。というより、擁護できる部分は特にない。
pixivを擁護したがっている人たちというのがいて、連日出てくる問題を鎮火させようと頑張っている。
カオスラウンジとズブズブだったpixivも悪の企業であると認めず、pixivは悪くない、pixivは俺たちの居場所だ、と信じて自分たちの立場を守ろうとする。（俺正義タイプ）
本の宣伝をしたいが代替サービスのユーザーがまだ少ない。pixivを宣伝用に使い続けるしかないのからpixivを守りたい。（我欲タイプ）
pixivとかユーザーのことなんて全くどうでもいいけど、批判に対して反対意見を言える俺かっこいい。（自己顕示タイプ）
大体想像できる動機はこんなところ。
メンツは固定しているないが、毎度の騒動で発生源となっているtogetterまとめを網羅的に眺めると、誰が鎮火しようとしているのか分かりやすい。
はてブでいうとb:id:sa_tie、b:id:katsura_1、b:id:tailtame辺りが該当。彼らを駆り立てているものは一体何なのか。（なお、エタ東も方向性が違うだけで同類にカテゴライズしている）
もっとも動機が不純だからといって、成すことが正しければ良い結果をもたらすこともあるし、独善が「悪事」としか呼べない暴走を引き起こすこともある。評価は人による。
pixivの新規登録画面は極めてシンプルで、pixiv idの用途については特に記されていない。（※要改善）
登録するとユーザーにはユニークな数字のidが付与されるので、pixiv idはログイン用のみだと考えている人は少なからずいるようだ。
実際にはpixiv id名でディレクトリが作られるほか、スタックフィード（活動履歴）のid、アカウントを共用するpixivブログや、姉妹サイトdrawr（flashで手書きできるサイト）のidとして利用されている。
pixiv idを外部から見られないものとして、個人名を使うなどする人もいて、問題となったことは過去に数度ある。id変更の機能追加をするという話もあったが今のところは実現していない。
今回の騒動の発端となったのはこのpixiv idが画像の絶対パスから参照可能だ、という最初期から判明していたことを何度運営に要望を出しても改善されないまま放置されたことに業を煮やしたことユーザー達のtwitterである。
これを、「最初期から判明していたことだから今更問題ではない」と擁護する連中が現れた。
「idは最初期から漏洩するような仕様で、スタックフィードなどからidを参照することも可能だ」と判っても問題点を把握できないユーザーが多数いたことで、危機の周知は次段階に移る。
「IDとパスワードを同じにしている人は危ない。プレミアムユーザーならクレジット番号などの登録もしているので危ない。」と危険を訴えた。この辺りから「ただの言いがかりレベル」などと鎮火ツイートが広がる。
現在のPCスペックの技術の向上は目覚しく、家庭用でもハイスペックなPCがあれば簡単なパスワードであれば数分～数十分で破ることもできるとされる。
が、それはメモリ内で高速に試行できるローカル環境上の話であって、web上のパスワード認証に対して必要とする時間は全く別物という視点が抜け落ちていて、とても現実的ではない。
だが、総当たりなどせずとも、簡単な単語やIDと同じパスワード、誕生日などであれば簡単にログインできてしまう可能性がある。
それを、「例えローカル上で10万回/秒でログイン試行できるPCでも、web上のパスワード認証に対しては通信とサーバーレスポンスがボトルネックとなって100回/秒程度のパフォーマンスしか発揮できないと思う。並列で大量にリクエストを殺到させればサーバーが落ちるだけだし、そもそも膨大なオーダーのログイン攻撃が仕掛けられれば、突破するより前にファイヤーウォールが異常を関知するか、サーバー管理者が気付く。そもそもイラストコミュニティサイトに対して逮捕されるリスクを犯して潜入したところで、成りすまして暴言コメントを書いたり個人情報を抜く程度で、不正アクセスのリスクにリターンが見合っていないわけで…。」
などと問題点をすり替えて、指摘する側がさも間違っているかのように発言を繰り返す。
大手ポータルサイトや銀行、携帯キャリア、有料ポイントを運用するネトゲなどであればそれなりに堅牢なログイン構造にするのが当然で、既に大手のお絵描きコミュニティ、しかもカードの支払まで行われるサイトにパスロックがないというのが問題でないはずがない。
admin.pixiv.net他に接続するとグローバルIPからでもログイン認証が出てくるというもの。発覚したのは実は1年も前だという。今回twitter等で公になってからも1時間程度は誰もがアクセス可能であった。
あくまでログイン認証画面が出てくるだけで、ID/パスワードが判明したわけでもなく、webのログイン認証に対するブルートフォースは非現実的なのは変わらないが、「外部からadminツールにログイン可能」というセキュリティ意識の無さが露呈し、大騒ぎとなる。
更に話が広まる際には「adminツールが流出した」「バックドアが仕掛けられた」「ログインにキーロガーが仕掛けられている」「アクセスするとウイルスを仕込まれる可能性がある」「今すぐ退会せよ」など虚実入り乱れた話となる。
普通に考えれば、外部からアクセス可能な状態で晒され続けたという事態が発覚した時点でサーバーを落として対策を取るはずなのだが、隠蔽体質に定評のあるpixivが何のアクションも起こさない為、念のためアクセスを控えるよう呼びかける。
「そこまで大事になっているのであればサーバーを落とすわけで、実害はない」などと見当違いな「俺の脳内のpixivのセキュリティ安全神話」ツイートが擁護派から出てくる。
admin.ads.pixiv.orgに接続すると「It workssl!」と表示されるもの。これがapacheのデフォルト表示「It works!」と異なることから、「何者かに書き換えられたか、運営が謎のミスをしたのか」と疑惑が生まれる。
ads.pixiv.orgは広告関連のサーバーのようだが、侵入された場合は他のサーバーも同様に危険である可能性が高く、「個人情報やカード情報が抜かれる危険性もある」と指摘されると「万が一侵入されていても個人情報が流出する可能性は低い」と根拠のないpixivの言い訳を持ち出す。
カード情報は決済代行会社が保存していると運営から「なぜか」一部ユーザーにメールで通知されていたようで、ここまでの騒ぎになっておきながらサイトトップでも発表しないなど、さらに不信感が募る。
「IDが漏洩する危険性がある」という問題点から、罪のないユーザーが被害に遭うことを防ごうしたものの、サービス開始時からの仕様で改善される望みが薄い。
さらに管理者ページが外部から閲覧できたことは、あってはならないセキュリティ意識、にもかかわらず、「批判は的外れで間違いだらけ」というまさに的外れな擁護ツイートが広まる。
ここまでサンドバックになってて何も発言せずパスロックを実装するpixivはある意味凄いが、その沈黙がさらなる疑惑を生んでいることにいつ気が付くのか。
「公式 Chrome ウェブアプリ はてなブックマーク」でコメントページを表示すると、旧UIのようにコメントだけを一覧表示できていい感じ。
というわけで訓練されたはてブ民の間ではuser.jsなどで飛ばしたりアレするのが流行るものと思われるが、グリモンだかなんだかに馴染みのない私は、今さら誰も触れないであろうProxomitronを使った転送方法を記しておく。
適当ながらメタブ対策を盛り込んでみたのがチャームポイント。
#はてブのコメントページをChrome Web App版に飛ばす 2011/05/17 14:50 (^$OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL(http://b.hatena.ne.jp/entry(/|\?mode=more?url=)(s/$SET(#=https://)|(http(s|)://)\#|(^(^[^/]++.))$SET(#=http://))(\#))$SET(9=$UESC(\@))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9)) ($OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL((http://b.hatena.ne.jp/entry/*)\0)$SET(9=$UESC(\0))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9))
下の行はメタブのためのmatch。タイトル下のブクマ数カウンターをクリックするとメタブページへ飛ぶようになる。不要ならばコメントアウト。
不具合があればどこかでid:Falkyをidコールするか@Sizukenにmentionを飛ばすかすると直るかも。
UIの好き嫌いが分かれてる感じですが、好き放題CSSを流し込んで左ペインさんに消えていただいたり、jsいじくってインラインプレビューを無効化したり、ちょこちょこいじってやるとそこそこ快適なブコメビューワになりますよ。新UIよりはずいぶんマシな感じですね。http://img.ly/system/uploads/000/993/748/original_PrtSc_000114.png
新アップローダがかなりドイヒーなので転載。http://www42.tok2.com/home/proxo/4.html
＜＜＜ URLControlフィルタ ＞＞＞ これはURLを扱うヘッダフィルタを１つにまとめるフィルタです。 ime.nuを飛ばしたり、他のサイトにジャンプさせたりと、指定の 仕方次第で様々なことが実現出来ます。 バージョン4.5以上推奨。 4.4以下で動くかは不明。（バージョンアップ推奨） （インストール方法） １、オミトロンフォルダ内のListsフォルダの中に URLControl.txt という テキストファイルを作る。 ２、このテキストファイルを 設定、BlockFile、追加 から URLControl と いう名前でオミトロンに登録する。 ３、下のヘッダフィルタをオミトロンに追加する。 範囲選択で下のフィルタを選択、コピー、ファイル、設定フィルタの併合、 クリップボードからデータを併合、ファイル、デフォルトの設定に保存。 ----------------------- [HTTP headers] In = FALSE Out = TRUE Key = "URL: URLControl (Out)" Match = "$LST(URLControl)" ----------------------- ４ URLControl.txt にURLとその処理方法を登録すれば完成。 （ URLControl.txt の記述例 ） 書き方は $URL(http://付きのURL)行いたい処理 という感じです。 例、 # ヤフー上のページにアクセスしようとしたらgoogleのトップページに飛ばす。 $URL(http://www.yahoo.co.jp/)$JUMP(http://www.google.co.jp/) #------------------------- URLControl.txt ------------------------- # NOADDURL # 先頭に # がある行は無視されます。 # 2chでimeの広告ページを踏まずに直接リンク先に行く。 $URL(([^:]+:/+)\0(ime.(nu|st)/|pinktower.com/)(\1))$JUMP(\0\1) # したらばで、広告ページを踏まずに直接リンク先に行く。 $URL(http://jbbs.shitaraba.com/bbs/link.cgi\?url=\0)$JUMP(\0) # Livedoor ブログ検索 $URL(http://sf.livedoor.com/show\?blog_url=([^&]+)\0)$JUMP(\0) # 旧tripodにアクセスしようとしてたら移転先のinfoseekに飛ばす。（２種類） $URL(([^:]+:/+)\0(cgi|members).tripod.co.jp/([^/]+)\1\2)$JUMP(\0\1.at.infoseek.co.jp\2) $URL(([^:]+:/+)\0([^/]++.|)\1tripod.co.jp/)$JUMP(\0\1at.infoseek.co.jp\p\q\a) # Proxomitron-Jでウェブフィルタを無効にする。 $URL(http://www.pluto.dti.ne.jp/~tengu/proxomitron/)$FILTER(False) # Proxomitron User's Wikiでウェブフィルタを無効にする。 $URL(http://abc.s65.xrea.com/prox/wiki/)$FILTER(False) ### 以下はコメントアウトして無効になっています。 ### 有効にしたい場合はコード行の先頭の # を消して下さい。 # local.ptron/以下に接続するときはWEBフィルタを無効にする。 # Bypassリストから local.ptron/ を消してこれを使えば # local.ptron/ にもヘッダフィルタが使えます。 #$URL(http://local.ptron/)$FILTER(False) # アクセスするときにキーボードのSキーを押していたらページのソースを表示する。 #$KEYCHK(S)$URL(([^:]+:/+)\0\1)$RDIR(\0\xsrc..bypass..\1) # アクセスするときにキーボードのDキーを押していたらデバックモードでソースを表示する。 #$KEYCHK(D)$URL(([^:]+:/+)\0\1)$RDIR(\0\xdbug..\1) # pya! で「18歳以上ですか？ はい、いいえ」ページをスキップ。 #$URL(http://pya.cc/pyaimg/han.php\?han=\0)$JUMP(http://pya.cc/pyaimg/spimg.php?imgid=\0) #------------------------- URLControl.txt ------------------------- ※ \k はマッチ欄では動かないのでこのフィルタでは使えません。 \kを使いたい処理は Kill-a-URL フィルタをご利用下さい。 更新情報 ： 2004/4/14 -> 2006/4/18 リストを更新。
