「サードパーティ」を含む日記 RSS

はてなキーワード: サードパーティとは

2017-10-12

Google人生破壊された

煽りタイトルだけど偽らざる本心なので。


何があったか一言でまとめると、

無関係他人炎上に巻き込まれ誹謗中傷された挙句、元ページを削除しても永遠にGoogle検索結果から消えない」

ということがありました。

最悪です。

Googleは全く対応してくれる気なさそうなので、万に一つでも増田話題になってくれれば何か違うかもしれないと思って書いてます

あと単純にWEBに詳しいはてな村の人たちの知恵を貸してほしい、マジで…。






経緯

1)無関係他人炎上に巻き込まれ

 同じ職場の似たような名前の別人(仮にはてな太郎とする)が悪事を働く

  →これってはてな次郎(これも仮名だけど俺の本名と思って読んで)じゃね?という感じで、俺が犯人ということにされる

  →誹謗中傷され、個人情報をあさられる

2)スレッド過去ログ倉庫に行くのを待つ(変に燃料追加したくなかったので)

3)無事過去ログ倉庫に送られたが、「はてな次郎」の検索結果にスレッドがヒットしてしま

 スレッドタイトルはこれも仮で悪いけど

 「一部上場企業連続レイプ犯がまぎれていた件www

 みたいな感じのゲスものだと思ってください。

4)弁護士に依頼して、該当スレッドから俺の本名はてな次郎)を削除してもらう

 この時点でかなり高額な費用がかかり、俺涙目

5)Googleキャッシュスニペットを削除する

 キャッシュキャッシュスニペット検索したとき

 ページタイトルの下に出てくる数行の説明みたいなやつです

 ※※ここ重要なところ※※

6)まだページタイトルだけは検索結果に出るが、しばらく待てば消えるだろうと思って放置

7)一年待つ

8)……消えねえええええええ(しか検索結果に1p目に表示される…)


何が困るって、該当スレッドからは「はてな次郎」っていう本名こそ消えてるんだけど、

知人が読んだら「これってはてな次郎じゃん」ってわかる内容なんだよね


特定されたくないからぼかすけど、

「このレイプ犯ってやつ、企画課の一番背高いやつじゃね?」みたいな感じで

想像してみ?自分本名ぐぐると1p目に

 「一部上場企業連続レイプ犯がまぎれていた件www」って出てくることを…

つらすぎ…


原因はおそらく、該当スレッドが、

Googleクローラーにとってめちゃくちゃ優先度が低いため、

何年待ってもクロールされず、インデックス更新が行われないこと。


平たく言うと、クローラーってロボットがいろんなページをくまなく探して、

そのページにどんな情報があるかをGoogleに報告して、

それを「インデックス」って読んで、検索結果に出るようにしてるっぽいんだけど、

クローラー全然来ないから、

「このページには はてな次郎 って情報がある」って誤ったインデックスが、

一年経っても更新されていない。

(か、そもそもGoogleインデックス更新システムバグってる)


から今俺にできるのは

該当ページがクロールされる可能性を少しでもあげること……。

2ch側に

「このページがクロールされるよう

ウェブマスターツールってのを使って対応してくれ」

って頼むことも考えたけど弁護士に「明らかに無理」って言われた)


以下、試してみたこと。

※※状況が複雑なのと、

まさかGoogle検索がそんなバカなはずがない」という正常化バイアスがあるせいで、

以下のようなアドバイスめっちゃしてもらうんだけど、

どれも効果なかったので一読してみてほしい


・ページ内に本名が実は残っていないか検索したら?ソースコード

 →CTRL+Fでくまなく探したけど残っていない

・どっかのページからはてな次郎」ってリンク張られてるんじゃないの?

 →そういう場合は「リンク貼られてます」って表示が出るらしいけどない

キャッシュスニペットを消すならここから消せるよ!

https://www.google.com/webmasters/tools/removals

 →キャッシュスニペットはもう消えてる。もう消えてる(二度目)

検索結果の一番下に出てくる「フィードバック送信から

検索結果おかしいよ!って送ればいいよ

 →何十回と試したけど効果なし

クロール巡回を促進できるページがあるよ!

https://www.google.com/webmasters/tools/submit-url

 →何十回と試したけど効果なし

  ていうかこのページがまともに機能してくれれば全部解決じゃんかよなんとかしろGoogle

Google名誉棄損だから消してくれっていいよ ここからできるよ

https://support.google.com/legal/contact/lr_legalother?product=websearch&uraw=

 →ここに最後の望みを託して依頼したんだけど、

  結果からいうとマジで不誠実な対応しかしてもらえませんでした。

  どれくらい不誠実かというと返信が全部コピペの上に、会話が噛み合わないの。

  あまりにもひどいから以下引用


俺、Google検索結果からの削除をお願いする

