「SECRET」を含む日記

■anond:20171120235424

ヴィクトリアズ・シークレット歴代『エンジェル』モデルまとめ【Victoria Secret】

https://matome.naver.jp/odai/2135029996694213001

普通に白人以外も山ほどいるやん。

増田が白人フェチで白人以外は目に入っていなかっただけでは？

元々昔から白人至上主義なんて方針ではなかった企業が、白人フェチ日本人の勘違いによりそう広められるって最早風評被害だな

Permalink | 記事への反応(4) | 10:14

ツイートシェア

■『Re:ステージ！プリズムステップ』がアイドル音ゲーの新境地に立った

ちょっと前、パズルゲーなのか音ゲーなのか、なんかよくわからないゲームの動画がツイッターのTLに流れてきた人は多いのではないか。

それが『Re:ステージ！　プリズムステップ』のゲーム画面だ。公式略称はリステとかリステップとか。

Re:ステージ！ってメディアミックスコンテンツがあって、そこからアプリに派生した、のかな？

いかんせん私も件の動画を見て興味をもった人間なので、このコンテンツがどれだけバケモノなのかは追えていない。

まあ、CD出したり声優ライブやったりしたコンテンツが、スマホ音ゲーにも進出したってのが今の時系列なんだと思う。多分。

にわかで申し訳ない。

とまあ軽い気持ちでアプリをインストールしたんですが、すごかった。

上から降ってくるノートを叩くゲームは散々やりましたが、ここまでライブ感、ことライブを作り上げる感覚を味わえるゲームは今までなかった。

ゲームの根幹に音ゲーを採用している理由がはっきりわかるゲームは初めてなのでは。

本当にすごい。

――これだけじゃ何も伝わらないと思うのでゲームの解説を少し。

この音ゲーのノーツは2種類。タップするやつとタップしないやつ。判定ラインは7レーンあり、そこに3種類の色が振られる。

そして、降ってくるノーツの色に判定レーンの色を合わせて、タップするノーツはタップする、タップしないノーツは合わせるだけ合わせて放置する。

色が合っていればパーフェクト。タップがズレていたり、タップしないノーツを遅いタイミングで色合わせするとグレートとかに判定が落ちていく。

タップを忘れたり、色を間違ったりすればミス。ダメージを受ける。

色を瞬時に判断して合わせるというパズル要素の強い音ゲーだ。公式が「思考型リズムアクション」と銘打つほど思考とアクション要素が大きい。

これだけ聞くとパズドラみたいなパズルを解きながら2分間で800ノーツ捌くみたいな理不尽ゴリラゲーを想像してしまうかもしれないが、実際はパズル前は密度が緩くなるし、そもそものパズルが1レーン隣と位置を入れ替える程度なので、「1小節以内に7箇所全部入れ替えなさい」みたいなことはない。

タップノーツも決して密度が濃いわけではなく、既存の音ゲーをある程度やっている人なら量を見切れないということは無いはずだ。

なので、「斬新な発想に基づく、簡単ではないが無理ゲーでもない」ってのが、このゲームの評価になる、と思う。

この音ゲーに包含されたパズル要素が、リステップを既存アイドル音ゲーとは別の境地に導いている。

この色替えパズルは、アイドルライブのフォーメーションチェンジと同義なのだ。

アイドル音ゲーで判定ラインに編成した女の子が並んでいるのは、そういうユニットを組んだからだ。

それはスコアのためだったり、オリジナルユニットのためだったり、艦隊組んだり推しをMVに出すためだったり理由は人それぞれだが、判定ラインには自分で選んだ女の子達の顔が並んでいる。

「推しの顔面殴りたくない」という声もたまに見かけるくらいだが、判定ラインが女の子なのは「そういうもの」としてアイドル音ゲーの常識になっていた。

リステップは、その常識にメスを入れた。

パズルによってアイドルの立ち位置が曲中に変わっていく。

センターの子が端に移ることもあれば、端の子がセンターに入ることもある。

