  |
はてなキーワード: オフとは
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
赤ずきんちゃんは、金髪の美少女でした。「将来、プロムに誘うならあの子だよな」村のにきび面の男の子たちはそう話し合ったものです。
やがて、平和な村に不穏な噂が流れてきました。なんと、狼団のテロリストが村に潜伏している可能性があるというのです。「愛国者法に基づいて山狩りをしよう」村長がそう呼びかけると、村人たちは松明と銃を手にテロリストを探し回りました。実のところ愛国者法は延長期限切れになって2015年の6月に失効していたのですが、そもそも愛国者法がどんな法律か知らなかった村人にはそんなの関係ありませんでした。
やがて、テロリストが潜んでいそうな場所が見つかりました。赤ずきんちゃんのおばあさんの家です。やはり愛国者法に基づいて仕掛けられていた盗聴器から、「モスクがどうたら」という会話が聞こえてきたのです。もしかしたら「モスクワ」と言ったのかもしれませんが、警察署長は自信たっぷりに「証拠は揃った、揃いすぎるほどな！」と断言しました。村人たちの中には「盗聴でわかったのなら山狩りは必要なかったじゃん」と思った人もいましたが空気を読んで文句を言わないことにしました。
警察署長が「さる筋から派遣されたスペシャリストだ」と勿体ぶって村人に紹介したのはほっそりとした少女でした。目深にかぶった白いフードからは見事なプラチナブロンド。そのあいだからは氷のように美しく澄んだ青い瞳が覗いていました。「彼女、すげーイカすな。なんのスペシャリストなんだろうな」村のにきび面の男の子はポルノめいた妄想で股間を膨らませながらそう話し合いました。
村の外れにある深い森、その奥へ奥へと白い少女が歩いていきます。やがて廃屋のならぶ集落が見えてきました。ここは開拓時代に栄えていた宿場町だったのですが鉄道が普及するとともに廃れ、ずいぶん昔から廃墟になっています。そんな廃墟の一角に赤ずきんちゃんのおばあさんは一人で住んでいたのです。こんなところにも老人問題の深刻さが見え隠れします。
白い少女は、おばあさんの家の前に立ち止まりました。ドアは半開きになっており、その前には広口のビンが転がっていました。つまり、ajar（半開き）と a jar（広口のビン）の掛詞になってるわけです。そんなダジャレどうでもいいので少女は「おばあちゃん、入るわよ」と言いながらドアをぐいっと開きました。ドアを開ける際にも油断なく左右を伺い、ドアの下部や上部のトラップワイヤーの有無を瞬時に判断するあたり、さすがスペシャリストって感じです。
ドアを開けるとむせ返るような血の匂いがしました。「おばあちゃん、すごい臭いね。まるで家のなかで人間の解体をしたみたいだわ」そう言いながら白い少女は寝室へ向かいます。寝室に入ると、人型ロボットがうずくまっていました。ロボットは「ぼく、いいロボットだよ」と言って高く手を上げて降伏の意思表示をしました。「いずれにせよあんたは赤ずきんの婆さんじゃあねえな。まあ死ねや」そう言うと少女は懐から取り出したソードオフ・ショットガンで至近距離射撃します。BLAM! BLAM! BLAM!
このソードオフ・ショットガンは、その名前の通り（sawed offは、のこぎりで切り落とす事）、普通のショットガンの銃身を切り詰めたもので、発射直後に散弾の拡散が始まるため、通常のショットガンと比べると有効射程は短いものの、至近距離の殺傷力や有効性はむしろ増大しており、更に全体の長さが短くなった事で、屋内などの狭所で扱い易いため、特殊部隊などが屋内に突入する際、出合い頭の戦闘が（敵と鉢合わせする事）多いポイントマンがエントリー・ショットガンとして用いる事もあるのです（Wikipediaより）。
ロボットはしゅうしゅうと煙を上げながら倒れ伏しました。少女は「しくじったな」とつぶやきました。おばあさんの家はいつのまにか一ダースほどの戦闘員に包囲されていたのです。
轟音とともに正面扉が吹き飛びます。おもわずそちらに包囲網の注意が逸れた隙に少女が裏口から飛び出します。銃弾が飛び交うなかをかいくぐり、戦闘員の背後にまわってショットガンを発射します。細身の体に似合わない怪力を発し、崩れ落ちる戦闘員の襟元を掴みあげるとそれを肉の盾としながら敵陣に突っ込みます。わずか50秒で瞬く間に敵を殲滅した彼女の白いフードは、今や血でベッタリと染まっていました。その美貌と戦闘力から彼女は「血染めの氷壁」と厨二っぽい二つ名で呼ばれていました。「白いフードが血で赤くそまるまで戦闘を止めない」アグレッシブな戦闘スタイルから、彼女を「赤ずきん」と呼ぶものもいました。（←これ、書いてて恥ずかしい）
血と肉片で汚れた銃身をフードで拭うと、その銃身に刻まれた文字がくっきりと読み取れました：
In Gun we trust
森から血染めの少女が帰ると、村ではお祭りの準備がされていました。今日はイースターのお祭りなのです。血染めの少女をみると、村人たちは「Meerica! Meerica!」と叫びました。突然音楽がかかり、村人たちはミュージカルめいて整然と踊り出します。バックコーラスは白い衣を着た聖歌隊です。聖歌隊には有色人種は一人もいません。スポットライトがあたる村の広場の中心に血染めの少女が歩み寄ると、先ほどの戦闘で見せた獰猛さを微塵も感じさせない清らかな声で、「アメージング・グレイス」を歌いました。
同人をやっていて仲良くなる相手が、皆同じくらいの実力を持っているとは限らない。そこには確かに上下があって、書き手同士の関係は実力の階級の上に構築される。
下手でも光る作品はある。実力とは無関係に、友人として波長が合うこともある。私はそう思っているけれど、そんな風に仲良くやれる人ばかりではないと思い知ったことがある。この記事はその時に溜めてしまった、心の毒を吐き出すためのものだ。
あるカップリングが好きな縁で、六人の仲良しグループが出来た。聖地巡礼に行ったり、イベントのアフターをしたり、当時は絵茶も活発だったし、ツイッターは登録と同時に全員が相互フォローになった。六人が同時に集まることは滅多になく、とりあえず全員に声を掛けて都合の付く人だけが会うような、ゆるい集まりだ。登場人物は作品の質が高い方から順に、A、B、C、私、D、Eという呼び方をしたい。
ちなみに私の書き手としてのレベルは、このグループに限らず中の中、もしくは中の下という評価を受けると思う。画力はギリギリ及第点くらい、話のクオリティと作業ペースが安定しているのでどうにかやれている。
ある時、Bさんが「皆で合同誌が作りたい」と言い出した。合同といっても編集会議などはなく、各々が自由に原稿を書き、編集・デザイン・告知サイト、頒布までBさんが一手に引き受けてくれるという。体裁はほとんどアンソロジーだ。
元々好きなカップリングが縁で知り合った仲だからと、私は執筆を引き受けた。忙しい時期ではあったのだが、この際だから個人誌の発行は諦めて、合同誌の原稿に全力を注ごうと決めた。
ただ、「告知ページの公開までは企画のことは内密に」とBさんから釘を刺されていたため、自サイトには「次のイベントでは新刊は出しません」とだけ書いてあった期間が長かった。普段の執筆ペースが安定していたことが災いして、閲覧者さんから体調を案じるメールを貰ってしまい、ちょっと辛かったのを覚えている。
告知ページが公開されたのはイベントの直前。
それだけと言えばそれだけの話だ。だが私は驚いて、考えなしに「え、なんで？」と発言してしまった。このことは今も後悔している。
私の問いかけにより、DさんもEさんも、発行告知の時点まで合同誌企画の存在を知らなかったことが判明した。Bさんからは「忙しそうだったから声を掛けなかった」という返答があった。
嘘をつけ。
普段の付き合いから、お互いの実生活事情は透けて見えている。私は「忙しくて原稿は厳しいです」「2ページとかでも全然良いので」というようなやり取りを経ての参加だった。Aさんが資格試験を控えていたことも皆知っていて、そのために集まりは自粛していたのだ。
Bさんが二人に声を掛けなかったのは、少なくとも配慮ゆえではない。彼女の言葉の白々しさと、それをDさんとEさんの目に触れる場所でわざわざ引き出してしまった自分の軽率さに泣きたくなった。
オフ同人には金銭が絡む。下手な者は原価割れをしたり、生活空間を在庫に圧迫されたりして、自分の力不足のツケを支払わねばならない（※）。
合同誌の場合、そのツケを支払うのは原稿作成者ではなく主催者である。この点において、私は「下手な人を切る」という判断をしたBさんを責める気はない。本人いわく「お金を出して行動を起こしたのは私なんだから、好きにして何が悪いの」とのこと。ごもっともである。
言いたいのはただ、こうも露骨に仲間外れを作る必要はなかっただろうということ。DさんとEさんの気持ちに配慮は出来なかったのかということ。例えばBさんとAさんの合同誌、BさんとCさんの本、そしてBさんと私の本。三冊に分割されていれば、「二人だけが仲間外れにされた」という感じは多少薄れたのではないかと思う。
Bさんが告知サイトの公開を遅くしたのは、入稿前ならDさんとEさんにも割り込む余地があるから。執筆者に企画のことを口止めしたのも同じ理由。合同誌を作りたいね、という話は全員がしていたものの、そういえば具体的なことはBさんとのメール上でしか話さなかった。DさんとEさんには情報が漏れない環境が出来上がっていた。
それから執筆者の人選とは無関係ですが、Bさん。あなたが描いた作品って、オフ会の時のDさんの語りを下敷きにしていますよね。「その話詳しく」とオフの後にも二人だけでお茶をしていましたね。仲良しアピールをして、ネタを吸い上げて、企画の際は爪弾きに出来る、その神経は凄いと思います。
Bさんの人間性にドン引きし、また「下手だから切られたのか」と即座に合点が行った自分自身にも嫌気が差して、私はそのグループのみならずジャンル自体から身を引いた。DさんとEさんはまだ残っているが、今は掛け持ちだった別ジャンルの方がメインになっているようだ。
申し訳ない。もしこの文章がお二人の目に触れることがあれば、私は彼女たちに謝罪の意を伝えたい。私が「なんで？」なんて言わなければ、話はもう少しあやふやなままで終わっていたはず。おまけにその直前には、私はお二人の目に付くところで無邪気に合同誌発行のお祝いをしていた。無神経にもほどがある。
お二人とも「なんで声掛けてくれなかったの」とは言いつつ、文末に「ｗ」を付け足せるような大人だった。Bさんも、お二人がそういう方だと見越して行動していたのかも知れないが。その手前、私が謝るのも変な気がして、何も言わずに逃げて来てしまった。
Bさんを労うこともなく、後のオフ会にも来なくなったという彼女たちが、傷付いていなかったはずがないのに。私も加害者だ。本当に、ごめんなさい。
寄稿なんかせずに個人誌を頑張っていた方が、あるいは私も執筆メンバーから外されていた方が、ずっと気が楽だった。それならまだあのジャンルに書き手として居られたと思う。
後日Bさんが「誘って欲しければ上手くなればいいのに」といった旨の連続ツイートをしているのを見掛けて、笑ってしまった。
それではDさんとEさんは下手だから誘わなかった、と公言しているようなものだ。誰へのリプライでもなく愚痴をこぼすということは、彼女なりに思うところはあったのかも知れないが、その発言もまた傷に塩を塗るようなものだという自覚はないらしい。
絵が上手い人と仲良くなりたい、という気持ちは私にもよく分かる。上手い人はそれだけ努力していることも知っている。だが自分が上手いからといって、下手な人を踏み付けて構わないのか、というとそれは別の話だろう。
相手が自分より下手な書き手だからといって、雑に扱ってしまっていませんか。上手い人に敬意を払うのを忘れないのと同じく、自分の作品を好きでいてくれる人、同じ原作が好きだという仲間を思いやる心もまた、忘れてはいけないのではないですか。
無理に褒め言葉をひねり出さなくていい。下手なのは事実だから。一般的な思いやりさえ忘れなければ、それでいい。
私は中の下の書き手だが、下には下がいる。上手くなりたくてじたばた努力もしている。自分が高い側に立つ時には、この記事に書いたことを心に留め置きたいと思う。
※
絵や文章が上手くても、ジャンル補正や装丁へのこだわりのため赤字という人は多い。なまじ大量に刷る分、在庫の置き場で苦労している場合もある。
上手けりゃ何の悩みもないという世界ではないのに、こんな記事を書いてしまう程度には凹むこともあるのに、何故我々は薄い本を出し続けるのだろう。
＞3.フォルダーを開いているところまで展開
元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
さて、この話をいつかはちゃんと記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。（またまた長文にて、失礼）
まず、1999年5月24日発表の郵政省資料「地上デジタルＴＶ放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください；
「また、昨年９月の暫定方式や既に答申がなされているＢＳデジタル放送方式、ＣＳデジタル放送方式の技術的条件において、実証実験を必要とする映像の表示方法とされていた720p（有効走査線数720本の順次走査による映像表示方法）について実験を行った結果、その性能が確認されたこと等が併せて報告されました。 この中で、720pは技術的にＨＤＴＶ放送と位置付けることが可能である、と結論付けられています。」（同上答申より引用）
関連記事は、日経産業新聞(1999年5月25日PP.3)、日本経済新聞(1999年5月25日PP.11)、電波新聞(1999年5月26日PP.2)などにも掲載されています。
今となっては、720pや1080pのプログレッシブ方式はプラズマや液晶テレビとの親和性、映画やCGなどの映像制作に有利なバリアブル・ピッチによる撮影、パソコンによる編集や再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年5月24日までの間、この720pを日本の放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。
私個人の主張、そしてマイクロソフトの立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。 米国の放送方式はATSCによるHD放送に向けた放送の標準フォーマットとして早くから1080i、720p、480p、480iが規定されていました。50年以上前に発明されたテレビ放送が米国に合わせてNTSC方式を日本は採用し、ヨーロッパ・中国・ロシアなどがPAL方式を採用してきた背景からすれば、日米のテレビ方式がデジタル・ハイビジョン（HD放送）の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマTVや液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつの映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視し映像を表現するフラットパネルの時代には、プログレッシブ（順次）方式が有利と思われました。さらに、映像圧縮に採用されたMPEG2方式においては、1080iは22Mbpsでは最高品質の映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像が破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらにMPEG2以外の圧縮方式MPEG4、H.264、WMV（現在のVC1）などを使えば8Mbpsから12MbpsでHD放送を伝送できるというのが、私たちの主張でした。
当時の私の主張をまとめると、「HD放送は1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人の認証、課金技術は特定技術一つに限らず、複数の技術をそれぞれもしくは組み合わせて提供可能とする。放送と通信の融合（連携）サービスを記述するメタ言語はHTMLをベースに各種プラグインそしてXMLに対応する。XHTMLをベースにしたBMLはそのサブセットとして組み込む。」
それに対して、1080i擁護派は、「1080iが優れた方式で、議論の余地は無い、プログレッシブの話をするなら帰れ!!」（実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん（E並氏）はとても紳士ですので、私は尊敬しております。決して誤解のないように）郵政省の会合でも何度となく放送のプロ達に諭（さと）されたものです。｢君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ｣「崇高な放送の世界を邪悪な世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。
将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。
当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業のHD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米の放送局でも沢山採用され、放送業界の権威あるエミー賞をDVC ProもHD D5も受賞されています。このD5というビデオデッキはNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタンを11個以上押さないと、（つまり二人の人間の指を駆使してボタンを押さないと720pの機能はアクティブにならないように細工がしてあったそうです。）..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類（たぐい）のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。
480pと720pの実験放送をやっていた日本テレビのSさんとKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術のトップの人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタル・ハイビジョンの映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果Sさん、Kさんは当然将来取締役が約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。
テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオ・スイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝と東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iのスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね？」という問い合わせが某局から入ったそうです。
TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画は純粋な技術的観点の選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro 720pを採択されたことが、唯一の救いと感じられました。
NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラを発見、JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネルの1080i/720pの文字列の720pの部分にはガムテープが張ってありました。
毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察の検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。
1998年のNABショウでマイクロソフトは初めて放送関連のコンベンションで技術展示をすることになりました（関連記事）。松下殿より当時500万円程したHD D5デッキをマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的な撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像に計算しなおし（アップスケール）、それをスダレのような偶数・奇数のフィールドに振り分け送出するという方式を取っていました（現在のデジタル・ハイビジョン放送の標準撮影方法です。）。そして同じ映像を1280x720の720p標準カメラで撮影しD5デッキに録画した映像をそのまま720ｐで再生するというデモ内容でした。映像の再生には当時の最高品質のCRTスタジオ・モニター(8000ドルクラスのSONY製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境で撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日のデモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトのブースを垣間見るや、とても渋い顔をしておられます。
私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員のホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人（私）が牢名主の親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。
そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか？何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下がマイクロソフトに協力して720pを推進するのはけしからんと、某放送局からお叱りを受けたと..それだけでも絶句の出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか？」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像をARIBの会員でもないマイクロソフトが勝手に使うのは如何なものか？」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明のパネルを書いて、某放送局の名前を実名で明らかにした上で、この名前の会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこのテープはここに置いて行きますが、夜中に誰かに盗まれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか？」と交渉は3時間を越える押し問答となりました。
その結果最後に明らかにされた背景は、某放送局の方から松下の役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!! それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当の役員がマイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当の役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープをマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネスの交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。
夜10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規に撮影を開始しますから、必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。 NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HDカメラ（当時は100kg以上あったと思います）とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオに見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラのライティング、撮影のオペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。
途方に暮れて困ったことは、深夜の12時にラスベガスのホテルで撮影できる生素材など有りはしないのです。それも著作権、肖像権を侵害せず、HD映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材（多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間に日中でロケハンに出かけることもできず、全てはラスベガス・ヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。
まず、深夜のルームサービスで果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてものを撮影しました。本格的なスタジオと違って光の回り方も映像のモニタを視ても、思ったような映像にはなりません。
夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌のカラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真を撮影してしまおうか？こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣を撮影すれば手彫りのエッチングで表現された人間の顔やお札の文様はHD撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣をビデオ撮影しても肖像権や著作権を主張する人もあるまい、という点が一番大事なポイントだったのです。
壁に貼り付けた50ドル札（私の持っていたピン札はそれしかなかったので）にバッチリとライティングを施し、撮影した結果は「キタ、キタ、キターッ」という感じ!!カメラをパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32
あれ、ほんとクソ
予測変換が邪魔。変換したつもりが勝手に語尾書き足されてたり、悪いけどまともに文字入力できる環境じゃない。
とにかく一度でも経験したことのある人ならわかると思うけど、iOSデバイスは外付けキーボードで文字を打つということがまともにできるシロモノではない。
でも買ってしまったんだよね。
こうなったら嫌でも元をとってやろうとおもうじゃないですか。
teamviewerによるリモートデスクトップ。
iOSがクソならwindows環境で文字入力すればいいんじゃね。
ってことで、2万くらいのネットトップ買ってきてセットアップ。
iPad側の入力を英字にしておくと、端末側の変換機能に依存することなくwindws側でローマ字入力できてマジで捗る。
24時間サーバー状態で、いつでもどこからでも快適な文字入力環境の出来上がりです。
じゃねーよ。フザケンナ。
まじでクソ。surface book買えばよかった。
ということでATOK pad買ってevernote同期させて下書き書いて、コピペで投稿することにしました。
ATOK padって、アプリ内だけIMEが独自のものが動くの。なにそれ天才。
1200円は高いけど、十何万塩漬けにするくらいなら安い。
予測変換をオフにするだけの機能をつけたメモアプリがあれば飛ぶように売れると思う。
それをみてappleが対策するころには一儲けしてとんずらできるくらいには間違いなく売れる。
IMEがクソなだけで端末全体の魅力が壊滅的になるってことだけはわかった。
昔から知ってたけど、proならなとかしてくれるかなって期待した俺がバカだったよ。
何がproだ。poorの間違いじゃねぇか。はやくなんとかしやがれってんだコンチクショウ。
まだ集中してない読み始めはその速度かもだけど、集中して読み始めると声に出す速度だと追いつかない気がする。
いや確かに脳内で勝手に音声が再生されるときもある。マンガとか。
オタクだし声オタだから、このキャラはこの声優さんがいいな～と思えば勝手に脳内でその音声で再生されるという便利な妄想機能もある。
でも、いざ文章を読みます、集中！となったら、脳内音声再生機能は勝手にオフになってた。
脳内音読だと一文字一文字追っかける感じになるから、時間はかかりそうだけど噛み締めて読めそう。
自分はある程度の文章のかたまり毎に認識していってる感じで読んでるから、読むのは早いけど、誤字脱字に気付かないことが多い。
かたまり把握タイプだからって噛み締めて読んでないわけではないけど、なんとなく残り具合が異なりそうな気がする。まぁ分かんないけど。
本を読む、という同じ動作なのに、人によって異なる処理が走ってるんだな。
