 
|
はてなキーワード: 文字列とは
今、Twitterでは日本でだけ話題なGumroadについて。Gumroadってのは、お手軽なクレカの現金化からカジュアルな転載でのお小遣い稼ぎまでが期待できる、出来たてホヤホヤの新しいサービスです。で、今回はその悪い使い方を考えてみようかと
Gumroadの新規性…は余りないんだけど、一番の既存のシステムとの違いは「購入のURLがクローズドに近い」ってところで。所詮はオープンなWebなんで、その気になれば掘り当てることは出来るけど(購入ページのurlは確認出来た範囲で最大5桁の英字の文字列だった筈)、トップから一覧が見れるとかそういうことはないので見つかりにくい
ということで、簡単に分かるけどそもそも無断転載されたページを発見しにくい。これは転載する側からしたら非常にメリットが大きいことかと
次に、中身が分からない
サムネイルですら、関係ないものを設定出来るので、偽装さえしてしまえば「知らない人間」からしたらスルー対象にもなりやすい。中身が何か分かるのは、転売の場の買う側と、Gumroadの運営だけだ。だから、片っ端からチェックして善意の通報をしようにも、中身を確認することが出来ないのでかなりハードルが上がる
で、そもそも権利者から以外の通報は受け付けないというスタンスが明示されているんで、善意の通報ってのが成立しない。権利者に連絡して、その権利者が動ければ良いけど、ここでまた向こうは英語だったりと面倒なことになる
ということで、売る場所と対象さえしっかりと考えられたら、簡単に転載を金儲けに組み込めるんじゃないかな、とか。別にPayPalでも同じことが出来ただろ、とか言われそうだけど、売るurl自体はGumroadのものなので、よりカジュアルにそれが達成できる感じかな、と。なんならメールとかチャットとか、そういう場所でも良いんだし
転載ビジネス、として今例えば挙げられるのは2chのまとめブログとか。あれだって「お金が手に入るから」こそあそこまで必死になってやる人間がいるわけで、金が絡んだ時の人間のモチベーション舐めんな、という話ですよね
散々他人を攻撃してきたニュース速報板、最後の攻撃先はニュース速報自分自身でした……
「ニュース速報板」というのは「2ch」内にある一つの掲示板です
ニュースを扱うことになっていますが末尾にプラスのつく「ニュース速報板+」等とは違い1200円程払えば半永久的に一応誰でもスレッドが建てられることになっています
2chまとめブログというのは「2ch」内から何らかのスレッドを選びそこからいくつか書き込まれたレスを抽出してブログ記事にしたものです
ひとまとめに2chまとめブログと言ってもジャンルや特色があり、アニメに特化したブログ、ゲームに特化したブログと様々です
もちろん何を扱っていても基本は「2ch」からの転載で成り立っています
これらのサイトは数年前からありますが年を経る毎にアクセス数は増え大手と言われるサイトでは一日のPVが100万、1ヶ月で1億を超えるサイトもあります
この2chまとめブログですが、その全てが個人によって運営されています
企業が参入してこないのはなぜでしょうか？
理由はコンプライアンス違反の可能性が濃厚だからです、法律的にグレーもしくは真っ黒ということですね
「2ch」に書き込まれた内容にはそのそれぞれに著作権があります - 『平成13年（ワ）第22066号著作権侵害差止等請求事件』
まとめブログはそれを引用の範疇を超えて転載しているので著作権者に訴えられれば著作権侵害となります
これは「2ch」への書き込み時に利用者は著作権移譲の規約に同意させられているからです
電車男騒動の際までは著作権自体は利用者にあったのですが騒動を期に規約が今の形へと変わりました
2chというサイトは元管理人のひろゆきが訴訟対策のためシンガポールにペーパーカンパニーを作るくらいに訴えられることはよくありますが
逆に訴えることはまずないという少しアンダーグラウンドな場所です
著作権侵害というのは親告罪ですので著作権者自身に訴えられるまではセーフです
そんなまとめブログですが当の「2ch」利用者には快く思っていない人も多くいます
特に転載される頻度の高い「ニュース速報板」の利用者は自分たちの書き込みが無断で利用、転載されているにも関わらず
自分たちには1銭の報酬もなく、まとめブログの管理人には（アフィリエイトによって）月数万～数百万の報酬があるというのですから日々鬱憤が溜まっているという状況でした
それが2007年のコピペブログ騒動です、これは結果的に「2ch」利用者の敗北に終わりました
この時「ニュース速報板」利用者の多くがアフィリエイトブログ（2chまとめブログ）への転載を禁止にしろと言いましたが
管理人のひろゆきはそれに応じず代わりに新しい掲示板を「2ch」内に作りました
それが「ニュース速報板（嫌儲）」という転載禁止を謳った掲示板です
それから月日が立ち丁度4年後の2011年12月、一つの騒動が起きました
「シャフト」というアニメ制作会社の公式サイト内に「やらおん」という2chまとめブログが報酬を得ることになるアフィリエイトURLが使われていたというのが事の発端です
これは通常考えられないことですので「ニュース速報板」では大きな騒ぎとなり
これはステルスマーケティングが関係しているのではないか、とまことしやかに囁かれました
それからステマという省略型が使われるようになり「ニュース速報板」全体がその単語で埋め尽くされるまでにあまり時間は掛かりませんでした
この騒動でこれを「ニュース速報板」からアフィリエイトブログ（2chまとめブログ）を排除する好機と考えた利用者は「2ch」運営に「ニュース速報板」のルールを転載禁止に変更するよう嘆願します
しかし却下され、これ以上の運動は何をしても無駄だと悟った「ニュース速報板」利用者は1/9 0:00をもって既にルールとして転載禁止のある「ニュース速報板（嫌儲）」へその多くが移住しました
現在「ニュース速報板」は移住を促す文句とアフィリエイトブログ（2chまとめブログ）への転載を邪魔する文句で埋め尽くされておりまともに機能していません
以上がことのあらましですが一つ一つをもう少し詳しく説明しますと
まず多くの人が誤解しているであろうことに"ステマ連呼"があります
"ステマ連呼"とは主にニュース速報板内でところ構わずステマと連呼しまくることで、色々なバリエーションがありますが基本的には"ステマ"という文字列で構成されています
そしてこの"ステマ"という言葉ですが、これはステルスマーケティングを指す意味もありますが、むしろアフィブログ反対というような意味合いを込めた掛け声という要素が強いといえます
例えば"これはステマ"と言えば、これはアフィブログの利になるだろうと思うのでまともな発言はしないよ、というような意味となります
そのほか耳にしたことは無いかもしれませんが"効いてる、効いてる"、"余程都合が悪いようだな"等が同じ意味合いの文句としてあります
ところでなぜこのような言葉が必要になってくるかというと、匿名掲示板という場所では誰がどのような考えをしているのか分からず
もっと言えば味方に見えた人が敵の装いであるかもしれないということが多々あるからです
アフィブログ反対という同じ気持ちはあるにせよ匿名掲示板上では何かの流れに逆らうというのは非常に難しいことです
ここで効果的な役目を果たしたのが上記の文句でした、巨人ファンも阪神ファンも取り敢えず日本がんばれ！で統一しようというわけです
今回ここまで騒動が大きくなったのは自然発生的にできた"ステマ"という合言葉が原因と功績の大部分を担っているのかもしれません
次に今回の2chでの騒動を殆ど、もしくはまったく知らなかったという人がいるかもしれません
普段なら祭りといわれる程の騒ぎなら大体知っていたはずなのに……と
もしそういう方がいれば、その方は普段2chまとめブログから情報を得ている方だと思います
今回の騒動は云わば反まとめブログ騒動なので当然ながら当事者のまとめブログは取り上げていません
まとめブログの情報も当然ながら編集された情報だということです
そしてまとめブログが極度に嫌われた理由の一つとしてその自己都合的（恣意的）なまとめ方があります
まとめブログというのは閲覧される回数が多いほど収入が増える仕組みとなっています、いわばPV至上主義というわけです
ですからPVが稼げるトピックを好んで取り上げ、時には内容の改竄とも取られかねないまとめ方をすることが多くあります
そうしてできた記事はよりセンセーショナルでコンプレックスを刺激し対立を煽るようなものとなっています
これは普段自分たちがマスゴミと揶揄してはばからない既存の大手マスコミか、責任を伴っていない分それ以上に非道いやりようで、最近は問題になることも少なくありませんでした
もちろん"楽して稼いでいる"という風聞や認識が広まりその部分が妬みを買ったというのも否定できません
しかし間違えてはいけないのはアフィブログ（2chまとめブログ）を嫌っている多くの人はアフィリエイトという仕組み自体を嫌っているわけではないということです
自らが産み出したテキストなどの正統な対価としてアフィリエイト広告を掲載している、例えばアルファブロガーなどに対してはアフィブログ（2chまとめブログ）と同じ非難の言葉が浴びせられることはありません
次にニュース速報板が完全になくなるとどうなるのという疑問ですが
まず一般的な2chまとめブログというものには面白系のニュースをまとめた記事が多くあるかと思います
その少なからぬ編集元がニュース速報板です、つまりこれまでに見てきたそういう記事は減ってしまうかなくなるかもしれません
次に自分の人生を語ってみたというような創作系の記事ですがその多くはVIPといわれる掲示板が編集元となっています
VIPについても現在反アフィ運動が展開されていますのでもし成功すれば、同様に記事は減ってしまうかなくなるかもしれません
その他のアニメ系、ゲーム系などの記事はそれぞれに専門板といわれる掲示板群が編集元となっていますので極端な変化はないかもしれません
ちなみに2ch利用者の中には自分の立てたスレや投稿したレスが大手といわれる2chまとめブログで取り上げられることがうれしいという人もいるようです
特にVIPに立てられ語られる創作系のスレッドではそういったことをモチベーションとしてやっている方がいるのも事実だと思います
映画にもなった「ブラック会社に勤めてるんだが、もう俺は限界かもしれない」などのお話は2chまとめブログがなければあれほどのムーブメントは起きなかったでしょう
2chまとめブログがネット上で影響力を持つことも悪い話ばかりではないのかもしれません
具体的な数字がありませんので全て憶測になるのですが、もしも何かを広めたいときに最もコストパフォーマンスの良い方法は何か？聞かれれば
自信を持ってニュース速報にスレッドを立てることだ答えられるかと思います
ニュース速報板にスレッドを立てる対価は極限まで薄めればタダです、しかし一度立ててしまえば無数にあるまとめブログがあの手この手を使って宣伝してくれることでしょう
もちろん取り上げられやすい話題などはありますが上で述べたような一定の傾向を抑えれば簡単に受けるトピックの作り方ができるともいえます
企業が組織的にニュース速報板でステルスマーケティングを実践しているというような陰謀論じみたことはにわかには信じられませんが
例えば自分が担当しているプロジェクトや商品について簡単に知名度を上げたければ、その個人がニュース速報板を使うということは少し想像力を働かせてみれば十分に考えられることだと思います
一度手を離れた情報がどのような伝わり方をするかが分からないというリスクはあるものの、それに見合うだけのコストパフォーマンスの良さがあるのでないでしょうか
そういった意味でニュース速報板→2chまとめブログのラインはかなりの影響力を持った媒体だったのではないかと思います
これは現在成功しつつあり今後も成功するのか、それとも何かあり失敗に終わるのかまだ予断を許す状況ではありませんが
成功し掛けているという点のみで十分に凄いことであると思います
ニュー速民といっても一つの意志をもった個体ではありませんし、何と言ってもリーダーのような存在がいませんので往々にしてその行動が一つにまとまるということはありません
それが今回は自分たちの住処となる板を移動するという相当難しいと思われる事をやってのけました
当事者でない方にこの難しさを伝えるのは簡単なことではありませんがとにかく凄いことだといえるかと思います
上で記したように"ステマ"という合言葉で反アフィの土壌がかなり固められていたことも大きな理由の一つかもしれません
ちなみにニュー速→嫌儲への移動までには色々と紆余曲折がありました
その多くは真偽不明の疑惑で、例えばニュー速にスレッドを立てている人はアフィリエイト側の人間で金銭を受け取っているであるとか
ニュー速は企業のステルスマーケティングの会場となっており、2ch自体がその業務を請け負っているというようなものまでありました
特に2chの運営自体がアフィブログ側の人間であるというような疑いはある種の絶望を産むこととなり、もう移動しかない……という諦観した行動原理を呼び起こす要因ともなりました
更に詳しい経緯についてですが、正直発端となったアニメ制作会社「シャフト」云々についてはあまり関係がないかもしれません
追記
・amazonアフィリエイトのURLが混入したことについて、「通常考えられないこと」と書いたのはそのURLが元サイト「やらおん」でも一度も使われていなかった、存在しなかったURLである
ということからこのように表現しました、しかし使われていたという情報も見たことがあり真偽は分かりません（←デマ(URLは存在した)らしいです、申し訳ありません）
・このまとめについてはできる限り内輪ネタにならないよう気をつけて書いたつもりですが、それ故細かい経緯、特になぜそこまでアフィブログが心情的な部分で嫌われたのかや
1週間余りの攻防ともいえるような2ch内でやり取りについて記せていないので、より詳しい方にとっては色々と不満があるかと思います
加えて、書いた人間がアフィブログ憎しという側の人間ですので、中立的な立場の方が読んでも不快にならぬよう心理的にかなりのバイアスを自らかけ、アフィブログにも配慮して書こうとした部分があるのも事実です
・なぜ自分たちの住処を移動するまでになったのか少し補足しますと、原因の一つとしていわゆる右翼左翼、嫌韓などの対立が意図的に誘導されたものだったのではないかという疑惑があります
スレッドを立てる人というのは限られていますので、彼等がまとめブログの運営者に近い人物であったり、その彼等が刺激的なタイトルで対立構造を煽っていた、というのはない話ではありませんし
事実として一部のスレ立て人はアフィブログの運営者であることを公言しています、2chは匿名ですからスレ立て以外の通常の書き込みでさえもそうした疑惑に駆られてしまい疑いだすとキリがありません
もちろんそこに証拠があったわけではないのですが、ニュー速に居続け転載され続ける以上その疑念を払拭することはできないので、その心配のない嫌儲に移住したというわけです
・http://anond.hatelabo.jp/20120111184947この方は存じておりません
現在も2chでは反アフィリエイトブログ運動が続いており「ニュース速報板（vip）」などにも飛び火しています
今後どうなるのかは分かりません、「ニュース速報板」は2ch内では規模の大きい板ですが仮に完全消滅したとしても2chまとめブログへの影響は限定的かもしれません
しかし2chの情報を何らかの形でまとめたサイトというのは無数にありますからどこかに変化があるかもしれません
いずれにしても予測の域をでませんので今後の経過を見てほしいを思います
匿名という武器と数の暴力という二つの力で祭りと称して個人の情報を暴いては嬉々としていた、いわばネット上の迷惑な集団の総本山とも言えるようなニュー速の
最後の攻撃先が自分たち自身というのはよくできてるようにも思えます
自分たちのコミュニティの閉鎖を最も望んでいるのが自分たち自身というのも珍しいですね
最後に
ざまああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ざまああぁぁぁぁあぁああぁぁあぁぁぁああぁあぁぁぁあああぁぁぁぁああぁぁあぁぁあぁああぁっぁぁああぁぁぁぁぁぁぁあぁっぁあああぁぁぁぁあぁああぁぁあぁぁあぁああぁっぁぁああぁぁぁぁぁぁぁあぁっぁあああぁぁぁぁあぁぁぁあぁあぁあｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ざ ま あ ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
DBってこんなもんか...と思ってたけど、インストーラのヘコさにあきれまくる。
その後 Microsoft SQL Server 2000 の手軽さを知って、こちらにどっぷり。
で、ずっとSQL Server。
そこそこの使い方ならどっちのDBも十分使える上に、Oracleは「くだらない」お作法が大杉。(Oracle Master の為?)
クエリー実行計画が図解でわかりやすい、バックアップやアタッチが超楽。
サポート(修正パッチなど)も料金込みのMSのほうがトータルで安価だし、CubeやReporting Serviceなどもコミコミで使える。
多言語関係もMS SQL Server のほうが良くできてる。
SQL Server のStandard Editionだけでなく、無償版であるExpress Edition も使っているが、
残念ながらこれは外部のPCから接続できない制限がある(はず)。
同じく無償版のOracle DB 11g Expressがあるが、こっちでは他のPCから接続できた。
Universal Installer は相変わらずjavaでできてるからかUIヘコいけど、
「くだならい」設定項目がだいぶ減って楽ちんでインストール完了。時代は進化した。
.NET Framework(OLE DB)で外部からのPC接続もホスト名、ユーザー名、パスワードを接続文字列で指定するだけで、あっさりOK。
tnsnames.oraとかいじることはもう無くてよいのだろう。
・文章が打ちづらくない？
ただし、Androidはソフトウェアキーボードの実装が機種依存だから
打ちにくい 機種も存在している。打ちにくい機種は本当に打ちにくい。
ただ、AndroidはDPIもフォントも機種依存だから見辛い端末はみずらい
・スクロールやらクリックやら、マウス操作にあたる操作が面倒じゃない？
クソな端末は本当にクソ
古いやつはガラケーのほうが早い。
結論から英馬、ガリガリ打ち込む作業についてはノートPCのほうが断然いいけど
スマホユーザーの大半は電車の中でちょっと読むとかだろうから、問題ないだろ。
ただ、最新のどっかのスマホがバグだして販売中止？になってるみたいだけど
そんな感じで端末によってキーボードも液晶の品質も結構色々違う。スマホとおもって買うと有名メーカーでも
痛い目見ることがある。
ようやくすまほを手に入れた。すまほといいつつLife Touch(Android端末) なんだが。
で、いろいろ疑問になった事をすまほユーザに訊きたい。
・文章が打ちづらくない？
・スクロールやらクリックやら、マウス操作にあたる操作が面倒じゃない？
キーボードマウスがついてるLife touch noteでさえ、こんなに使いづらい。
決まった操作しかやらない人や身体障害者にとっては支障も無ければ好都合な代物なのかもしれないが、メールを書いたり増田に投稿したり、そこそこＰＣを使ってきた人間にとっては、すまほは使いづらいんじゃないか？と思うのだが。
むかーし、マウスが嫌い・気持ち悪いと言っていたオジサンがいたが、今ならわかる気がしてきた。
すまほは慣れれば天国なのだろうか？
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
これをやらないとVLCで音声が出なかったり、TMPGencで音声が二重になったりする。
以下の内容のバッチファイルを作りショートカットを「送る」（SendTo）に入れる。TSファイルを右クリックし「送る」から選択するとMPEG2のPSファイル（主音声のみ）に変換される。
"C:\[パス]\BonTsDemux v1.10+10k7+nogui+es\BonTsDemux.exe" -i %1 -o "%~n1" -encode "MPEG2PS" -sound 1 -nogui
C:\Users\[ユーザ名]\AppData\Roaming\Microsoft\Windows\SendTo
設定の「プロセス」タブ内「コマンドを実行する」下欄に以下を入力（「MPEG2PS主音声」は任意の文字列）
MPEG2PS主音声:"C:\[パス]\BonTsDemux v1.10+10k7+nogui+es\BonTsDemux.exe" -i "%1" -o "%3\%4" -encode "MPEG2PS" -sound 1 -nogui
やー。面倒でした。
古い情報だと Outlook Express を経由しろと書いてあるので、後継であるらしいWindows Live Mail を経由して（Windows Live Mail からエクスポートする方法で）
Outlook に移行したのだが、どういうわけか宛名が文字列として移行されてしまい、xxx@example.com というメールアドレスの移行ができなかったんです。
で eml → msg もしくは pst 形式への変換ソフトを探すのですが、無料のものが見つからなくてあんまり情報もありませんでした。が、ありましたよ！お兄さん。
====
MAPI data collection and parsing tool. Supports property tag lookup, error translation, smart view processing, rule tables, ACL tables, contents tables, and MAPI<->MIME conversion. MrMAPI currently knows: 3916 property tags 801 dispids 35 types 58 guids 148 errors 27 smart view parsers Usage: MrMAPI -? MrMAPI [-Search] [-Dispids] [-Number] [-Type <type>] <property number>|<property name> MrMAPI -Guids MrMAPI -Error <error> MrMAPI -ParserType <type> -Input <input file> [-Binary] [-Output <output file>] MrMAPI -Flag <flag value> [-Dispids] [-Number] <property number>|<property name> MrMAPI -Rules [-Profile <profile>] [-Folder <folder>] MrMAPI -Acl [-Profile <profile>] [-Folder <folder>] MrMAPI [-Contents | -HiddenContents] [-Profile <profile>] [-Folder <folder>] [-Output <output directory>] [-Subject <subject>] [-MessageClass <message class>] [-MSG] [-List] MrMAPI -ChildFolders [-Profile <profile>] [-Folder <folder>] MrMAPI -XML -Input <path to input file> -Output <path to output file> MrMAPI -FID [fid] [-MID [mid]] [-Profile <profile>] MrMAPI -MAPI | -MIME -Input <path to input file> -Output <path to output file> [-CCSFFlags <conversion flags>] [-RFC822] [-Wrap <Decimal number of characters>] [-Encoding <Decimal number indicating encoding>] [-AddressBook] [-Unicode] [-Charset CodePage CharSetType CharSetApplyType] All switches may be shortened if the intended switch is unambiguous. For example, -T may be used instead of -Type. Help: -? Display expanded help. Property Tag Lookup: -S (or -Search) Perform substring search. With no parameters prints all known properties. -D (or -Dispids) Search dispids. -N (or -Number) Number is in decimal. Ignored for non-numbers. -T (or -Type) Print information on specified type. With no parameters prints list of known types. When combined with -S, restrict output to given type. -G (or -Guids) Display list of known guids. Flag Lookup: -Fl (or -Flag) Look up flags for specified property. May be combined with -D and -N switches, but all flag values must be in hex. Error Parsing: -E (or -Error) Map an error code to its name and vice versa. May be combined with -S and -N switches. Smart View Parsing: -P (or -ParserType) Parser type (number). See list below for supported parsers. -B (or -Binary) Input file is binary. Default is hex encoded text. Rules Table: -R (or -Rules) Output rules table. Profile optional. ACL Table: -A (or -Acl) Output ACL table. Profile optional. Contents Table: -C (or -Contents) Output contents table. May be combined with -H. Profile optional. -H (or -HiddenContents) Output associated contents table. May be combined with -C. Profile optional -Su (or -Subject) Subject of messages to output. -Me (or -MessageClass) Message class of messages to output. -Ms (or -MSG) Output as .MSG instead of XML. -L (or -List) List details to screen and do not output files. Child Folders: -Chi (or -ChildFolders) Display child folders of selected folder. MSG File Properties -X (or -XML) Output properties of an MSG file as XML. MID/FID Lookup -Fi (or -FID) Folder ID (FID) to search for. If -FID is specified without a FID, search/display all folders -Mid (or -MID) Message ID (MID) to search for. If -MID is specified without a MID, display all messages in folders specified by the FID parameter. MAPI <-> MIME Conversion: -Ma (or -MAPI) Convert an EML file to MAPI format (MSG file). -Mi (or -MIME) Convert an MSG file to MIME format (EML file). -I (or -Input) Indicates the input file for conversion, either a MIME-formatted EML file or an MSG file. -O (or -Output) Indicates the output file for the convertion. -Cc (or -CCSFFlags) Indicates specific flags to pass to the converter. Available values (these may be OR'ed together): MIME -> MAPI: CCSF_SMTP: 0x02 CCSF_INCLUDE_BCC: 0x20 CCSF_USE_RTF: 0x80 MAPI -> MIME: CCSF_NOHEADERS: 0x0004 CCSF_USE_TNEF: 0x0010 CCSF_8BITHEADERS: 0x0040 CCSF_PLAIN_TEXT_ONLY: 0x1000 CCSF_NO_MSGID: 0x4000 CCSF_EMBEDDED_MESSAGE: 0x8000 -Rf (or -RFC822) (MAPI->MIME only) Indicates the EML should be generated in RFC822 format. If not present, RFC1521 is used instead. -W (or -Wrap) (MAPI->MIME only) Indicates the maximum number of characters in each line in the generated EML. Default value is 74. A value of 0 indicates no wrapping. -En (or -Encoding) (MAPI->MIME only) Indicates the encoding type to use. Supported values are: 1 - Base64 2 - UUENCODE 3 - Quoted-Printable 4 - 7bit (DEFAULT) 5 - 8bit -Ad (or -AddressBook) Pass MAPI Address Book into converter. Profile optional. -U (or -Unicode) (MIME->MAPI only) The resulting MSG file should be unicode. -Ch (or -Charset) (MIME->MAPI only) Character set - three required parameters: CodePage - common values (others supported) 1252 - CP_USASCII - Indicates the USASCII character set, Windows code page 1252 1200 - CP_UNICODE - Indicates the Unicode character set, Windows code page 1200 50932 - CP_JAUTODETECT - Indicates Japanese auto-detect (50932) 50949 - CP_KAUTODETECT - Indicates Korean auto-detect (50949) 50221 - CP_ISO2022JPESC - Indicates the Internet character set ISO-2022-JP-ESC 50222 - CP_ISO2022JPSIO - Indicates the Internet character set ISO-2022-JP-SIO CharSetType - supported values (see CHARSETTYPE) 0 - CHARSET_BODY 1 - CHARSET_HEADER 2 - CHARSET_WEB CharSetApplyType - supported values (see CSETAPPLYTYPE) 0 - CSET_APPLY_UNTAGGED 1 - CSET_APPLY_ALL 2 - CSET_APPLY_TAG_ALL Universal Options: -I (or -Input) Input file. -O (or -Output) Output file or directory. -F (or -Folder) Folder to scan. Default is Inbox. See list below for supported folders. Folders may also be specified by path: "Top of Information Store\Calendar" Path may be preceeded by entry IDs for special folders using @ notation: "@PR_IPM_SUBTREE_ENTRYID\Calendar" MrMAPI's special folder constants may also be used: "@12\Calendar" "@1" -Pr (or -Profile) Profile for MAPILogonEx. -M (or -MoreProperties) More properties. Tries harder to get stream properties. May take longer. -No (or -NoAddins) No Addins. Don't load any add-ins. -On (or -Online) Online mode. Bypass cached mode. -V (or -Verbose) Verbose. Turn on all debug output. Smart View Parsers: 1 Additional Ren Entry IDs Ex 2 Appointment Recurrence Pattern 3 Conversation Index 4 Entry Id 5 Entry List 6 Extended Folder Flags 7 Extended Rule Condition 8 Flat Entry List 9 Folder User Fields Stream 10 Global Object Id 11 Property 12 Property Definition Stream 13 Recipient Row Stream 14 Recurrence Pattern 15 Report Tag 16 Restriction 17 Rule Condition 18 Search Folder Definition 19 Security Descriptor 20 SID 21 Task Assigners 22 Time Zone 23 Time Zone Definition 24 Web View Persistence Object Stream 25 Nickname Cache 26 Encode Entry ID 27 Decode Entry ID Folders: 1 Calendar 2 Contacts 3 Journal 4 Notes 5 Tasks 6 Reminders 7 Drafts 8 Sent Items 9 Outbox 10 Deleted Items 11 Finder 12 IPM_SUBTREE 13 Inbox 14 Local Freebusy 15 Conflicts 16 Sync Issues 17 Local Failures 18 Server Failures 19 Junk E-mail Examples: MrMAPI PR_DISPLAY_NAME MrMAPI 0x3001001e MrMAPI 3001001e MrMAPI 3001 MrMAPI -n 12289 MrMAPI -t PT_LONG MrMAPI -t 3102 MrMAPI -t MrMAPI -s display MrMAPI -s display -t PT_LONG MrMAPI -t 102 -s display MrMAPI -d dispidReminderTime MrMAPI -d 0x8502 MrMAPI -d -s reminder MrMAPI -d -n 34050 MrMAPI -p 17 -i webview.txt -o parsed.txt
理由は分かるよね？reCAPTCHAの謳っている文句的にこれはまずくない？
要はreCAPTCHAでは二つの単語、プログラムで生成された単語とOCRで読み取れなかった単語、が提示されて、ユーザはそれを読み取ることを求められる。しかし、この際正確に入力するのはプログラムで生成された単語のみで良い。なぜなら、OCRで読み取れなかった単語には答えが無いから適当に入力してもプログラムからは分からないので。reCAPTCHAの問題はその二つの単語が容易に区別できてしまうこと。なぜ区別が付くかというと、プログラムで生成した単語は乱数で生成した無意味な文字列なのに対して、OCRで読み取れなかった単語はきちんとした英単語だから。その二つを区別するコストが二つの単語を読み取る手間より低ければ、reCAPTCHAのもう一つの目的である人力OCRは成立しなくなってしまう。
この問題に対処するには、プログラムで生成する単語を無意味な文字列ではなく、辞書から引っ張ってきたものにすれば良い。ただ、ノイズ処理のかけ方からその二つの単語の区別は容易につくような気もする。こういうの論文のネタにならないかしら。
「はてなウェブ検索」なんかよりブクマされたページの検索機能をつけて欲しい。
はてブ新着で見て、ブクマしようかどうか迷った挙句に結局しなかったページが後で気になったけど全然探せなくて困る事がよくあるから…という自分勝手な理由からだけどさ。
とにかくはてブで見つけたんだから「3users以上にブクマされてるページ」というのは確実なわけで、そこから探したいんだ。
原発がふっとぶ直前のネット上で専門家が「絶対に安全だ」と言った例を俺は知らない。
もちろんトンデモが混じっていた可能性は否定できない（危険派もそうであるように）。
しかし、そもそも「絶対に〇〇である」という言い方自体が非科学的だ。
Twitter上の発言には多くの前置きがあった。
俺が知るかぎり「深刻な事態は起こりえない」といった類の発言は、
どれも「広島・長崎の原子爆弾」や「チェルノブイリのような爆発」を念頭に置いたものだった。
そして実際にそうした事態は起こらなかった。
しかし深く考えていない人は「深刻な事態は起こりえない」という文字列だけを見て「何の危険もない」という風に読み取る。
上で述べたような文脈は綺麗さっぱり忘れ去られている。
それは正しい態度なのか？
そして、あのとき流れた多くの「デマ」は、今になってもやはりデマのままだ。
決して覆りはしなかった。
Twitterのハッカーとのコンタクトに成功―攻撃手口の詳細が判明した
http://jp.techcrunch.com/archives/20090719the-anatomy-of-the-twitter-attack/
とかを読んで、パスワードの保存方法をいろいろ考えなおして悩んだ。条件は、
ってこと。現在、この方法に実験的に移行しつつあるけど、はてな民のみなさんの意見が聞きたい。
以上の準備の上で、真のパスワードは (A) + (B) + (C) という文字列。
以下に具体例を書く。
まず、(A)だが、これは座右の銘とかことわざとか住所とかを、うまい具合に省略して決める。例えば、座右の銘が「寿限無、寿限無 五劫の擦り切れ」だったとすると、（A)を "jgmjgm"とかにする。これはどこにも書かない、あまり変えない。逆に言うと、忘れにくいものにする。
次に、記号(B)を決める。これは無難に "@" にする。実は、この(B)は、厳密には存在意義があまりないんだけど、(A)(C)に記号を含ませるのはちょっと面倒なので強引に記号を導入するということで組み入れた。
最後に適当な乱数ジェネレータとかで(C)を決める。例えば "8sbI" だとする。
はてな：8sbI
実際のパスワードは、"jgmjgm@8sbI" となるので、これでパスワードを変更する。
現実には、パスワードはブラウザに覚えさせるので、マスターパスワードは絶対に設定する。ブラウザのマスターパスワードとEvernoteのパスワードくらいは別にして「気合いで」覚えても良いかもしれない。
あと当たり前なんだけど、Evernoteが乗っ取られたときに備えて、該当のメモノートには「パスワード」とは書かない。タイトルは「もつ鍋レシピ」とかにして、もつ鍋の写真を先頭に貼っておくと、Evernoteのプレビューでは写真だけがでかでかと強調されて表示されるので若干リスクが下がる。どうでもいいけど。
蛇足：面倒臭いのは、パスワードの文字数上限が8文字とか、記号禁止とか、そういう例外的なクソサイトへの対応なんだよな。使わないってのが最適解なんだけどね。俺の経験上、もっともクソだったのが就活サイト全般。
これを見て思ったんだが、そろそろviのなんとかモードという考え方を止めた方がいいのではないか。
vi系エディタの初学者がつまづく最大のポイントは、起動してそのままでは文字列が入力できない、という所だろう。そこで教える方は「最初は通常モードだから字が出てこないんだよー。挿入モードにすれば打てるようになるよー」とやるわけだけど、「aを押すと文字が入力できるようになる。打ち終わったらエスケープキー押しなさい」とでも言っておいたほうがいいのではないか。
というのは、このいわゆる挿入モードは、たとえば書いた文字を消すことができない。通常モードが非常に強力なのに対して、挿入モードの機能はは貧弱そのものであるのは、vi系エディタユーザー諸兄諸姉のあまねく知るところであろう。これだけ差のあるものをモードという二項対立を前提とする概念を用いて理解する必要が本当にあるのか。
おれは昔電算の授業でviの使い方を教えたことがあるが「えーと打ち間違ったからエスケープキー押して通常モードにしてxで一文字消してi押して挿入モードに戻して」なんて説明されてすんなり理解できるのはかなりの超人だぞ。だいたい教える方だってこのての編集作業は体が勝手にやってるだけで頭で考えてるわけじゃないしさ。
…とここまで書いて思ったが、そもそもviの学習をプログラミングと絡めて行うのがよくなかったのかもしれない。環境設定ファイルの編集から始めたほうが敷居が低い気がする。行ジャンプとか文字列の検索置換とかコピペのやり方をやって、最後に文字入力の方法を教えるの。これができれば免許皆伝です、とか言って。