もちろん曲によってそのパフォーマンスは異なる。

サビにセンターからステージの端の方に移動する曲はスタンド席へのファンサとして最高だし（Secret DreamのHardとか）、

同時押しの直前にフォーメーションを変える曲は、そのペアで会場をアオっているのではと錯覚すら覚える（君に贈るAngel YellのHardとか）。

デレステやミリシタのようにMVはないが、だからこそ譜面から演出を好きに妄想することが出来る。

判定ラインに意味を見出したこのゲームは、「アイドルがライブを成功させる」ゲームの別解を示すことに成功した。

リステップは音ゲーではない。

判定ラインはアイドルの立ち位置であり、ノーツはバミリだ。

プレイヤーであるあなたは、バミリを見てフォーメーションを変化させるようアイドルに指示を出す。

曲に合わせて、譜面の演出に合わせてステージを作り上げていく。

文字通りの思考型リズムアクションゲームなのだ。

多分、「ライブ再現の発想としては面白い。けどゲームとしては……」で止まっている人も多いと思うが、是非一度体感してほしい。

既存音ゲーにはないライブシーンを演出する爽快感が、きっと刺さるだろう。

Permalink | 記事への反応(1) | 01:37

ツイートシェア

■融けないアイスクリームの開発者って放射性物質を吸着するK525の人なんだな

金沢大学発の融けないアイスクリームが海外のニュースサイトで話題になっているのを見かけた

• Japanese scientists have created ice cream that doesn’t melt. Here’s how ヒンドスタン・タイムズ
• Japanese scientists create ice cream that doesn't melt Phys.org
• Ice cream that doesn't melt! Japanese scientists create a recipe that includes a secret strawberry extract to keep the treat cool in warm weather デイリー・メイル

はてなでも数十のブクマを集めていた

http://b.hatena.ne.jp/entry/www.asahi.com/articles/ASK7F3GV8K7FPXLB00W.html

国内の記事ではマイナビが一番まとまっている

溶けないアイスの仕組みはどうなっているの? - 金沢大学の名誉教授に聞いてみた マイナビ

この材質を作ったのって福島原発事故当時話題になった汚染水から廉価に放射性物質を吸着する物質K525を開発した太田富久名誉教授だったんだな。すごい。

Permalink | 記事への反応(0) | 09:44

ツイートシェア

■http://anond.hatelabo.jp/20170406082549

Victoia's Secretで探してみては

Permalink | 記事への反応(0) | 08:35

ツイートシェア

■http://anond.hatelabo.jp/20170219143625

曲とアニメAnilogia IDの対応表です。

ご確認お願いします。

Permalink | 記事への反応(0) | 14:39

ツイートシェア

■Hearthstone3大Pay to Win

謎めいた挑戦者/Mysterious Challenger

6/6/6　雄叫び(Battlecry): あなたのデッキから全ての種類の秘策(Secret)を1枚ずつ場に出す（ただしゲームシステム上、展開できる秘策は5種類まで）。

比較対象ーボルダーフィストのオーガ/Boulderfist Ogre　6/6/7

本体のスタッツと能力の強さが全く噛み合ってないぶっ壊れ。登場時に貼る秘策（条件が満たされると自動で発動する罠カード）の中に「相手がこちらのミニオン（MTGにおけるクリーチャー）を攻撃した時2/1の身代わりを召喚してターゲットを移す」と「こちらのミニオンが倒された時こちらのミニオン1体を+3/+2する」がまず含まれているので実質的なスタッツは9/8相当。その上で他にも「こちらのターン開始時にこちらのミニオン全てを+1/+1する」や「こちらのミニオンが死亡した時、体力1で復活させる」などを貼っていくという頭のおかしさ。何故か弱体化されることなくスタン落ちを迎えつつある。現在は秘策カードのうち強力なものがスタン落ちしてしまったため一応影を潜めつつある。HSにはワイルドというエターナル環境があるためもっぱらそっちで暴れているためスタンでは見かけなくなったという言い方のほうが正しいかも知れない。