返信(長いので一部抜粋

このサイトに対して法的措置を講じられ、結果として問題の素材が削除された場合

その変更が Google検索結果に反映されるのはサイトの次回クロール後です。

ウェブマスターによる変更後、早急にキャッシュの削除をご希望場合は、

ウェブページ削除リクエスト ツールhttp://www.google.co.jp/webmasters/tools/removalsから

リクエスト送信していただきますようお願いいたします。

俺、「だからそれはもうやってるって。

それでもクロールされてないっぽいから依頼してるんだって

クロールしてくれ」

返信(一部抜粋

懸念はお察しいたしますが、Google では、

検索アルゴリズムを手動で上書きして、

対象URL がご指摘のキーワード検索結果に表示されないようにすることはありません。

Google では、ご要望のあったような形で特定キーワードに対する検索結果を変更することはしない方針です。

名前検索したときに表示されるサイトは、検索キーワードの中の単語の組み合わせ、

文書の内容、その他の数多くの要素に基づき、Google検索アルゴリズムによって関連性のある結果として選定されたものです。

ときには、検索キーワードとの関連性が最も高い結果であっても、検索キーワード内の単語のものを含まないこともあります

俺、「検索結果を恣意的に変更してくれって言ってるんじゃない、

該当ページをクロールしてくれ…頼むから…」

返信(一部抜粋

検索結果の情報サードパーティウェブページにはもう表示されていない場合は、

Googleキャッシュが徐々に更新され、最新のコンテンツ検索結果に反映されるようになります

俺 「だから一年待っても反映されないんだって!!!


という流れです。


いや言いたいことはわかるよ!?俺も社会人から

いちいちひとりひとりのユーザー要望に応えて

検索結果をいじったりできないっていうのはわかるよ!


でもさ!アフィブログとかのコピーサイト

サジェスト汚染とかはあっさり対応してもらえてるじゃん!

検索すればいくらでも例が出てくる)


アフィブログとかのコピーサイト問題よりも

俺の人生って軽いですか!?

上のメッセージでは省いているけど、

必要であれば顔写真付き身分証明書などの書類も提出できます

ってお願いしたんだよ!?!?!?


おそらく、

一年だと短いのでは、あともうちょっとだけ待てば?」

という反応があると思うんだけど、

Google検索フォーラムというところで過去事例を探したところ、

同じような苦しみ方をしている人がたくさんおり、

三年以上待っても消えないという人もいました


一例

https://productforums.google.com/forum/#!topic/websearch-ja/jR3-1mfWciA;context-place=starred

https://productforums.google.com/forum/#!topic/websearch-ja/42c3-xqvgn4;context-place=starred

https://productforums.google.com/forum/#!topic/webmaster-ja/Q5qv_7d8skw;context-place=starred

もっといっぱいある(マジで無数にある)けど

わかりやすいのだけ…


これだけ定期的に同じような苦しみ方をしている人間がいるので

Google問題を把握していないわけがないと思うのですが

なんら!一切の!対策はなし!!!!!!

俺の人生なんだと思ってんの!?ゴミだと!?


上記フォーラムで一番参考になったのはこれ↓

https://productforums.google.com/forum/#!topic/websearch-ja/ORA9iVvsa2g;context-place=starred

> 「2010年7月なので、既に3年以上経過してい」ようと、そのクソ中のクソサイト/ページがグーグル検索システムにとって1/9999京の価値もなければ、10年でも50年でも、1度も再クロールされず、したがってその不都合文言検索に出続けるでしょう — いま現在まさにそうであるように。


とのことです。

10年後も50年後もわけのわからない汚名を着続けるわけですね ははっワロス


以上のような流れでマジで死にたいくらい絶望してたんだけど、

人力検索はてなでは思ってた百倍くらい親身になって考えてくれてマジで感謝だった

お前らがいなかったらやばかった、本当ありがとう

http://q.hatena.ne.jp/1507301385

口調全然違うけど俺だ


以上が事の顛末になります

2chには何も期待してなかったけど、

まさかGoogleっていうちゃんとした大企業

こんなクソみたいな対応してくれないとは思わず

マジで絶望していました


願わくば少しでもこの増田がたくさんの人の目に触れて、

はてな村にいるスーパーハカーが知恵を授けてくれますように…

もしくはGoogle社員の目に届いてGoogle社員が猛省してくれますように


から頼む!!!!!みんなブクマしてくれ!!!!!!ください!!!!!!お願い!!!!!!!!



以下余談

・厳密にいうと、ページの中にはてな次郎の「はてな」だけは残ってるんだけど、

それって、「はてなって食べると美味しいの?」みたいな、俺の名前とは無関係文脈で、

一般名詞として使われているので、たぶん関係ないと思う…

そんな珍しい苗字じゃないしそこだけで検索1p目にヒットするのはおかしいと思う…

・たとえば、「富山 観光」って検索して、

富山温泉」のページがヒットするみたいな、

ページの中に「観光」っていう言葉はないけど当然連想されるよね~みたいなことだったら

まだ諦めもつくんだけど、そういうんじゃない

全然有名人じゃないし示唆されるような情報もない

っていうか俺の名前検索して俺本人(いや俺は犯人じゃないんだけど)がヒットするのそのページだけだし

だんだんGoogleそんな悪くないのかも?俺の被害妄想かも?」って気もしてきた

でも今マジでへこんでるのでブコメあんまり厳しく言われたら悲しすぎるのでそういう場合はやんわり注意してください…

でも俺かわいそうじゃない…?

※※追記

みんな本当にありがとう

林さんに迷惑という意見を見たのでひとまず名前だけ変更しま

2017-10-10

anond:20171009111135

昔はフラッシュライト代わりに使うのですら標準じゃできなかったかアプリを入れる必要があったし、

リマインダーも存在してなかった(だからtodoアプリサードパーティのものしかなかった)。

今は逆に「一通り全てのことが標準でできるようになった」と言うこともできるんだよな。

# 確かにgoogle浸食されてる感はすごい。

# ほとんどapple標準をリプレイスして上回る出来。

# apple独自地図サービスとか鳴かず飛ばずだし。

標準では実現できなくて、webサービスでないもの

というのはよくよく考えたらもう殆ど存在しないということかな。

RSSリーダーくらい?

2017-08-14

web系の専門用語多すぎ問題

門外漢からするとこんな風に聞こえてる。(所々適当に書いてるし書いてる内容は嘘デタラメ

「gulpでbowerしてsassgruntビルドすれば、cssストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWS連携させてWebGLTensorflowやらchainerやらと組み合わせればブラウザDQNとかA3CとかDCGANも動かせるスクリプトリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsカスタマイズしたりタスクランナープロセスマネージメントできるからもはやjstensorflowを含めたpythonラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinマインングをサポートしていてブラウザ上でウォレットからマイニングセットアップまでできるんだってブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータ分散してサーバーに保存できるみたいなこともあるんだって。」

どうしてweb系は専門用語肥大化するんだ。

2017-06-15

https://anond.hatelabo.jp/20170615160932

PERにしてほぼ100倍、値嵩株でこんなPER銘柄は他に無い。

海外なら山ほどある。

任天堂投資家海外中心である

この時点で論理破綻をしている。

2017年3月期はシアトルマリナーズを売却した利益で辛うじて決算を維持していた会社だ。

本質的にはPERは100倍よりずっと高いのだ。ってそれはスイッチ発売前の問題である

「主力商品であるNintendo Switch北米を中心に失速気味」のソースがない。

もしかして月販だろうか?

現状再生産分は船の上である生産中国からアメリカまでは輸送に通常一ヶ月はかかる。

少数は航空便で運んでいたようだが

四末の入荷以降は六月で予約を取っていたのを知らないのだろうか。

アホである

なにしろ最大のサードパーティIPであるドラクエモンハンが両方ともPS4に行ってしまったのだから

ドラクエスイッチでも発売されるしそもそもモンハンスピンオフである

そもそもモンハン携帯機で遊ぶものでありPS4で発売された据え置きは売れていないということを知らないのだろう。

頭は大丈夫なのだろうか?

店頭行列など任天堂にとってマイナスしかないのだ。

そもそも任天堂株価規定する一つに無駄がない。

利益率が高いというのがある。工場を自社でもってないのもそのひとつ

シャープなどが工場閉鎖で赤字しまくってたのを知らないのだろうか。

ただの世間知らずである

まだ色々書きたいが要するに結論は「任天堂PER50倍未満の適正値に戻るにはかなりのショックが起きそうだよね」ということだ。

そもそも今期の増産予測のままでいくと普通にPERは50倍程度になる

ショックも糞もない。ショックなのは現実が見えてない売り豚やってしまって大損こいてる君なのではないだろうか?

哀しいことだ。

そもそも任天堂価値IPとその豊富ネットキャッシュにある。

ネットキャッシュって知ってる? ビットコインじゃないよ?

っていうか十年前の相場忘れたの?

公的資金でこんな会社の株を買うのはどうかしてると思っている。

どこが買ってるのか。見えない敵と戦っているのだろうか。

結論

株に負けるとこのような妄想を書き散らかすことになる。

ちなみにわたしは今1500万の含み益が出ている。

2000万を超えたら利確するつもりだ。

任天堂ショックが来る

今日任天堂株価が上がった。

PERにしてほぼ100倍、値嵩株でこんなPER銘柄は他に無い。

E3ポケモンSwitch版の開発を発表したことなどを好感している、ということだが、正直こんな株は辞めた方が良いんじゃないのか。

2017年3月期はシアトルマリナーズを売却した利益で辛うじて決算を維持していた会社だ。本質的にはPER100倍よりずっと高いのだ。

主力商品であるNintendo Switch北米を中心に失速気味で、今期に出ないポケモン期待でこのハードが浮上するのは無理がある。

さらSwitchポケモン等の各IPを出すと3DS利益を圧迫するので、Switchが伸びればいいという話ではないのだ。

任天堂が開発費を保障しない形での新作をSwitch提供する大手サードパーティはいない、という事もE3で明るみに出た。

なにしろ最大のサードパーティIPであるドラクエモンハンが両方ともPS4に行ってしまったのだから。(ドラクエPS4版の方が3DS版より予約が好調である)

ソシャゲ成功例として認識されていたファイアーエムブレムヒーローズはもはやトップ10から陥落してしまった。

次に出した「はねろ コイキング」などのゲーム名前すら知らない人の方が多いだろう。今期はソシャゲ事業で一気に伸びる期待はできないのだ。

ゼルダなどの売り上げが前期に計上されてしまっている点も少なからず影響がある。

ネットワークサービス有料化を延期したのも、値段が安いのも影響がある。

店頭では未だに抽選が行われるほどの人気」などと言われるが、製造工程問題があるようなハードプラットフォーマーになることな不可能で、

任天堂は今期の目標であるNintendo Switchの出荷1000万台を達成できない見込みが強いというだけの話になる。

店頭行列など任天堂にとってマイナスしかないのだ。

まだ色々書きたいが要するに結論は「任天堂PER50倍未満の適正値に戻るにはかなりのショックが起きそうだよね」ということだ。

公的資金でこんな会社の株を買うのはどうかしてると思っている。

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2017-01-20

俺がNintendo Switchを購入する理由

現在の愛機はVita

自分プレイしてきたのは主にPS3と縦マルチゲーム

多少の劣化我慢できる…と思っていたが、PS4世代になるとそれも限界

そもそも移植すらされなくなってきた。

それなら据置機を買えばよくね?という話になるが、

俺はテレビを持っておらず、またゲームのためだけに買うつもりもないのだ。

から携帯機がファーストチョイスになる。

こういう人は俺だけではないと思う。

Switchはまさにドンピシャだ。

任天堂は据置機であることを強調しているが、やはりハイエンド携帯機としての魅力を感じる。

外に持ち出すつもりはないので大きな画面は歓迎だし、バッテリー許容範囲内だ。

ローンチタイトル移植ばかりだったのに不満の声が多いようだが、

移植を望んでいる側としてはそこはむしろ好感が持てるところだ。

不安要素と言えば、WiiWiiUのようにサードパーティギミックを嫌うことだが、

SwitchWiiほどギミック強要していない印象も受ける。

スペック的にはおそらくPS4・XboxOneに対する縦マルチ的な扱いになると思うが、

どうか展開先のひとつとして定着することを願っている。

もうひとつTVにつなぐつもりがないユーザーのために、

ドック抜きのパッケージ販売してくれないかとも思うが、まあこれは単なる要望だ。

俺は任天堂謹製ゲームにはあまり興味がない。

とにかくマルチだ。よろしく頼む。

あとVitaの後継機も待ってます

3月3日までに発表してくれれば踏みとどまるかもしれないよ…。

2017-01-10

それではこれより、株式会社時間の第138億5472万1241期株主総会を開始します。

ご存知の通り、弊社は宇宙の始まりとほぼ同時期という早いタイミング業界に参入し、絶対的尺度を持たない暗黒の宇宙に「時間」という画期的ソリューション提供してきました。現在に至るまで業界におけるシェアは「空間」「熱」といった後発の競合プロダクトを大きく引き離し、圧倒的No.1の座を守り続けています

また、第7期に弊社社内ベンチャー制度から独立子会社化した株式会社存在」とともに強みを生かしたシナジーを発揮し、あらゆる事象の生起を可能とするプラットフォーム運動」をBtoB,BtoC問わずあらゆるステークホルダー提供してきました。その結果「生命」「知性」といったサードパーティ概念も空前の大ヒットを記録しております

今後も企業理念である「すべてを」を体現し、すべてを提供してまいります

質疑応答の前によく聞かれる質問ですが、「時間とは何か」については企業秘密とさせていただいております

2017-01-09

最高の無料メールクライアント2017

GmailOutlookのようなウェブメールサービスを利用すれば、すべてのデバイス簡単メールアクセスモバイルアプリ提供できますが、それらのメールサービスあなたデスクトップでの動作保証するでしょうか? 

今は、多くの人が複数メールアカウントを持っている。これらのアカウントが異なるプロバイダ使用している場合は、一度に複数ブラウザタブを開く必要があります

便利な場所にすべてのメッセージを集約するだけでなく、優れた電子メールクライアントは、暗号化カレンダーRSSフィードVoIPアプリケーションとの統合などの機能を追加できます

デスクトップクライアントメールローカルに保存することもできるため、オフラインときアーカイブされたメッセージアクセスしたり、貴重なバックアップ提供することができます

eMクライアント

さまざまな電子メールプロバイダ統合されたチャットサポートする最高の電子メールクライアント

eM Client10年近く前から始まっています。その長い開発により、Windows用の最高の電子メールクライアントに発展することができたんや。

無料版は非営利目的使用と2つの電子メールアカウント限定されますが、それ以外の場合は有料版とおんなじ。

eM Clientには、GmailExchangeiCloudおよびOutlook.comタッチコントロール、高速検索統合カレンダーおよび連絡先のサポートが含まれてん。JabberGoogle Chatなどの一般的な標準をサポートする統合されたチャットアプリもあり、Outlookのような重量のあるアプリには良い選択肢ですわ。

Mailbird Lite

あなたメッセージを補う機能が満載されたすばらしいメールクライアント

Mailbird Liteは単なる電子メールアプリではなく、スケジューリングチャットファイル同期、チームワークのためのアプリケーションを追加できるコミュニケーションプラットフォーム全体です。

Mailbirdをダウンロードした後は、Proバージョンの30日間試用版に対処されます。このバージョンは、月末にアップグレードしないことを選択した場合限定Light Editionにダウングレードされますフリークライアントには時間制限はありません。

無料ユーザーは、速読電子メールスヌーズ添付ファイルのクイックプレビューなどの機能を忘れていますが、Mailbird Liteは依然として優れた選択肢です。最大3つの電子メールアカウントサポートし、スピードに合わせて最適化され、起動時に最適です。

セットアップ簡単です。電子メールの詳細を入力すると、Mailbird Lite必要POPまたはIMAPの設定を自動的に見つけ、メッセージインポートを開始します。あなたFacebookアカウント接続することができるので、あなたの連絡先のプロフィール写真あなたの受信トレイ活性化し、WhatsappGoogleカレンダー無料タスクマネージャMoo.do、teamworking app Asanaにリンクすることもできます

Claws Mail

Claws Mailのシンプルインターフェースは、より自信を持ったユーザーに適した強力な電子メールツールです

Claws Mailは使いにくくはありませんが、独自メールフィルタリングに耐え、無制限電子メールアカウントサポートしたい経験豊富ユーザーに最適です。

ここの他のクライアントとは異なり、ClawsはユーザーPOP3 / IMAP設定を手動で設定する必要がありますGmail使用している場合は、Googleアカウントの設定を調整して、安全性の低いアプリケーションアクセス許可する必要があります

古くは現代電子メールクライアントでは、HTMLメッセージ送信するオプションはありません.Clawはプレーンテキストのみですが、不要機能を省略することで、Clawは驚異的なスピード動作します。その検索機能特に優れており、プラグイン経由でも拡張できます

それは最も美しい電子メールアプリケーションではありませんが、Clawsはあなたスタイルを超えて物質評価するならば、素晴らしい自由選択です。定期的に更新されているため、バグはすぐに除かれます

Inky

すべてのデバイスメール管理するためのワンタイム設定の無料メールクライアント

Inkyの無料版はWindowsMac OS X、およびAndroidで利用でき、ワンタイム設定は3つのプラットフォームすべてで使用するのに最適なメールクライアントになります! 

電子メールクライアントダウンロードしてインストールしたら、Inkyアカウント作成するよう求められます。これにより、すべての電子メールアドレスリンクされ、POPおよびIMAP設定を設定することなく、Inkyがインストールされた任意デバイスからアクセスできるんです! 

一度登録すればセットアップ簡単カンタン♪ 各アカウントユーザー名とパスワード入力すると、残りの部分をInkyが処理してくれちゃう

日常的に使用されるInkyは優れた自動タグ機能メッセージタイプ個人定期購読ソーシャルノートなど)のインテリジェントなフィルタリングデバイス間の非常に高速な検索クラウド同期でわんだふるん♪。

Windows 7以降を使用していて、特定メッセージスレッドを見つけようと多くの時間を費やしている場合、Inkyは膨大な時間節約できちゃうの!

Opera Mail

優れたOperaウェブブラウザの背後にあるチームからの柔軟なオープンソース電子メールクライアント

Opera開発者は、電子メールを常に優れたブラウザ重要機能とみなし、無料電子メールクライアントであるOpera Mailの開発に多大な努力を払ってきました。

その機能には、メッセージテンプレート特に業務用に便利)、メッセージフィルタリングソートタイプ別メッセージソート、さまざまなカスタマイズオプションがあります

クライアントRSSフィードインポートするので、Feedlyや欠けているGoogleリーダーなどのWebアプリケーションの代わりになります

Thunderbird

Mozillaから期待されるように、たくさんの機能があり、無料拡張機能を利用することもできます

Firefoxと同様に、無料電子メールクライアントThunderbirdMozilla Foundationによって作成されました(しかし、2つの開発はそれ以来分離されています)。 ウェブブラウザと同様に、その機能は、サードパーティアドオンの膨大な範囲拡張され、強化されます

優れたビルトイン機能には、電子メールには大きすぎるファイルと、電子メールと一緒にRSSニュースフィードを読む機能があります

セットアップ簡単です。 ほとんどの現代電子メールクライアントと同じように、必要なのはあなたユーザー名とパスワードだけで、Thunderbirdは残りのものを処理します。

Windows Liveメール

長い時を経てもまだ選択肢に残る老舗の電子メールクライアント

Windows Live Mailは、Windows 8および10のMailアプリケーションに取って代わられた2012年最後更新されました。ただし、Live Mailの比較昔ながらの外観にもかかわらず、2つのプログラムはほぼ同じです。

Windows Live Mailは、私たちを含む多くの電子メールユーザーがより現代的ですが、最小限のデザインを好む3ペインレイアウト提供します。 RSSクラウドベース電子メールPOP3サポートし、添付ファイル送信したり、複数アカウント作業したりすることが容易になります

マイクロソフトのやり方が気に入っても、ウルトラスリムWindows 10アプリケーションがあまりにも制限されているのを見つけたら、従来のWindows Live Mailは賢明選択肢です。

 

 *

 

http://www.techradar.com/news/the-best-free-email-client

2016-12-13

よく開発中などにありがちな情報リークって

リークって言葉情報垂れ流してる人がいるけど、ああいう人たちが当たり前のように増えてるのってどうなんでしょうね。

今日ニンテンドースイッチソフトを開発してる人がスイッチの性能をリークなんて記事を見かけたけど

リークすることが当たり前のようになってる時代って、おかしいと思わないのかなと思うのです。

昔なら雑誌取材で判明させるくらいに小出小出しで情報が出ていて、更新が楽しみと期待に胸をふくらませたものだったけど

今は公式必要以上の情報提供してないというのに、サードパーティが口軽く勝手にあれこれ吐いちゃってるってのは問題じゃないかと思うんですよ。

こういう変に情報を垂れ流す人のおかげで期待どころか失望勝手に抱いてネガティブに叩く人が増えてしまう気がしまして、

いい加減、本人たちを無視して勝手情報を漏らすのはやめたらどうかなと。

新しい情報に敏感で気になってしまって仕方ない人も多いとは思いますが、

その情報公式に出してもらえばいいだけであって、サードパーティ勝手許可もなく出すもんじゃないと

思うんですが、今はそういう考えこおかし時代なのでしょうかね・・・

2016-11-17

ルフランのおかげでvitaが多少なりとも売れただろうからうれしい

コレに限らずソニーはちゃんとサードパーティ感謝したほうがいい

2016-10-28

新しいMacBookPro、コネクタUSB-Cだけだ・・・

全面的に良いと思ったらこれだよ

そして純正変換アダプタがくっっっっそ高い

 

選択肢は3つだ

1.くっそ高い純正変換アダプタを買い漁る

2.サードパーティ製変換アダプタの接触の悪さに日夜悩まされる

3.新しいMacBookProを買わない

 

・・・3かな

2016-10-23

Nintendo Switchの狙い

http://n-styles.com/main/archives/2016/10/22-060000.php

任天堂おじさんの記事おもしろかったので自分も考えてみた。

仮想敵PSでもVRでもなくスマートフォン

現在もっとシェアを獲得しているゲームハード言わずもがなスマートフォンである

DSWii期に新規ユーザー獲得を狙い一般層向けのカジュアルゲーム一時的成功したが、その客はスマホの普及でスマホ向けゲームアプリにごっそり取られてしまった。Switchではこの客を取り戻そうとしているのではないだろうか。

任天堂据置型ゲーム機デザインゲームキューブまではいかにも玩具然りとしたデザインだったが、Wiiから一般層・ファミリー向けであるというコンセプトからリビング邪魔にならないデザインを目指していた。そしてSwitchは持ち歩くのに抵抗のない、それこそスマホのようなデザインだ。これは個人的感覚だが、電車の中でスマホで遊ぶのに抵抗はないのに3DSを開くのはなぜか少し抵抗がある。3DSいかにもゲーム機っぽいデザインからかもしれない。そんな心理的な抵抗をデザインから解消しようとしているように思える。またスマホゲーは入力装置タッチパネルオンリーという性質上、操作性に不満があったがJoy-conがそれを解消してくれる。なにより手のひらの中でスカイリムスプラトゥーンを遊べるようになるのは世界的に訴求力がでかい

サードパーティ活性化

任天堂おじさんも触れているがSwitchWiiリモコンヌンチャクWii Uゲームパッド操作対応していないように見える。というか現時点では新たな入力装置操作体系による新鮮なゲーム体験を売りにしていない。

Wii系ではハード開発段階でもろもろ研究済みの任天堂に対して、既存技術知識通用せずいちから研究コストをかけねばならないサードパーティスタートダッシュで出遅れることになった。結果任天堂ソフトけが存在感を示し、サードがほぼ息をしていないラインナップ不足なハードという印象が足を引っ張る形となった。

そこで今回は飛び道具的な新たな体験を切り捨て、デベロッパーフレンドリー環境を用意する事でサードパーティの良質なコンテンツをより多く呼び込もうとしているように思える。UnityUnrealエンジンへの対応もその一環で、それはインディーデベロッパーにも開かれた門戸となる。

弱点

現時点ではリモコン等で示した新たなゲーム体験を切り捨てたように思えるが、それではスマホとの差別化を図れないうえにスマホ新機種発売ペースが速い為、いずれ早い段階でスペックで追い抜かれる可能性がある。Joy-conのアタッチメント方式仕様を見るに実は拡張性が高く後付けで新たな価値提供する用意があるのかもしれないが、カジュアルゲームのお株がスマホに奪われたようにその価値すらパクられる可能性もある。任天堂自身スマホアプリ提供しているので共存する方向で考えているとは思うが、はたしてそれがどんな形のものなのか今はまだ想像できない。

とにかく今は早くゼルダで遊びたい

2016-08-09

golang半年近く使ってみて

後なんかweb系の企業golang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線

今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか!

どっちもユーザーです!(ペアーズでは3名ぐらい逢った、メルカリではバイクMacbook Air売ったなー。)

ポケモンGoとかやんねーし、地味に自分がよく使っているアプリサービスから成功パターンを得るのがいいのかなぁ

なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが(CtoCなんだから当たり前か、何いってんだ)

人とコンバージョンしたいです。

2016-05-12

http://anond.hatelabo.jp/20160511210127

はてなゲーマー様や自称ゲーム市場事情通の皆さんってこういう木を見て森を見ない議論好きだよね。


海外サードパーティがきちんと自分たちゲーマーじゃないユーザーCS機に呼び込んで囲い込み、

その囲い込んだ非ゲーマーゲーマー調教する仕組みを整えてる。

から市場が拡大するし、拡大した市場ニッチゲームからAAAタイトルまでの売れる絶対数が増える。

自分たちできちんと自分たち商売の土壌をメンテナンスしてる。


じゃあ、国内はどうだろう?ゲーマーではないユーザーを囲い込むために非ゲーマーゲーム会社が目を向けると

自称優良顧客様がヒステリー起こしてわめき散らさないか

「こんな企業は終わりだ(俺を大事にしない企業など終わって欲しい)」だの、

ゲーマー大事にしないか日本市場は駄目なんだ(俺を大事しろ)」だの、

自分だけを見てないとヒステリー起こしてわめき散らすゴミカス巣窟だろ?

海外だってそういうゴミカスはそれなりの数居るんだけど、ゲーム会社そいつらの奴隷にはなってない。


なぜ日本だけそれが問題になって、海外ではそうならないのかの根本の原因は少子化

一番時間価値が低くて大量に浪費可能子供絶対数が減ってるんだからゲーム専用機市場新規ユーザーは減る。

ゲームだけで育ってきてゲームに嫌われたら人生終わりな老害も年をとるごとにゲームばかりやってられなくなって

自然減少してはいるんだけど、それ以上に少子化新規ユーザー絶対数が減ってるから老害割合はむしろ増えてしまってる。

から割合の増えた老害ヒステリー国内メインで活動するゲーム会社無視しづらい。今の日本の政治状況と同じだね。

ゲーム会社だけではどうにもならない問題だけど、ゲーム会社とその客がお互い足引っ張り合って

全員が不幸になる道をたどってるのが国内ゲーム専用機市場の唯一にして最大の問題

そこを何とかしないとどうにもならんよ。

タイトルの売り上げ比率という上っ面の問題だけ切り取って嘆いても何も変わらん。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」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 サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイル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

http://no-oauth.insanecoding.org/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、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 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ 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 のような場合は期限切れがあってはならないので、パスワード等を預かる

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

上記の問題点は、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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の 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 がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

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

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-03-13

大手家電メーカーは、もうコタツ作ってないのね

炬燵のヒーター部分が壊れた。メーカー保証はとっくの昔に切れてる年数。

なのでヒーター部分だけ交換しようと思ったが、その前にコタツ丸ごと新品だと値段どのくらいなんだろ?

と試しに調べてみたら

http://kakaku.com/kaden/kotatsu/

並んでるのは「YAMAZEN」とか「コイズミ」とか「東谷」とか馴染みのないメーカーばかり。

大手家電メーカーは揃ってコタツから撤退してたのね。知らんかった。

厳密に言えばパナソニック住宅設備扱いの掘りごたつは作ってるけど。

因みにウチのコタツナショナル

石油ファンヒーターから大手家電メーカーが一斉に撤退したのは、ナショナルFFストーブでの死亡事故を受け

購入顧客を把握できない、定期点検義務付けられてない、なのに永久安全保証しろ、ではやってられん

でそうなったのは知ってたけど、コタツ業界もこんなことになってたとは。

まあ考えてみれば日本しか売れないガラパゴス商品だし(イランには「コルシ(Korsi)」と呼ばれる同様な暖房器具

あるそうだが←wikipediaで知った)、電化製品としての機能はこれ以上あまり発展なさそうで差異化が難しいし

いざヒーター部分が壊れたにしても、ヒーター部分の交換だけで済ませちゃって買い替え需要もあまり望めないから

撤退も宜なるかなって感じだわ。

ヒーター部分を探す。こちらもなかなか寡占化が進んでる。「こたつユニット」と呼ぶのか。

http://www.amazon.co.jp/b/ref=amb_link_69775869_35?ie=UTF8&node=85240051&pf_rd_i=3895761=289254069

山善 (YAMAZEN) はメトロ電気工業からOEMらしい。

すぐ使いたいと家人から要望があったので家電量販店にてメトロ電気工業の品を購入。

こたつユニットの取り付けネジの位置コタツの机部分のネジの位置が異なるのでボルトオンとはいかず。

市販金属ステーを介して取り付け。

昔は取り付けネジの位置をあえて各社変えることで交換用こたつユニットサードパーティ排除してたのか知らんが

こたつ及び補給部品供給から撤退するなら、残存メーカーボルトオン取り付けできる製品生産を依頼するとか

変換キット用意するとかしてほしいと思った。

2016-02-06

Twitterの表示が変わる?

Twitterの表示が来週から変わるらしい。日本Twitter文化は割と全ツイート読みな気がする。一部ユーザーテスト的に新しい仕様にしてるみたいだけど評判はイマイチSNSに割く時間が減っている?なんて思ったが前述したように全ツイート読む日本人には不向きすぎる。今や多くの企業Twitter情報を発信している。フィード配信より速いかつ、個人的には見やすいため重宝している。これからは「リスト」で管理しなければいけない時代がやってきそう。そもそもサードパーティアプリも潰れてしまうのか?パターンを選択できるようにできないのか?

来週からの変更がツイ廃たちにどう影響していくのかウォッチ案件

2015-09-19

iOS9の広告ブロック機能の件について

まず、Apple広告ブロックしているのではない。

広告ブロックアプリを作っているのはAppleとは関係のない個人または法人

何の広告ブロックするかしないかの選択基準サードパーティーアプリを作っている個人または法人によって異なる。

Google Analyticsで解析可能にするしないの選択も当然サードパーティアプリ制作側次第と思われる。

どの広告ブロックアプリを選択するかはユーザー次第であり、もちろん広告ブロックアプリを使用しないという選択肢ユーザーにある。

そして、PCブラウザには大昔から広告ブロック機能があった。

今までPCからだと普通に出来ることが、スマホだとなぜかできないことこそが異常事態だった。

しかしながら、今現在も多くのユーザーPCブラウザのABPなどの拡張機能存在も知らないし利用していない。

常に一定数のユーザーけが広告ブロック機能を利用するし、しないユーザー永遠にしない。

現状から考えるとWEB広告マーケティングに何らかの影響が出ることはないだろう。

2015-09-02

FEifは任天堂っぽくない

良くも悪くもセンスサードパーティっぽすぎる

サードパーティっぽいキャラクター世界観(恋愛アダルト要素含む)

サードパーティっぽく食材を組み合わせて料理ができること

サードパーティっぽい武器スキルの種類やネーミングセンス

サードパーティっぽい複雑なシステム(弓が槍に強いとかそういった直感理解できない明らかにゲームのために作られたような法則)

もしあれが中堅どころのサードパーティが新作として出したゲームだったなら…

2015-02-12

LINE Q使ってみました。iOS版です

http://anond.hatelabo.jp/20150211212201

App Storeレビューが極端に低く、最初サードパーティアプリかと疑いました。低評価の大部分は管理質問が消されたなど)やユーザーに対するもので、アプリ品質に関してのものは少ないようです

アプリLINEと同じようにシンプルで良いデザインですが、かなりGoogle+アプリに似ているなと思いました。購読したジャンル(購読情報プロフィールで公開されます)に寄せられた質問タイムライン形式で流れます

んで中身ですが、まあ小中学生ならこんなものかなあと言う印象です。特に酷いとは感じません。小中学生が皆マトモなら少年法なんていりませんしね、色々馬鹿なことをやって成長していくもんです

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん