  |
はてなキーワード: 転送とは
すでに携帯ゲーム機はビジネス的に厳しいというコメントがソニーからされています
なのでVITAの後継機がでることはおそらくないとおもわれますが
こういう理由で出したほうがいいんじゃないかという話をしたいと思います
ぼくのかんがえたさいきょうのPS経済圏ってことでしかないのですが
大きなお世話でしかないものですが暇な人は読んでみてください（ネットの文章なんてみんなそんなものじゃないですか）
今はPS4が順調のようですが、このままだとMSか任天堂、またはべつの企業にやられてしまうとおもうのです
なので、それはPS4が抱えている問題に起因し、そしてそれはPS4ポータブルによって解決するという順で書いていきたいと思います
そしてそれがPS4の次世代（噂のPS4Kというものや、PS5についても言えます）に影響が出てきます
容量の限界
BDは規格上、一層25GB,二層50GB,三層100GB,四層128GBが可能ですが
PC用のGTA5が60GBを超えてついに二層式BDに収まらないなんて話がありましたが
今後そう言ったゲームが4K8Kになると加速していくでしょう
（層が増えると読み込みエラーが増えていくなんてはなしもありますし）
BDの等速での転送速度は4.5MB/sで10倍速でも45MBです
高速転送しようと回転早くすればするほどうるさく壊れやすくなります
HDDの転送速度は90MB/s出ますが現状のHDDでも転送速度が遅くてブラッドボーンなどでは読み込み時間が問題になりました
現状2.5インチHDDは1TBが標準で2TBがごく少量といった状態です
メーカーはもうHDDへの開発をやめていてこれ以上の進化は期待できません。
２０１６年現在でのSSDの価格は、ノンブランドITBで約22000円です。（ブランドものだと３万円超えます）
安くなったとはいえ、東芝ITBが5000円のHDDに比べるとバイト単位でいうと４倍以上です。ブランドものだと６倍。
キネクトをつけてしまったがゆえにPS4よりも割高な価格になったXBOXONEが
厳しい立場になったのを見ればわかると思いますが、ゲーマーというのはこういったことに敏感だと思います。
そもそも金に余裕があるならPCにするわいみたいな話ですし
（あとなによりインストールが面倒ですよね）
肝心なのは供給メディアで、ロムカートリッジの採用を提案したいと思います
SDカードをみれば数GBから上は256GBまで登場してしますし、切手サイズでおさまります
SDカードは90MB/sが当たり前で、ソニーのXQDカードだと読み込み400MB/sにもなります
半導体の技術はもうここまで来ているのだなと感心しますし、ゲームメディアでも十分可能ではないでしょうか
VITAとちがい、PS4ポータブルはあくまでもPS4を小型化して液晶をつけたものです
PS4のゲームが完全にプレイできるのでゲーム機立ち上げのタイトル不足問題が解決できます。
テレビ出力をつけて、大画面でやりたいアメリカでの需要も拾えますし
開発費が高騰しているいろんなメーカーもにっこりでしょう
PS5でもこのメディアを使いソフト供給ができれば互換性というアドバンテージができます
おそらく今後のゲーム機はゲームメディアというレガシー問題と向き合うことになると思います
なので今のうちにPS4ポータブルでメディアの切り替えを用意しておくことで、他社との差別化ができるというわけです
急にPS5でカートリッジになってもユーザーは切り替えに時間がかかってしまうと思います
あと個人的な好みの話ですが
ゲームメディアの供給がダウンロードのみになることの問題も指摘しておかなければいけないでしょう
ダウンロードは確かに便利ですし、試験的に運用されているPSnowみたいなストリーミングのようなものもそうなのですが
企業（権利者）がそのきになればゲームの供給を止めることもできてしまいます
ユーザーとしてはこういった物理メディアでの供給は続けてほしいなという思いがあります
(追記：最近amazon unlimitedで懸念してたことが起こりましたよね。配信するしないを向こう側に握られるってオタクとして気味が悪いので何とかしてほしいです。)
最近なにかと話題のVRも、振動に強いメディアのほうが良いと思いますし
任天堂の目指すところはこういうところなのではないかと考えています。
携帯ゲーム機と据え置きの共通メディア化が今後のカギを握るのではないかと
だからと言ってネットでのサイト視聴も、権利者側の都合で修正とか提供終了とかそういう主導権をにぎられるのも嫌です
（これはゲームと同様ですね。権利者に主導権を握られることに精神的不安があります。）
そうなるとやはり持っておきたいと思います
TBSラジオ、ポッドキャスト終了 10年超の歴史に幕 「収益化のめどが立たないため」
長年愛聴していたTBSラジオのPodcastが終了する。mp3で聞けなくなるのは困る。そこでどうするかを考えた。
1. radikoを録音できるフリーソフト「Radikool」を使う。
このRadikoolには自動的にiTunesに登録する機能があるので、聞きたい番組を録音予約するだけでいい。その後でiOSデバイスなりAndroidなり携帯音楽プレーヤーなりに転送すればいい。
月額350円を支払って、radikoプレミアムに加入し、Radikoolでradikoプレミアムを有効化して録音する。VPNを使ってTBSラジオを聞く方法もあるが、常に録音成功するわけではなく、失敗する可能性が高い(体験談)。
CravingExplorerなど、動画を自動的にmp3に変換してiTunesに登録できるソフトを使用し、Youtubeやニコニコ動画などから目的のラジオ番組をダウンロードする。TBSラジオは人気が高いので、たいていの番組はアップロードされている。ただ手動でダウンロードするのは意外と面倒ではある。
3. radikoプレミアムに入りたくないなら、スマホを直接PC、もしくはラジカセにぶっ挿して録音する。
これはTBSラジオが聞ける環境の人ならRadikoolで事足りるので、radikoプレミアムに入りたくないないがTBSラジオは聞きたいという人向け。
iOSデバイスならPrivete My Privacyという脱獄アプリで位置を偽装、AndroidならrazikoというアプリでradikoでTBSラジオが聞ける。それをそのままPCやラジカセに直接接続し録音する。超アナログな手法だが、意外と使える。
4. 今度始まったTBSラジオのストリーミングを独自に解析して、ぶっこ抜く
http://anond.hatelabo.jp/20160606084656
・まず全サイトの301への対応は不可能だ、というかすべきでない。
なぜかというと301が、本当に「元と同じ内容のページに飛ぶ」かはわからないからだ。
これはセキュリティ的な話（スパムサイトに飛ばされるとか）もそうだし、
そもそも301の利用法として「全部トップページに飛ばす」「共通のエラーページに飛ばす（つまり301→404）」という使い方が商習慣的にされているのが厄介の種だ。
はてブはエラーページに過去のページのブクマをまとめる阿呆なサイトになってしまう。
更に言えば302と301の区別がついていない阿呆なエンジニアというのもまたいるわけで、
そういうサイトがメンテなどで全部301転送してしまっているところにたまたまクローリング等かけてしまったら、目も当てられない。
・じゃあ個別サイト対応（今回ならImpressだけ）とかもありなのかもしれないけど、
301は不可逆（旧→新はいけるが、新→旧）なので、基本新しい方に既存のブクマを載せていくことになるが、
じゃあ仮に登録制（旧→新の組み合わせをはてな側に登録する）として、
impresの登録の通りにして、もし登録内容を間違えていて翌日直したとして、
あるいは301が実際に行われてから、登録されたブクマはどこに行くべきなのか。
（というかおそらくURL構成上はてぶはURLをユニークのベースにしているし、
何せ存在しないURLにもブクマできてしまうザルなので、二つのページのブクマを同じにするだけでかなり大変なのではと推測する）
とはいえ、転送前と後両方についてのページがあるのははてな的にはむしろSEO上不利（同じ意味のページが2つできてしまう）な気がするので、
これは普通にそろそろ現れそう
今もあるけど、もっと高性能化して、お手伝いロボとして一家に一台あるくらい一般化して欲しい リアルなのよりメカメカしいのが好き
お家にいながら話せるぜ。面接の交通費がかからなくなるぜ。今もありそうだけど(ていうかスカイプ？)、どの就活に使われるくらい実用化して欲しいんだぜ。
漫画とかによくある携帯から人の顔の立体映像が出るやつ 利便性はともかくかっこいい
ATフィールドみたいなの。背後からスナイプされても安心だ。後かっこいい。
会社から家まで1秒で出勤出来る。たまに異次元の間に飛ばされてそこから始まる新たなストーリー。
ヘッドホン的な機械を頭につけると自分の過去、行動、性格を把握・分析。そして自分の適性にあった仕事とか相性の合う友達を見つけてくれる。自動自己紹介機能付き。
自分のことなんて自分にも他人にも理解できないからすげー欲しい。適性に合った仕事あてがって欲しい。
・かっこいい機械乗り物
Dホイールとかコナンのスケボーとかみたいな変形したり多機能だったりorターボ付き的なの
空飛べたらなおよしっ
・変声期
これで自分の声を録音して死にたくなることや、返事しても声が小さすぎて「え？〇〇いないのか？」って言われることがなくなる
スマホが出てきたときは大分近未来感じてワクワクした。そのうちホログラムが出せる3Dスマホとかも出そう
個人的には自己分析プログラムとロックマンエグゼ擬似人格プログラムが生きてる間に欲しい。後者はアニメ見て以来ずっと思ってる。
久しぶりにMMORPGをやってみたくなって探してみた。
MMO歴は大昔にテイルズのオンラインゲーム(ウィーバーじゃないやつ、エターニア？)とか、友達に誘われてトリックスターをやってみたりとかしてた程度。
大体どのゲームでも、ある程度レベルを上げたら序盤のエリアや拠点付近に座り込んで人の往来を眺めたり、
街でわいわいみんながやってるのをちょっとはなれたところに座ってじーっとROMったり、
街中を散歩したり、たまに気が向いたらちょっと外に行ってレベル上げをしてみたり、なんとなくできた顔見知りと一緒に初心者のヘルプしたりする感じ。
話しかけられたら多少は返事するけど、別にそんなに熱心にチャットしたりはしない。ギルドとかにも別に入らない。
どうも、現実では煩わしかったり、病気になっちゃったくらいストレスの方が多くなる「人がいっぱいいてザワザワしてる状況」を、画面とウィンドウ越しに眺めるのが自分にはちょうど心地いいらしい。
そんなわけで去年からいくつか探して遊んでみている。iPad持ってるのでiOSとPC。
【iOS】
何にしても全部チャットが打ちづらいので、話しかけられたときに返事ができなくて申し訳ないからメインにしづらい。
・AVABELオンライン
アソビモの稼ぎ頭っぽいタイトル。
キャラクターがみんな頭身が高い、美男美女しかいないけど初期キャラメイク幅はiOSのMMOではそこそこある方だと思う。
でもなんかシルエットが似かよるせいか、どうやっても割とみんな同じに見える……、アバタ―ありきな感じだから別にいいけど。
割とドロップとかでもアバタ―がポンポン手に入るので楽しいし、無課金アバタ―なら結構安値で市場に売られているのでちょっとお金貯めたら買えたりする。
遠距離職でチクチクやってるだけでもなんとかボスとかは倒せるけど俺には結構難しい、罠とかのないモンハンみたいな気分。
人が多く、チャットはクレクレとギルド勧誘と中高生っぽい会話であふれていて活気がある。
転送装置の中で土下座したり灯台に登って焼き土下座したりして遊んでた。
23Fまでプレイしてちょこちょこ知り合いができてたけど、忙しくなったタイミングで一切触らなくなって、なんとなく復帰する気になれなくて凍結。
アソビモの割とあたらし目のヤツ。キャラクターの頭身が結構低い。MMOっぽさはかなりあると思う。
なんか俺にはゲームプレイが全体的に難しくて、バカスカビーム撃ってくる序盤のボスっぽいのを必死になって倒したあたりでリタイア。
・Klee～月ノ雫舞う街より～
頭身の低い人形みたいなキャラクターを着せ替えることに重点を置いてそうなゲーム。
クエストにいく度にダンジョン作って潜る系。ほんわかした雰囲気とトテトテ走るキャラクターの動きが可愛い。
あっという間に戦闘に飽きて完全な町人となる。バグを使って街の中で壁抜けして街灯の上に登ったりして遊んでた。
街灯の上で自キャラを躍らせたまま付近を歩き回る人々をただただ眺めて2時間過ごせる程度には居心地がよかったし、
時々絡んでくれる知り合いもできたけど、しばらく休んでる間に気が付いたら過疎がとんでもなくひどくなってた。
・オーダー＆カオス2：リデンプション
PC向けMMOっぽい感じのガチ感あふれるMMO、俺が触った時はチャットはハングルと英語が飛び交いまくりだった。
文字が小さかったり表示が消えるのが早かったりしておつかいすらなかなか満足にこなせない。
グラフィックもシステムも俺にはちょっと重すぎた。ただただ圧倒されてリタイア。
・イルーナ戦記
またアソビモ。古くはiアプリだったらしい歴史あるゲーム。グラフィックやUI等、全体的に時代を感じる荒さがある。
パーツによってはテクスチャ伸ばしまくって使ってるからドット見えてまっせ感。なんかハンゲームとかで昔こんなMMOなかったっけって思う。
髪型の選択肢から女性アバタ―偏重の姿勢が読み取れて面白い、性別に関係なく髪型を選べるので、ドリルツイン男子も作れる。キャラは4頭身ぐらい？
狩りは割と単調にペチコンペチコンオートでし続けるタイプ、もっとレベル上がったりジョブチェンジすればスキルとかもどんどん使うのかもしれない。
深夜に一人でドングリ追い回してたら親切な通りすがりの人が突然メールで謎の盾をくれて、その盾なしでは生きていけない体になった。
町の中央部は人が多いけど、分からない単語で何かの募集がかかっていたり取引を持ちかけていたりして、
まったり身内でチャットしてるような人たちは大体自分の世界(島？)に引きこもっている様子。
無心でモンスターを狩る作業が割と睡眠導入用にいいので今も時々起動している。
【PC】
進化しすぎていてとにかく難しい(というか俺がついていけない)ゲームが多い。
ちょっと頭身低めのキャラを動かす3DのMMORPG、かなりいろんなことをやって暮らしていける感じっぽかった。
自由度の高さがそのままチュートリアルのダルさになってしまっていて、
チュートリアル村を抜けた後割とすぐに何をすればいいかわからなくなってリタイア。
結構過疎ってる感じがした。
・ArchAge
なんかグラフィックとか綺麗系、獣人の男を選んだけどキャラクター作るのに3時間かかった。
敵が動かなくなるまでボッコボコに殴れば雑魚モンスターは大体倒せるけど、そこそこ淡白な戦闘に対してストーリー展開がなんか重い。
画面の情報量が多くて老いを感じる。選んだ鯖が悪かったのか、3日間ぐらいプレイしたけど動いている他プレイヤーを2人しか見掛けなかった。
・TERA
ファンタジーにかなり寄せた感じのMMORPG、いろんな見た目の種族がいるけど一部の職には特定の種族や性別でないとつけなかったりする。
Wikiを少し読んだら、初心者にはおすすめできないって書いてある職ばかりでアワワワってなった。
拠点が分散しているのかビギナーサーバーなのがダメなのか、ArchAgeほどではないけど人がいない。
最序盤のシナリオで何回も死にかける程度には戦闘が難しかった。ちょっとオーダー&カオスと似てるプレイ感。
かばんがいっぱいになった後、買い取ってくれる店がわからなくて1時間近くさまよった。
今のところ、このゲーム続けるか！っていうのにまだ出会っていない感じ。
まず探してみてびっくりしたのが、今のMMOが大体どれも3Dになってること。すげーな。
すげーんだけど俺にはちょっとしんどい。三人称視点のWASD移動なり仮想パッド移動なりがこんなにかったるいとは思わなかった。
自分と他人が1画面でテーンって並んでる感じのカメラ位置が落ち着くなーって思った時点で、
思いのほか自分がクォータービュー向きの人間だったことに気付いたけど、そんなこといっても世の中の流れはそうじゃないみたいだからしょうがない。
色々触ってみて、自分がMMOに求めるのは適度なガヤガヤ感(あんまり過疎ってない)と、
着せ替えたり装備を変えたりしたのが見た目に反映されて、ひとりで眺めて満足したり、入手した達成感を得られる程度のアバターの量。
できれば3Dでもめっちゃリアルなやつよりはちょっと等身が低めの方がいいのかもしれない。でも多分2Dの方が好きそうだ。
後は本格MMOみたいなやつがどれも難しく感じたので、あんまり戦闘重視じゃない方がいいかなー？とか、
ダンジョン生成して数人で潜るのがメインループになるゲームは、狩りを楽しめなくてあんまり向いてないっぽいなーといったところか。
Tree of Saviorっていうのが今年中に日本サービスインするって話なので期待しているのだけれど、それまで何をやろうかなー。
いっそラテールとかメイプルとかそういうのやってみた方がいいんだろうか？
なにかおススメとかあったら教えて欲しい。
・ワイルドドロー4は、色宣言後ドロー4または宣言された色のドロー2・リバース・スキップでチェイン可
・雰囲気でカードに名前を付けたりして、場に出す時は何かしら声を出す
例)
A「イエローゼロ！ZONO！！そぉら怯えろ！竦め！」(黄0・残2枚)
C「ライトニングスプレッドミサイル！」(黄D2 + 青D2)
E「スキップスキップランランラン！」(赤S + 緑S + 緑S)
G「アトミックワイルドドローフォー・ウィンド！」(WD4→緑)
高校の頃数年間、ほぼ毎日やっていたから染みついてしまっていて、いまだにUNOをやると自然と変なテンションになる
外部の人を交えて遊ぶときに毎回ビックリされるし、もうみんな三十路に近づいてきたので、
人生50年と言われた時代ならもう折り返し、何もすること無く連休が終わるので振り返る。古い記憶は思い出すのが難しく、新しい記憶ほど濃く出てしまうのは仕方ない。
進研ゼミをやってたこともあり勉強はそれなりに、いやそもそも小学校の範囲なんて普通に聞いてればどうにかなるだろうと。
運動は苦手というか嫌いで部活はインドア系、今で言う程の虐めは無かったがからかわれたりされるキャラ。同じ目立たな系グループや、全方位社交的タイプの人や、辛うじてまだ友人と呼べる人がいた。
この頃、パソコン(PC-9821)を買って貰った。もちろん建前は一家共用のもの、だけど実際に使うのはほぼ自分だった(PC-98というところかしてお察しください)。
当時のパソコン通信もやるようになり、「馬鹿(なことを言う奴)は叩かれる」という現代に通ずる教訓を得ることができた。
そして勉強。生来のズボラさ、真面目系クズの因子があるとこの辺で勉強に付いていけなくなる。当然、落ち零れ始めると進研ゼミはテキストも開かない、課題提出もしないまま高3まで継続することになる。
この頃、一人だけ自分に対して話しかけてくれる女の子がいた。「○○って好きな人とかいるの？どんな人？だれだれ？」と妙に絡んできたり、将来はパソコン使う仕事がしてみたいとか話したら、教室の班内で日記的なものを順に書き教師に提出するノートで(明らかにそんな興味はなさそうなのに)「パソコンの仕事がしてみたい」と書いたり、それなんてエロゲ的な知識からするとフラグと思えなくも無いが目に見えないフラグなんて何の意味も無いし気付くわけが無い。しかし今でも夢に見ることがある。お陰で、上述したエピソードどころかその存在すらも夢の中で自分が妄想したものではないかとすら疑い始めている。
この辺りから、顔を知っているという程度の知人はいても友人というほど親しい存在がいなくなっていた。放課後に誰かと遊びに行くこともなく、パソコンにかまけていたんだと思う。
中学時代の女の子は帰り道が一緒になったときに声を掛けてくれたりたまに話してくれたりもしたが、いつしかそれも無くなり、逆に自分が無意識に目で追っていることに後で気付いた。
大学受験は散々だった。理系なのに数学の内容が全く理解できない時点で終わってる。結局、3月過ぎの最終日程で、得意な現国一教科受験が可能なFラン大学の新設情報系学部へ滑り込みを果たした。
(高い)金さえ出せばアホでも行けるという周囲の評判通り、他学部ではチャラそうな男女が目に付いたが、一日自由に誰の目を気にすることも無く快適なパソコンとネットが使えるというのは大変に魅力的で暇さえあれば通い、家では新作エロゲをひたすらプレーしていた。
ゼミのメンバは(イベント毎があれば何かしたがるリア充的な彼ら特有のノリで)大変に気さくで飲みに行くこともあったが、それ以外の場ではやはり話す人も無く、遊びに行く友人も無く、淡々と3年で必修単位を取ることに徹した。卒業1年後、ゼミの同窓会的な催しの連絡があり行ったが、その後は音信不通となった。
氷河期と呼ばれる時代は辛い。私はこの時点まで使う必要がないことから携帯電話を持っていなかったが、さすがに差し障りが大きいということで親名義のものを譲って貰った。
就活は自己分析に始まり自己否定に終わる。誰もが思ってもいない建前を並べ、何処でも良いから内定を寄越せという本音を隠そうとするがそれでも否定され、自分が社会に不必要な存在であると言うことを実感させられる。
「性格分析の結果だと、凄く明るくて社交的なのに全然違うね？」と宣うぐらいなら、性格検査なんていうアホな試験をさせるべきでは無い。何処の世界に就活で、自分は暗くて内向的なコミュ障ですとアピールする奴がいるというのだ。
「凄く優秀そうなのに、どうしてまだ未内定なのか不思議です」、その理由はすぐ横にいる人事に聞けばいい(これを言われた面接で落とされた)。
しかし50、60、と面接の回数を重ねると利点が一つだけ有る。心身が疲弊しきって、面接程度ではもはや緊張を覚えなくなるのだ。相手も本気で新卒に何かを求めているわけじゃない、地雷かどうかを見極めているだけだ。グループ面接で聞き飽きた他人のエピソード第一位は「サークル or バイトのリーダーとしてイベント or 仕事を成功させた」だが、横で聞いてる自分ですらまたかよと思うのに採用担当者ともなればもうやめてくれと思うんじゃ無かろうか。
そんな無我の境地が奏功したのか、一社だけ内定を得ることができた。自分のやりたかったこと(開発)とは微妙に異なるがIT系ではあるので運が良かった。
アキバをオタクの聖地だなんて今でも言うのか知らんが、半導体からアニメまで界隈に集い、ここに慣れてしまうと他が物足りなくショボく見えてしまうのは仕方ないことだと思う。毎週通うために回数券で切符を買っていた。
仕事の方は、残業70～90H/月程度だったがこの頃は羽振りがまだ良く残業時間にうるさくは無かった。むしろ残業代の形で還元されることもあり、周囲含めて生活残業が多かったのだと思う。
しかしそんな給与は1円も貯金すること無く、エロゲやアニメDVD、同人誌、マンガ、CDへと消えていった。
社会人何年目かで、アキバで出会ってしまったのがいわゆるドールだった。フィギュア的な造形でありながら、フィギュア以上の表現力を持ったそれにすっかり魅せられてしまった。
ドールは大量生産に向かないためか通常に買う場合でも一体6～10万、過去の人気ドールともなるとヤフオクで20万、30万、もしくはそれ以上という異常な価格となる。しかし買えない価格では無い。そう、社会人にとっては多少無理をすれば大抵のものは買えてしまう。
ある時、どうしても欲しいドールがあり、初めてキャッシュカードに付属したキャッシング枠を使った。そしてクレジットカードと同じように後日それを返すだけ。
人間の感覚というのは本当に恐ろしいもので、一度味をしめると慣れが生じる。経験が油断を生み、警戒心を歪ませる。
間が悪いことにこの頃、親会社への出向が解除となり入社以来縁がなかった自社に戻ることになった。子会社にとって残業時間管理は死活問題、定時を過ぎて用が無ければ帰れとしつこく言われ、何年かぶりに明るい時間の帰宅をした時は戸惑うしか無かった。
残業時間が減れば残業代が減る。残業代が減れば収入が減る。収入が減れば欲しいものが買えなくなる。ここで話は戻り、足りないなら借りるしかないということになる。
最初のキャッシュカードの使用枠はいつの間にかなくなり、別の消費者金融のカードを作っていた。最初は50万だけだったのが、100万、200万となり、気付けば借金は3社で計400万近くなっていた。
消費者金融における総量規制により年収の1/3以上を借りられなくなるという話を聞いたとき、ようやく現状を省みることができた（総量規制に便乗した、いわゆるおまとめローンの案内が来た）。
多分、一種の買い物依存症だったのだろうと思う。買うという行為自体に満足感を覚え、DVDやマンガなどは買ったときのレジ袋のまま部屋に放置していたというのがその証拠だろう。酒や煙草は全く嗜まないこともあり、溜め込んだストレスを知らず知らずのうちに買い物という方法でしか解消できなくなってしまっていた。
この400万近い借金の返済には6年を要した。途中、1円単位で小金を集めて用意することもあったが一度の遅延もなく（信用情報上、大きな借金がある時点で不利なのにさらに遅延があると極めて不利になるので絶対に避けたかった。また、大きな借金があっても遅延無く支払っているのであれば継続的に安定した収入があると見做される）、むしろ終盤には収入が増えて余裕ができたこともあり予定より三ヶ月ほど早く完済が叶った。
あれほど金が無い、金が無いと言っていたのに今では200万程の残高がある。しかし三十路を過ぎた男が200万しか貯金が無いというのは余りに情けない。
しかも20代の頃はただ闇雲に浪費を重ね、何かを極めたわけでも、引き換えに何か誇れるものを得たわけでも無い。そして30代の前半は今月分を返済したら幾ら残るかを考えるだけで過ぎてしまった。
社会人になってから自名義で契約した携帯電話としてiPhoneを持っているが、その番号を知る知人、友人、家族はいない。掛ける相手もいないので履歴は全てセールスの着信で、発信履歴はない。
一度、中学校の同窓会案内が転送されてきたことがある。当時はそれどころではなかったのと、中学時代の同級生に特に思い入れも無かったこともあり返信すらしていなかったが、引越の時にその案内書がでてきた。よくよく見ると同窓会の告知するwebサイトの案内があり、ふとした興味で何となく覗いてみた。いわゆるBBS、当日の写真といったものがあり、聞き覚えのある名前を発見することができた。
写真は年相応になった懐かしい(…とはあまり思えなかったが)面々、年老いた教師、といったものだったが、BBSの方は久闊を叙するメッセージの狭間に「当日は子供の世話が…」「嫁の都合で…」といった文言が有り衝撃を受けた。恐らく当時は26、27ぐらいの年齢だと思うが、見覚えのある名前がそういう状況になるというのはなるほど奇妙なものだ。赤の他人の話であることに違いはないのに、すぐ横で出し抜かれたような気がしてしまうのだ。
今となってはもう友人も恋人も結婚も望むべくもないし全てが遅すぎた。もし来世があり、草や木に生まれなかったのなら次はもう少し人間らしい人生を送ってみたかったと戯れに考えてしまう。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 のような場合は期限切れがあってはならないので、パスワード等を預かる認
元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか
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
現在、1.34Mbpsしか速度が出ていない。(まだ、ましなほう。もっとひどいと1Mbpsを割り込むｗｗｗ)
測定サイト： http://www.musen-lan.com/speed/ Ver5.6001
測定日時： 2016/03/01 22:50:52
--------------------------------------------------
1.NTTPC(WebARENA)1： 1.34Mbps (167.03KB/sec)
2.NTTPC(WebARENA)2： 804.66Kbps (100.39KB/sec)
推定転送速度： 1.34Mbps (167.03KB/sec)
以前も同様の症状が一カ月以上発生していて、
はぁ？
では、お前らはなんの努力をしているのだ？
大々的なキャンペーンを打って、さらに加入者を増やすことなのか？
何も理論値通りの速度を求めているわけではない。
それともインフラ業界のやつらは、ちゃんとサイジングできないの？ バカなの？
客が1000人もいるにもかかわらず、1人前の料理しか提供されていないのと同じ。
こんな食べ放題の店があったとしたら、返金騒ぎでマスコミも押し寄せるだろ？
なのに、通信だと「ベストエフォート」という免罪符で許されるのか？
プロバイダーだけのせいにするなよ。エンドも含めて監視しろよ、カス。
深夜・休日など小児科が繋がらない時間帯において、この番号に電話をすると小児科医師・看護師から、子どものの症状に応じた適切な対処の仕方や受診する病院等のアドバイスが受けられるというサービスで、母子手帳や市区町村の発行する書類などにも再三「困ったら#8000」などと記されている。
夕方から３か月になる娘が熱を出したため、この#8000に電話を掛けているのだが、一向につながらない。
たった一度だけつながった時があったのだが、機械音声で「担当医に転送します」と言われ、その後「電話がたいへん込み合っていますのでおかけ直しください」と言われて切れた。
その後は何度かけても話し中でまったくつながらない。
今も子供は高熱で苦しんでいる。