ドクター・ブーム/Dr. Boom

7/7/7　雄叫び(Battlecry): ブームボット(Boom Bots)を２体召喚する。注意:ロボットは爆発する恐れあり。

比較対象ー戦のゴーレム/War Golem　7/7/7

同じコスト同じスタッツの戦のゴーレムに対してお供2体が出る代わりにリスクあり、誰もが最初はそう思っていたカード。ブームボットの性能は1/1/1とそれ自体は大したことがないのだが「死亡時ランダムな相手ミニオンかヒーローに1~4点のダメージを与える」という能力を持っている。ダメージが飛ぶのは相手だけ、つまりこのお供カードにはメリットしか詰まっていないのだ。ブームボット自体の攻撃力を合わせると平均して1+1+2.5*2で7点分のダメージを出してくれることになる。極端な言い方をすればブーム1枚で戦のゴレーム2枚と相打ちになれるだけの能力を持っていることになる。その上で小回りが効きどんな状況にも対応できることや相手がこれらを無傷で処理するのがほぼ不可能なことなどが評価されよほどの軽量デッキでもなければどんなデッキにも入っていた。これまた何故か弱体化されることなくスタン落ちまで暴れ続けた。

海賊パッチーズ/Patches the Pirate

1/1/1　突撃（MTGでいう速攻）　自分が海賊を使用した後、自分のデッキからこのミニオンを召喚する。

比較対象ー石牙のイノシシ/Stonetusk Boar　1/1/1　突撃

つい最近HSぶっ壊れレアカード界に超新星の如く現れた期待の新人。"海賊"という属性を持ったミニオンを召喚すると自分のデッキから勝手に飛び出してくる。専用デッキを必要とするしサイズも小さいのだがノーコストでボード展開とデッキ圧縮をやるのだから恐ろしい。突撃の効果により出したターンに相手にダメージを与えてくれるので全体除去に巻き込まれて何の仕事もせずに消えるということはない。このカードと同じタイミングで他にも1マナの優秀な海賊が加わったため1ターン目にデッキから飛び出すことも可能であり、その場合AOEが飛んでくるまでにはタイムラグが生まれ十分な仕事が出来る。もし序盤で軽量のAOEが飛んできても他の海賊カードはまず残るのでテンポ的に問題がなく、相手が1マナのカードで処理をしてもこちらが使っているのは実質0マナであるためやはりテンポを取っていると全くスキがない。テンポを取りつづダメージクロックをかけつつデッキを圧縮するというアグロにとって最高の仕事をしてくれる。多分これも弱体化することなくスタン落ちを迎えるのだろうが、それまでに一体どれほどの悪行とヘイトを積み重ねるのだろうか。

Permalink | 記事への反応(1) | 18:00

ツイートシェア

■Victoria's Secretのリアルワンピース見てると

https://www.youtube.com/watch?v=eht4vSOY4Wc

全員セックスさせてくれないかなー無理だろーなーと思って落ち込む。

Permalink | 記事への反応(0) | 16:55

ツイートシェア

■「[DVDrip-HD]] waTch The Secret Life of Pets Full'Movie'Online'Free [2016] streaming」

https://vimeo.com/179848100

https://vimeo.com/179848100

https://vimeo.com/179848100

Permalink | 記事への反応(0) | 13:55

ツイートシェア

■「Watch The Secret Life of Pets Full MOVIE HD (2016) Online」

https://vimeo.com/177807998

https://vimeo.com/177807998

https://vimeo.com/177807998

https://vimeo.com/177807998

Permalink | 記事への反応(0) | 21:59

ツイートシェア

■「[1080p] Watch!! 'The Secret Life of Pets' FULL Online Free (2016) HD」

https://www.change.org/o/1080p_watch_the_secret_life_of_pets_full_online_free_2016_hd

Permalink | 記事への反応(0) | 10:03

ツイートシェア

■個体値計算で話題になっている件

http://gigazine.net/news/20160802-pokeiv-pokemon-go/

GIGAZINE経由で話題になっているサイトの仕組みについて、私はあのサイトの作者でないけど、解説してみます。

ブコメを眺めていて問題視されてるのは

A. パスワードが盗られのではなかろうか

B. ポケGOを勝手に操作されるのではなかろうか

C. Tokenの管理が杜撰だと危険ではなかろうか

の3点と思われます。

以下、危険性について述べます。

実際に中の人がどういう運用しているかは中の人次第なので、信じるか信じないかという話になるから、水掛け論がはじまるだけなのでやめときます。

まずAについて

Pokémon Trainer ClubについてはYes。そりゃパスワード入れてますもの。

Google AccountsについてはNo。あくまでもパスワードを入力する先はGoogleになるので、他のサイトは介在できない仕組みです。

以下、Pokémon Trainer Clubについては自明なので言及しません。

Bについて

Yes。

どのくらいの長さの時間使えるかは分からないですが、Access Tokenかセッションのどちらかの有効期限内では、勝手に操作出来るものと思われます。

Cについて

可能性は低いがYes。

ただしポケGOの実装次第です。

以下、理由を。

まず彼のサイトの認可取得方法は、OAuth2という物にもとづいています。

これは、あるサイト上のユーザリソースを、外部のサイト若しくはプログラムから操作する場合に用いる方法です。

OAuth2自体はオープンかつセキュアな仕様ですが、運用によっては当然危険な事が起こりえます。

よって、Aについては(Google Accountsならば)No。そもそもパスワードを受け渡さないための仕組みだからです。

さてこの仕組ですが、認可を得るための方法は幾つかの手段があります。

ココでは彼のサイトで使っている方法(AndroidアプリやiOSアプリなどのための認可手段)だけを説明しますと、

1. OAuth2 ClientIDを用いてAuthorization Codeを取得

2. Authorization CodeをOAuth2 ClientIDとClient Secretを用いてAccess Tokenに分解。Authorization Codeは一回のみ使用できる(あってますよね？)

3. Access Tokenを特定の場所に投げることで、サイト側はユーザの情報を知ることが出来る

となります。

彼のサイトで用いているアクセス範囲で確認できるのは、ここでAccess Tokenを用いて取得できるのは、Google Accountsのメールアドレスくらいです。

コードをコピーする仕様になっていますが、それは1と2の間で行われています。

もし何らかの手段でConsumer Secretを知っているなら、Access Tokenに分解する作業は彼のサイトで行っている可能性が高いと思われます。

しかし、普通Client Secretはサーバサイドに置き、APIで分解する形が多いと思われます。

分解された後のAccess Tokenは一定期間で有効状態が切れます。

Client IDはある意味オープンな情報なので、コード発行画面までは、知っている人なら比較的たやすく表示させることが出来ます。

よって、「ポケモンGOが」と表示されているのは、このClient IDが本物だから出ているのであって、彼のサイトの作者がそういう詐称行為を行っているわけではないです。

ここからは、Android用のtokenの動きを知らないので推測となります。

Access Tokenは1時間弱の短い期間で有効期限が切れます。

その後のAccess Tokenの取得は、一回ユーザが認可すると再度の取得には認可画面による対話操作を必要としない仕組みを使い、アプリケーション内で自動的に取得できるような実装になっているんではないでしょうか(AndroidやiOSに詳しい方、補足願います

また、Access TokenはセッションやDB内で管理し、クライアントアプリ側には戻さないのがよくある姿ではないかと思います

(ステートフルは重いからとクライアントに戻す実装をしている場合もあるとは思いますが)

よって、通常であればAccess TokenがBはセッション持続中若しくはAccess Tokenの生存期間中の短い時間ならYes。

Cは可能性は低いものの、Access Tokenをクライアントに送り返す仕組みにしてあり、彼のサイト側でそれをDB等に保存してあるならばYES。

となります。

私は基本的にサーバサイドの人なので、クライアントサイドの常識はそーじゃねーよって話もあるかとは思います。

その時は…すいません。と、予め謝っておきます。

Permalink | 記事への反応(1) | 22:32

ツイートシェア

■「Watch The Secret Life of Pets (2016) HD Full movie Online」

https://vimeo.com/175583635

https://vimeo.com/175584073

https://vimeo.com/175584548

Permalink | 記事への反応(0) | 02:57

ツイートシェア

■はて[LINK-MOVIE] The Secret Life of Pets 2016 ON-LINE | Rooster Teeth

http://roosterteeth.com/post/51275330

http://roosterteeth.com/post/51275330

Permalink | 記事への反応(0) | 18:21

ツイートシェア

■はて[MEGAVIDEO] The Secret Life of Pets 2016 ON-LINE | Rooster Teeth

http://roosterteeth.com/post/51275262

http://roosterteeth.com/post/51275262

Permalink | 記事への反応(0) | 14:53

ツイートシェア

■日記Watch The Secret Life of Pets を書F~ull Movie On-line書く

http://www.ustream.tv/channel/kfsUawHjZC9

Permalink | 記事への反応(0) | 12:14

ツイートシェア

■make 10

favorite stages

ultra hell -2,4~10,12,15

secret 1-4,10

secret 2-1,4~10

secret 3-8

Permalink | 記事への反応(0) | 12:25

ツイートシェア

■ガーディアン紙の報道ってどうなの？

Tokyo Olympics: €1.3m payment to secret account raises questions over 2020 Games

https://www.theguardian.com/sport/2016/may/11/tokyo-olympics-payment-diack-2020-games?CMP=share_btn_tw

日本側の人間の名前が、出ていないようですが。

誰が関与してるのかな？

追記：この記事には、既に300以上のブクマがついていたんだねー。

ニュース自体は、テレビで報道もされては、いるのですね..w

Permalink | 記事への反応(2) | 21:08

ツイートシェア

■OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスのゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連

認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

• 必要以上のアクセス権をサードパーティに与えることになる。
• 認証情報を格納する場所が増えるということは、盗まれる危険が増える。
• パスワード等を変更したときに API 利用者側でも更新が必要になる。
• ひとつのアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
• 特別な認証要素を使っていると、制限が多すぎる。

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

1. ユーザがサードパーティのアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
3. EVS は、その指定したアクセスレベルをユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？

クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 Permalink | 記事への反応(3) | 12:44

ツイートシェア

■アルバム曲で (intro) , (prelude) , (interlude) , (reprise) , (~remix) いらなすぎ

曲数稼ぎで要らなすぎ

下手したら3曲ぐらいこの手の捨て音源入れてるアーチストもいるからな、ストレスマッハで破裂するわ

最後の曲ファイルに無音からのしょーもない音源入れてる (Secret Track) は憤死しそうになる

(Bonus Track) は、曲として成立してるならギリギリ許せる

(Radio Edit) は、入ってるとなんか嬉しい

Permalink | 記事への反応(2) | 21:45

ツイートシェア

■とある音楽ゲームの楽曲の略称一覧

3強　　　小松菜(Ashemu)、下痢(p†p)、三闘神(quell, Bad Maniacs, MENDES)

————————　連奏ゲームへの壁　—————————

地力A　　 修正(mosaic)、秘伝のタレ(Secret Tale)、更新(fffff)

個人差A　田中くん(four pieces of heaven)、バーロー(ubertreffen)、⑨(Dances with snow fairies)

—————————　未確9の壁　——————————

地力B　　 BDMN(Bad Maniacs)、PLDN(PLEASE DON’T GO)、MTYH(Music to your head)、ﾖﾛﾛ(MAX 300)、マメガ(Mermaid girl)、

同窓会(reunion)、火門(come on)、穴子(R5)、野菜(Y31)、韓国(衰色小町メランコリア)、紅鮭(Red. by Full Metal Jacket)、鯖(PARANOIA Survivor MAX)、将棋(GOLDEN CROSS)、

木田(少年 A)、松井（murmur twins）

個人差B　ﾎﾎﾅﾃﾞｰﾙ(Leaving…)、うどんげ(MOON RACE)、〆(Xepher)、やらないか(tant pis pour toi)、鎮圧七奴隷(quell)、セワンジェ(session 1-genesis-)、

( ﾟдﾟ )彡そう！(EDEN)、お味噌(蛇神)、

——————–　まずはよく見る略称に挑戦の壁　———————–

当て字C　耳(era)、竹(take it easy)、麺(MENDES)、炎(FIRE FIRE)、羽(VANESSA)、修羅(schlagwerk)、愛社員(LOVESHINE)、

愛無双(I’m So Happy)、溺死(DXY!)、時津風(Time to Air)、黒白複眼(3y3s)

直訳C　　 金角(golden horn)、青雨(bluerain)、雪嵐(snow storm)、桜嵐(sakura storm)、色(colors)、明日香(tomorrow perfume)、

白壁(Innocent Walls)、猿踊(Monkey Dance)、仕組(太陽/世界/生活)(Programmed Sun/World/Life)、

失楽園(PARADISE LOST, p†p, BROKEN EDEN)、蛇棒(Snake Stick)、冷凍光線(Frozen Ray)、息(Breath)、禁欲(stoic)、

十三(No.13)、虹虹(rainbow rainbow)、雷(thunder)、十二式(twelfth style)、偽時間(FAKETIME)、雪雁(snow goose)、

虐殺(GENOCIDE)、速猫(SPEEDY CAT)

————————-　押さえておきたい基本系　————————-

奈落天国式再編(Abyss-The Heavens Remix-)

http://anond.hatelabo.jp/20160129222946

Permalink | 記事への反応(2) | 02:39

ツイートシェア

■お知らせ◆TorayC×DJ HASHIGOTAN×DJ CyberGlass◆B!FES

告知失礼します。

今年もVillageで開催されるB!FESのメンバーが決まりました。

オールナイトイベントへの出演は初となるTorayC（World Minimal）が貴重なミニマルパフォーマンス。

またビレッジシーンから絶大な信頼をおかれているハードコアの帝王、DJ HASHIGOTANをゲストに迎えます。

そして、レジデントはスカトロニックラブ（DJ CyberGlass、ドラマー女々）が登場。

また、ビッグヒットを連発し、ブロガーズフェスティバルにも参加を果たした青兄、ホットスプリングスを中心に活躍するSUZUKI★DEATH、独自のプレイスタイルで人気を集めているKANA（Sun Bright）をゲストに迎え、12月32日に開催致します。

VJには炎を操る魔術師Hage-Xと、オリジナリティー溢れる映像で引き込む縄のゴト師も出演。

とにかく豪華、かつアングラでバイオレンスにこだわったパーティーです。

このかつてない組み合わせから起こる化学反応を全身で感じてください。

※身の安全をご希望の方は、トゲ付きアーマー（レンタル可）や手斧をご用意の上、自己責任でご参加ください。トゲ付きアーマーのレンタルは前日までの受付となります。

■ 12/32(Fri)

Guest Live:

TorayC（World Minimal）

Guest DJ:

DJ HASHIGOTAN (Black Beam)

Resident DJ:

DJ CyberGlass with ドラマー女々（スカトロニックラブ）

Guest DJs:

青兄（2Years）

SUZUKI★DEATH（Koala Records）

KANA（Sun Bright）

VJ:

Hage-X

縄のゴト師

venue : Village

open : 23:30

entrance : 3500stars(door) 2500stars(w/f)

info : http://anond.hatelabo.jp

（追加発表）

Secret Guest:

杏❤︎萌え（地蔵レコード）

えつこ（@2family house）

Masuda11（AnonymousDiary）

Permalink | 記事への反応(0) | 15:08

ツイートシェア

■AppleMusicで見つけた、アニメソングをピアノ&バイオリンでカバーしたCD

誰かに布教したかったけど布教できそうな場がなかったのでここで。

特にクラナドの「ちいさな手のひら」、あの花の「secret base」、CCさくらの「プラチナ」が好き。

https://itunes.apple.com/jp/album/sonum-armonia/id695172959

ググったら宣伝動画もあった。2013年の夏に発売したらしい。

バイオリン担当がxclassicalcatxちゃんで、ピアノ担当がzorsyくんらしい。

https://www.youtube.com/watch?v=qY_IiJfWdVc

個別のチャンネル登録数は約95000と約15000、なかなか人気。

xclassicalcatx: https://www.youtube.com/user/xclassicalcatx

zorsy: https://www.youtube.com/user/Zorsy

でも許可取ってなさそうなんだが大丈夫なんだろうか。

まぁいっか。

Permalink | 記事への反応(3) | 11:29

ツイートシェア

■ピクシブでお気に入りに入れてる人がサンクリに出るっていうから

この人被お気に入り少ないから行こうかな

サンクリ行ったこと無いや

と思って

サンクリのページに行ってみたら

SC2015 Autumn開催（2015/10/4開催）

うんちっ娘＆おしりっ娘「ぷりむす！」

THE IDOLM@STER「SECRET C@RNIVAL!」

SC2015 Summer開催（2015/6/14開催）

おむつっ娘「おむ☆フェス2」

ロードオブヴァーミリオン「LoVけっと2」　

耳かき音声作品「みみふぇす！」

って書いてあったから

やめた

Permalink | 記事への反応(0) | 10:04

ツイートシェア

■検閲ってほんとにあるのね

検閲業界には明るくないし興味もないが、たまたま見つけてへーと思ったのでここに書く。業界人にとっては何を今さら的な感じなのかもしれない。

『絶対に行けない世界の非公開地域99』という邦訳本がある。昨年末に日経ナショナルジオグラフィック社という出版社から発行された本で、表紙にも例の長方形のロゴが入っている。

私は本は頭から終わりまで隅々読む面倒なタイプなので、ずーっと眺めて行って最後に奥付を見ると、左下にこう書いてあった。

　　"100 PLACES YOU WILL NEVER VISIT: The World's Most Secret Locations"

邦訳版より一か所多い。まえがきに秘密の場所を明らかにするものである的な記述があるような本で、一か所丸々を落とすというのはなかなか高度なギャグである。

気になって原著タイトルで検索すると、何が落とされたのかがわかった。

"Ise Grand Shrine" と "Woomera Prohibited Area" の間にある、"Fukushima Dai-ichi Nuclear Power Plant" つまり福島第一原発だ。

（どうでもいいんだけど、第一ってdai-ichiなのね。そこまでが固有名詞だからか）

96番が割り振られている伊勢神宮の次は97番でウーメラ立ち入り禁止区域となっていて欠番もないし、奥付以外に疑問に思う場所がなく、明示的には何も触れられていないので、なぜ落としたのか、自主なのか外圧なのか、などは不明である。

不明であるが、わかることもあって、

• 意図は別にして、日経NG社は翻訳においてこのレベルの検閲は行う出版社である
• この本の書評がもしあれば、検閲に触れなければその書評家は信頼に値しない

個人的に最も気になるのは、この検閲を原著の著作者と出版元は認識し承諾しているのか、そもそもその必要があるのか、という点で、権利関係について単純に知りたい。

ちなみに、関連ワードでいうとチェルノブイリは載っている。

最後に、この本は割高な雑学本といった感じで、検閲云々を完全に抜きにしても定価2200円＋税で買うかどうかは慎重になった方がいい。

（買いたくなった本は迷わず買っておけと良く言われるが、それでも衝動買いはよくないというのが、この本一番の教訓だった）

Permalink | 記事への反応(1) | 22:34

ツイートシェア

■http://anond.hatelabo.jp/20150227111003

ドラマ主題歌で有名になったのはZONEの「secret base」の方じゃないか。

「夏祭り」もドラマ主題歌だったけど、それで売れたっていうイメージはないな。

Permalink | 記事への反応(0) | 11:16

ツイートシェア