「ネイティブアプリ」を含む日記 RSS

はてなキーワード: ネイティブアプリとは

2019-11-30

新卒エンジニア就活が終わったので, 21卒ニートのためにまとめる

学歴: TOP5くらいの理系大学BE

経験: 未経験半年web開発実務経験 + 実ポートフォリオ2つ(ネイティブアプリ1, WEBアプリ1) + ハッカソン賞1つ

___

内定

___

会社/分野: アドテク

職種: SWE

場所: 東京

年収(額面): ¥480マソ

___

会社/分野: ゲーム/AI

職種: SWE

場所: 東京

年収(額面): ¥500マソ

___

会社/分野: メディア

職種: SWE

場所: 東京

年収(額面): ¥600マソ

___

会社/分野: 通信

職種: エンジニア(?)

場所: 東京

年収(額面): ¥340マソ

___

落ちたところ

___

会社/分野: AI

職種: SWE

場所: 東京

年収(額面): ¥???

___

会社/分野: EC/Infra

職種: SDE

場所: 東京

年収(額面): ¥???

___

会社/分野: Fintech

職種: SWE

場所: 東京

年収(額面): ¥400~500マソ

___

会社/分野: コミュニケーションアプリ

職種: SWE

場所: 東京

年収(額面): ¥500~700マソ

___

20~30歳くらいの人たち、情報共有しようず☆彡

2019-11-29

anond:20191129135009

フロントやってるが、まあ気持ちは分かる。

とりあえずスマホ対応結構かいかな。10年前にスマホあったけど、普及はこの10年。PCだけ考えていればOKだったのが、スマホも考えるとなると結構キツイところ。(PC横長、スマホ縦長だし)

あとはWebアプリ作る感じだとパフォーマンスの制約(ここにもスマホは絡む)と実現したいことのギャップキツイ普通に常時通信とか当たり前だし、Flash死んだし。

結構普通にネイティブアプリでやってたことがWebでできないとおかしい的な感じもでかいかな。ゲーム界隈とかほんとすごいと思うよ。使ってると気づかないんだけど、気づかせないのがすごい。10年前ならネイティブアプリWeb機能全然違うとか普通だったしね。。。今同じな方が普通だしね。。。そうなると開発規模が増えてFWとかモジュール管理が欲しくなってきて、ただそこも独自ルールを覚える必要もあるし更なる問題も出てくるからそこにも対応せんといかんしね。。。同じように実現できてても「まだNode.jsで消耗してるの?」とかクソヤローもたまに出てきて確かに便利だけど面倒なんじゃ!ってなるし。←ここは主の主張とマッチしてござるなwwwんんwww

いろんなライブラリたちがバージョンアップして、適材適所でやってたつもりが一本化できるんじゃね?できないの?検証しなきゃ・・・とかやらんとならんってのもあるなぁ。

まあなんだ、この10年でWebも変わってはいるんスよ。ただ同時にWeb"系"が隆盛して、マウンティーになっているのも事実かもなーなんて思う。俺なんてjQueryおじさんにもWebイケメンにもバーニーおじさんにもなれないような人間たわごとですけどね・・トホホ

2019-09-24

.net Core3.0はwindowsネイティブアプリケーションもサポート

ワイ「おっ、ええやんけ。さっそくインストールしてみっか」

dotnetコマンド「Running 'dotnet restore' on winformtest/winformtest.csproj...

/usr/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(59,5): error NETSDK1100: Windows デスクトップ アプリケーションを構築するには Windows必要です。」

ワイ「そういうとこだぞ!」

2019-01-23

PWAネイティブアプリに取って代わるって去年の春頃に言ってた奴、

全く取って変われてないけど、どう落とし前つける?

指の一本くらい詰めてみるか?

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算windows10電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

数字大文字文字で約60の時は10桁で20万年と書いているが

現代の解析技術20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

JWT送信セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能識別子)が含まれ

おそらく一般構成仮定で書く

https通信するのでパケットキャプチャによる傍受は不可能と思っていた

(http通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントネイティブアプリ場合

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信セッション(cookie形式?)送信セッションからuser_id取得 

接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

まりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

まりcookieだろうがjwtだろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2018-09-21

ネイティブアプリ開発者

Webに近いけど

正直Webの界隈こわい

あそこは例えるなら紛争地帯

ネイティブ平和日本って感じ

平和ボケしてそのうち絶滅しそうだけど

2018-09-14

Webアプリ検索性と網羅性の悪さ

クラウドWebアプリは嫌いだ。

HTML5宣伝されて、世間クラウドだのと言い始めたが、

iPhoneAndroidネイティブアプリが普及して、Chrome bookが廃れたのを見て、ざまあみろと思った。

社内のアプリケーションが InternetExplorer専用のクソ使いにくいWebアプリになったりして印象が悪かった。

開発元企業が、あたか先進的なテクノロジーのように宣伝しているのを見て死ねと思った。

ところが2018年現在、未だかつてないほど、Webアプリを使う人生を送るようになっている。

やはり Microsoft OfficeWebアプリ化した影響は大きかった。

俺の中で Webアプリもなかなかやる、という認識に変わった。

そうなると、Webアプリ検索性の悪さが気になる。

ストレージGoogle Drive使用するとして、Googleドライブから接続できる範囲Webアプリしか見えてこない。

iPhoneAndroidMacWindowsといった胴元のいるプラットフォームなら、アプリストアが整備されるので、

必要サービスが探しやすいが、Webアプリはとにかく検索性が悪いと思う。

検索性が悪いため、ユーザーが集まらず、サービス簡単に終了したりする。

なんだかんだでネイティブアプリが好きだが、Webアプリも使っていきたい。

この問題が解消されることを願っている。

2018-09-13

つのソースiOSAndroid両方対応

「一つのソースiOSAndroid両方対応」みたいな某フレームワーク

画面はHTMLロジックJSで書くようなやつ。

会社アプリがそれで作っているけど、iPhoneXで動作おかしいともめてる。

から、そんなのやめて普通にネイティブアプリで作っとけって言ったのに。

2018-06-30

anond:20180630230123

そう思うだろ?

そこら辺の問題ネイティブアプリで「広告がない代わりに値段がついているアプリ」と、「広告がある代わりに無料であるアプリ」を比較した際に

圧倒的に後者の方が収益性DL数も高かったこから、やっぱりガラケーおじさん並みの「珍種」でしかないことが市場によって証明されている。

はい一定広告を嫌う人間はいるので、その人間をも食い物にするために「広告オフにするオプション」を有料で提供したりもしている。

まりは、オフにできない広告がある現状がまだ不自由なだけで、アドオン広告を消すための有料オプション基本的広告を出力する全てのプラットフォーム採用されれば解決する問題とも言えるわけだ。

世は増田が思うよりは広告に寛容なんだぜ。

増田だって電車降りて駅から出た途端に無数の広告に囲まれてるやんか。

時間テレビ見たら12広告見てるじゃねえか。

そこで蕁麻疹起こすんか? 起こさんだろ。そういうこっちゃ。

2018-05-26

Webアプリしろネイティブアプリしろアプリケーションを作れるっていうことは要は

自分スキル学習を記録したり加速したりするアプリケーションも作れる」

っていうことなので

別に十年後に力が衰える心配とかはする必要が無いんだと思います

2018-03-22

https://anond.hatelabo.jp/20180321171652

調べたら、本当にPWAネイティブアプリの見分けがつかないって書いてる人がいて、うわぁ……と思ったけど、まあ将来的に改善される可能性はあるんじゃない?

今のPWAオワコンというのには禿同

2018-02-26

ミリオンvsシンデレラ、好敵手が育てた2つのアイマス

さてさて、いきなりタイトルがこれですが、何で書こうかと思えば2月14日配信したミリオンニコ生ミリシタのことは触れてもコンテンツとしてのミリオン5周年に全然触れてないので、5周年前日というこの日にこちらが勝手に振り返ってみましょうかと。本当は副題に「-ミリオンライブ 5周年に寄せて-」と入れるつもりでしたが、入らなかったのでここに記載w

なお、筆者はどちらかといえばデレマス寄りの人間ですので、それを承知の上でお読みください。

モバマス成功からグリマス誕生まで

元よりこの作品、あらゆる意味で「大人の事情」が複雑に絡み合った作品でした。遡ること2011年11月に先んじて「シンデレラガールズ」(モバマス)がリリースされたわけですが、想定の10倍の売上を記録したもんだからバンナムにとってもソーシャルゲームは稼げると確信付けたに違いありません。しかモバマスCygames外注したが故に当然レベニューシェアが何割か取られることになります。そこで本家の開発陣で作った純正アイマスソシャゲを作ることで自社の収益を最大化したいのは言うまでもありません。

一方でモバマスの人気に指を咥えていた会社もいました。モバゲー(DeNA)のライバルであるGREEです。元々他でヒットしたソーシャルゲーム模倣して売上を伸ばしていた同社からすれば、アイマスは喉から手が出る程欲しい作品です。こうした利害の一致からバンナムGREE戦略的業務提携し、GREEアイマスの開発がスタートしました。

ところでこのGREEアイマスは当初男性アイドル物になるはずでしたが、坂上総合プロデューサーによって時期尚早と待ったがかけられ「765プロ新人」という設定に変わりました。また、上層部からモバマスのように100人アイドルを出せとの指示もあったようですが、結局は50人(765AS13人+新規37人)に落ち着きました。グリマスがいわゆるSideMのようなものとして生まれてたらどんな未来だったか想像つきませんよね。

さらバンナムはもう一つの課題を抱えていました。IP(知的財産)を軸としたグループ企業間連携です。今までアイマス音楽CD日本コロムビア販売してますが、これを自社グループ傘下のランティスからも発売すれば当然グループ連結の売上にも寄与します。そんな形でGREEアイマス、即ちミリオンライブ!(以下グリマス)は誕生します。

モバマスの逆襲

ここで寝耳に水だったのはモバマスの開発元であるCygamesモバマスの出演声優陣です。木村取締役(当時)の「サイゲームスとモバマスユーザーズッ友だよ」発言や、一部出演声優から発言からも察するに、グリマスが出れば自分たちはお役御免になってしまうのではないか、そういう危機感があったのです。

奇しくもモバマステーマ曲お願い!シンデレラ」(4月10日)とグリマステーマ曲「Thank you!」(4月24日)はほぼ同時期に発売、しかも「Thank you!」は8thライブの先行抽選販売まで付いていました。極め付けは2014年公開の「THE IDOLM@STER MOVIE 輝きの向こう側へ!」でミリオンアイドル7人が出演すると聴いてアニメ出演まで出し抜かれてしまます。なお2013年当時のモバマスオンラインゲームとしては「艦これ」、二次元アイドル物としては「ラブライブ!」という強力なライバルの奇襲に囲まれてました。つまり前門の艦これラブライブ、後門のミリオンライブ!という状況だったのです。

もっともこれがモバマスが奮起する原動力にもなりました。CINDERELLA MASTERシリーズや年1回の総選挙でボイス付きのアイドルを増やし、新規イベントを次々と増やすことでユーザー繋ぎ止めを図ったのです。単独ライブアニメ化も、いわば自分達で掴んだようなものです。

さらCygamesが水面下で開発していた新作RPGグランブルーファンタジー」も助け舟になりました。2014年秋に開催されたコラボイベントモバマスを梃子にグラブルユーザー数や売上を拡大した契機になり、またアニメ化前にPの熱気を暖めることにも成功しています。つまりこの逆境が無ければ今のシンデレラガールズCygamesもなかったことでしょう。

グリマスに訪れる苦境、そしてミリシタへの道

2015年から始まったアニメ軌道に乗ったシンデレラガールズに対して、ミリオンライブ!は苦境を迎えることになります。初年度から2年目こそ毎月のようにCDリリースされる程勢いは良かったのですが、コアであるゲームアクティブユーザーや売上が漸減していってたのです。それもそのはず、グリマスリリースされた2013年は前年に「iPhone5」が発売し、「パズル&ドラゴンズ」(パスドラ)等のヒットでブラウザソーシャルゲームからネイティブアプリトレンドが移行していました。アイドル物でも「ラブライブ!スクールアイドルフェスティバル」(スクフェス)などアプリを主戦場とするタイトルが中心となり、前時代的なブラウザソーシャルゲームでは太刀打ちできる状況ではなかったのです。でも楽曲ストックは沢山あるのだからリズムゲームを中心にしたアプリに移行すればいいと皆考えるでしょう。

ところがここで思わぬ伏兵が出てきます。そう、シンデレラガールズリズムゲームスターライトステージ」(以下デレステ)です。完成度の高い3Dモデルによるリッチ演出アニメまでの楽曲の少なさを逆手に取ったイベント新曲の導入、まるで玩具箱の人形が飛び出してきたかのようなルーム機能…元よりのシンデレラガールズ達の知名度の高さも手伝って、デレステは瞬く間にスマホ向けリズムゲームトップシェア上り詰め、今や国産ゲームアプリでも年間10位以内の売上を誇ります。想定以上の大型タイトルが出現したため、当初2Dで開発していたというミリオンライブアプリ計画は振り出しに戻されます

そして2017年にようやくリズムゲーム「シアターデイズ」(ミリシタ)をリリースすることになりますデレステを越えるアプリにすべくパートによる歌い分けやフルポゴンによるコミュニケーションパートなど意欲的な技術が導入されるのでした。サービス開始当初は配信楽曲の少なさやイベントスケジュールの遅さなどが響きつまづきましたが、最近になりようやく毎週のセールスランキングで上位に食い込むようになりました。さすがにデレステ程でなくてもリスクヘッジのようにデレステが売上の谷間を作りやすい月の半ばから下旬を補完するくらいにはなったのです。P視点ではグリマスサービス終了の影響か「俺たちがミリオンを支えなくてどうするんだ」と奮起するようになったのではないかとも考えられます

765プロ未来」を摑み取れ!

てな訳で皮肉なことに同じアイマス一家の姉シンデレラと妹ミリオンライバルとして、互いを高め合うべく切磋琢磨しているのです。しかシンデレラミリオンもまだ安穏としていられません。スマホ向けアイドルリズムゲーム元祖スクフェス3DCGを身につけた新アプリとなって逆襲の機会を伺ってますし、今春グリマスサービス終了と引き換えに、完全新作「アイドルマスター シャイニーカラーズ」(シャニマス)が控えています。同じアイマス一家にも新入りの後輩というライバルが生まれるのです。

思えばアイマス歴史逆境を乗り越える歴史でした。大体最初アニメ化サンライズ側の都合で設定や声優まで替えられてしまうような作品でした((ゼノグラシア自体スパロボX-Ω参戦など、むしろ公式積極的に弄ってくれてるのでもう誰も気にしてませんがね))。それでも9.18という混乱を乗り越えてアニメで栄華を極めた765プロ所詮傍流という立場から奮起し、今やアイマスは元より二次元アイドル物有数の稼ぎ頭に進化したシンデレラガールズ、先の9.18で生まれたが故に「忌み子」扱いされたJupiterが新たな事務所、新たな仲間と共に真の栄光を掴んだSideM…みんな苦難を乗り越えて今の栄華があるのです。

ならばミリオンライブ!逆境はまさしく今ではないでしょうか。原典の終了、アニメ化の目処も立たず、シャニマスという後輩が生まれる今だからこそです。ミリシタを拠点に再起を図り、逆境を乗り越えた先にこそミリオンライブ!の真の未来が見えるはずです。だって、「765プロ未来はここにある」んですから

2018-02-04

何故ソシャゲサービス終了するのか?

最近サービス終了したソシャゲと、そのユーザーの反応を見ていて思う所があったので書いてみる。

ソシャゲサービス終了する理由

一言で言うと「会社として続けていくことが難しくなったから」ということになる。

で、9割方はお金問題になる。売上がでなければ当然サービスを維持できないので終了する。

開発チームの人員が確保出来なくなったとか細かい事情は色々考えられるけど、結局どれも根本お金問題だったりする。(お金があれば人は離れないし、確保もできる)

逆に言えば、例えばApp Storeセールスランキングトップ10に居るようなアプリはハッキリ言って突然サービス終了するなんてことはあり得ない。

なんで売れなかったの?

ソシャゲビジネスモデルは大きく分けて2つある。

ソシャゲの売上はざっくり言うとDAUアクティブユーザー数) × ARPUユーザー一人あたりの平均課金額)で求められるので、どちらかを上げれば売上も上がると言える。

DAUモデル

DAUを増やして売上を上げようという算段のモデル。要は薄利多売。

有名所で言えばモンストFGOなどが挙げられる(FGOは一人あたりの課金額もすごそうだけど…

ARPUモデル

ARPUを増やして売上を上げようという算段のモデル。言い方は悪いけど、一部の廃課金者にごっそり貢がせようという形。

有名(と言えるのかよくわからないけど売り上げランキング上位の)例としては戦国炎舞 -KIZNA-など。

ここ数年はアプリの数も増えてソシャゲ市場は完全にレッドオーシャン状態なので、特にユーザー数の獲得が難しいオリジナル新規タイトルはこのモデルに寄りがち。

売れなかったアプリはこのどちらのモデルにも寄せられなかったということになる。

DAUモデル場合はちゃんと万人受けするものを作れていなかったとか、広告宣伝が足りてなかったとか、そもそもターゲティングを読み間違えていたか

ARPUモデル場合は、しっかりとコアユーザーに課金をさせるためのゲームデザインができていなかったということになる。

こんなに人気があるのになんで終了しちゃう!?

それは多分あなたの見えている範囲内だけでの話。

Twitterなんて近しい人間フォローするのでその中で盛り上がっているように見えるのは当たり前。

とりあえず試しに人気アプリFGOとか)と自分のやってるアプリTwitter検索して、ツイートの流速とか比較してみるといいと思う。

極めつけに言うと、ソシャゲの売上はストアランキング見れば大体分かってしまうので、ランキング推移を人気アプリ比較してみるといい。(「アプリ ストアランキング」とかで検索すると推移を見れるサイトが出る)

実際どれくらいになったらヤバいの?

会社の規模とかにもよると思うけど、ざっくりとした感覚で言うと、ストアランキングの「"総合"セールスランキング」で、月に一回(ガチャ更新の日など)くらい「100位以内」(ゆとりを持って見ても200位以内)に上がらないアプリ結構厳しい。

圏外の場合はハッキリ言って論外なので、いつ終了してもおかしくない。

色んな推論が飛び交ったりするけど、ランキングさえ見れば9割方は判断が付くので、変な憶測飛ばしたりする前に、まずはランキングを見て欲しい。

売れないからって打ち切るのはひどい!

これは結構見るけど、売れないから打ち切るのは至極当然の判断

結局金かよ!とか冷たい判断、とか思うのかもしれないけど、そんな感情論ではなく世の中はお金で動いている。

当然アプリを開発するのにもお金がかかっている訳で、開発チームの人件費だったり、サーバー等の運用費だったり、広告費だったりと、恐らく皆が思っている以上のお金がかかっている。(特にネイティブアプリに移行してからは開発費用も期間も大幅に増えている)

そのお金を賄うのは会社経営陣)な訳で、その回収が見込めなければ終了せざるを得ないのは当然。

「開発チームはまだまだ続けたかったはずだ!」なんてのも見るけど、その開発チームの給料を払うのも会社な訳で、極論を言えば売上が出なければ開発チームの人間給料を払うこともできなくなる。

結局売上が無ければ開発チームも満足に開発できる環境は得られないし、最終的には誰も幸せにならない未来しか残らない。

あと、これは個人的意見だけど、ゲームが好きとは言え、売上の上がらないゲームの開発をし続けるのは正直モチベーション的にも厳しい所があるし、

それを何も知らない外部から勝手憶測で「まだやりたかったはずだ」とか言われたり、誰かを悪者にされたりしてもあまり気持ちの良いものではない。

サービス終了を悲しむのはいいけど、変な妄想で周りを攻撃したり、自分勝手エゴ押し付けるのは辞めておいたほうが良い。

そんな事をしてもサービスは復活しないし、作り手も嬉しくはない。

お金払えば復活してくれるの?

サービス終了の判断まで行くという事は既に結構厳しい状況という事なので、現実的には難しい。

例えば仮に有志100人が集まって毎月皆でン十万円課金してくれるとかなら続けられるかもしれないけど、そんな事をしても運営ユーザー疲弊していくだけ。

現状で売上が上がっていないということは、無理をして解決しようとしたって絶対破綻する。

結局誰が悪かったの?

売上を上げられなかった開発チーム(具体的に言えばターゲティングとそれに合わせた課金モデルをうまく作れなかったプロデューサーディレクタープランナーなどの責任が重い)と、

適切な判断ができずにGOサインを出してしまった経営陣が悪い。

サービス終了で悲しまないためにはどうすればいいか

身も蓋もないことを言ってしまえば、サービス終了しそうなゲームプレイしないこと。(ランキング圏外のゲームプレイしないこと)

とは言え、そうやってニッチゲームに誰も課金しなくなって、人気ゲームだけに一極集中してしまうのは少し寂しいものがある。

大人な心をもって、無理のない課金ゲームを楽しんでくれれば作り手としては嬉しい。

お前は誰だ?

ソシャゲ業界に居た人間。いくつかのソシャゲサービス終了を看取ってきた。

ソシャゲに関わるのに疲れて、今はWeb系の会社まったり仕事している。


2018/02/05 追記

なんか結構反響があったので、改めてこの記事で言いたかたことの整理と、いくつか多く見られたコメントへの返信も書いておく。

 言いたかたこ

特に言いたかったのは3つ目で、別にソシャゲの話でなくてもこういう事は多いけど、ちょっとむしゃくしゃしたので書いた。

コメント返信

当たり前の話じゃん

全くもって本当にその通り。こんなことをわざわざ書いた理由としては前述の通りで、まあ単に個人的ストレス発散が目的

増田なんか読んでるような人間は当たり前に思うかもしれないけど、実際当たり前な事を理解してない人間は多い。

お金以外の問題で終了するパターンは?

そのパターン自分も直面したことは無いので知らない。自分ソシャゲ業界全てを知ってる訳じゃないので免責も込めて9割と言ったけど、まあ99%くらいはお金問題帰結すると思う。

拡散性ミリオンアーサー乖離性に移行する以前の問題として「運営の体力が厳しかたから」って事らしいし。

https://app.famitsu.com/20141226_479007/

FGOが高DAUモデル

FGOは割と特殊な例なので今回の例としては相応しくなかったなと思うけど、DAUが多いのは確か。(と言ってもモンストとかツムツムレベルでは無いが)

実態としてはDAU結構多くてARPUも高めって感じだと思うので線引が微妙な所。

個人的にもFateは一部の古参ファンが金をめちゃくちゃ注ぎ込むコンテンツという認識だったので、ここまでユーザーが増えたのには驚いてる。

ちなみに今回はシンプルで分かりやすいようにDAUARPUを挙げたが、売上の指標としては他にPUR(課金ユーザー割合)、ARPPU(課金ユーザー一人辺りの平均課金額)とかもある。

この辺の話は割とよく出てくるので、興味があったら調べてみると良い。

終了後にコンテンツを残してほしい

この声結構多くて、実際最近では終了後にも楽しめるようにコンテンツを残してくれるソシャゲも増えてきている。(ポプストとかあんガルとか)

その取り組み自体は素晴らしい事だと思うけど、実際これをやろうと思うと思った以上に手間が掛かる。それはつまりお金(人件費)が掛かる。

結構簡単にやって欲しいとか言うけど、アプリ簡単オフライン化できることなんてまず無くて、結構根本から作り直さないと難しかったりする。

それにオフライン化してリリースたからと言ってそれで終わりにもできなくて、リリースする以上ある程度はサポートバグ修正などもしなければいけないので、それに対応する運用体制必要になってくる。

設定資料集みたいな物を作るとしてもデータをまとめたり編集作業したりでそれなりに工数が掛かるし、印刷費なども掛かる。

データアーカイブの公開も、主に外注権利関係問題などがあったりして、簡単にすぐ出せるようなものでもない。

から、あまり期待を膨らませられても困るし、サービス終了を検討するような状況の所に身銭を切らせてやらせるのは酷だという事は理解して欲しい。

ソシャゲ業界はいつ潰れる?

これも数年前から言われ続けてるけど、自分は潰れること無く続いていくんじゃないかなと思ってる。

最近任天堂まで参入してきたし、去年はアズールレーンみたいなオリジナルでのメガヒットタイトルが久々に出てきた。

あと、Appleガチャ確率表記義務付けた話も、裏を返せばAppleガチャモデル容認したとも取れる。

今更大規模な法規制が起きる事も考えにくい(誰も得しない)し、仮にソシャゲ規制してもコンシューマに金が流れるとは思わない。

ただ、「日本の」ソシャゲ業界は厳しい状況になってきてるだろうなと思う。

アズールレーンの台頭から既に騒がれつつはあるけど、中国の持つ資金力に加えて、日本でも売れるコンテンツ力が付くと、正直勝ち目は無いんじゃないだろうか。

もうソシャゲ業界でも「金がなくてもワンチャン成り上がれる」みたいな夢のある話は無くなってて、体力(資金力、開発力)のある企業がしっかり丁寧に作らないと勝負にならない。

それができる企業というのはもう本当に少ない。悔しいけど、多分Cygamesくらいしかいかも。

正確に言うなら、ソシャゲビジネス自体は無くなることは無いけど、日本ソシャゲ業界は衰退していくのかもしれない。(あるいは既に衰退し始めている)

2018-01-07

Web系での就活について

はじめに

そろそろ就活シーズンなので、数年前の就職活動の思い出を書くことにしました。

私はネイティブアプリフロントエンドエンジニアとして、Web系と呼ばれる会社選考を受けました。

10社ほどの選考を受け、2社からお祈りされ、4社辞退し、4社から内定を頂きました。

この記事のねらい

色々思い出してきたので、個人的に良かった会社と悪かった会社愚痴を書きます

スケジュール

当時大学院1年生だった私は、10月逆求人系のイベントに2回ほど行き、お互いに「良いな」と口に出し合った企業選考を受け、1月就職活動を終えました。

良かった会社と悪かった会社の違い

結論から言えば、「人事の方がどれだけ学生目線で考えてくださっているか」に尽きます

最初から企業理念事業内容・エンジニア雰囲気については良いと思えた会社のみの選考を受けましたので、結局は人事の方がどのように接してくださったかが肝でした。

良かった会社

お祈りをされてしまいましたが、目黒のL社の人事の方の対応は素晴らしいものでした。

お祈りメールを頂いた後に、「なぜ選考に落ちたのか」を訪ねたところ、たった1日で採用担当者の方に掛け合って頂いた上で詳細な理由をご教示頂いたからです。

悪かった会社

M社

M社については、選考を辞退した際に人事の方から社会人経験の長い私からアドバイスがしたい」とお話を頂いたので、半信半疑ビデオ通話をして頂きました。他の会社に進む理由を1分ほど話せば「それはウチの会社でもできるよね!」と一生懸命覚えたであろう自社のアピールポイント10分ほど立て続けに喋り続ける、ということを繰り返すだけで、話は平行線に終わってしまい、心底疲れました。

P社

P社については、2次選考までは順調でした。お互い途中までは意気投合していたこともあり、面接が終わったその場で合格を頂いたのは後にも先にもこの会社だけでした。しかし、3次選考が5日間のフルタイム無賃インターンであることが判明してから、流れは大きく変わりました。

どうにかならないか人事に掛け合った結果、「あなたのことは大変良く気に入っています!なので、最終選考を終えた後、内定が出たら無賃インターンをしてもらえればと思いましたが、どうですか?」と素晴らしい提案を頂きました。なぜ私のことをよく気に入ったにも関わらず、内定を出した後に無賃インターンをするのでしょうか…?私の実家年収がかなり低く、はっきり言って無賃インターンを5日間もしていては生活が回りません。そこで改めて三次選考についての再考をお願いしたところ、メールが返ってこなくなってしまいました(これは私も悪いと思いますが)。メール一言ぐらいは返して欲しいですが…

W社

W社については選考を受けておりませんが、「あなたが夏に体験した弊社のインターンについて何か意見を頂けませんか?」というお話を人事の方から頂いたのでビデオ通話を行いました。ところが、私が就活クロージングし始めていることを伝えたにも関わらず、途中からあなたは弊社について誤解をしていますCTOと是非ランチに行って誤解を解きませんか?」としか仰らなくなり、流石に苦笑してしまいました。私の先輩をサイレントお祈りしたり、違法アニメアップロードサイトリンクを呟いたりする人事の方がいらっしゃる会社というのは存じておりましたからあまりショックはありませんでしたが。

2017-12-08

anond:20171208141536

厳密に言うと「ソーシャルゲーム」とはSNS上でプレイできるゲームことなんだけど、

ご存知のとおり現在の主流はネイティブアプリだし、

それ以外のブラゲもSNSの衰退に伴って「いろんなSNSアカウント連携できる」程度になってしまっている。

なのでもう「ソシャゲ」という表現はどう頑張っても実態に即さないし、

その呼称を使ってる人たちもガラケー時代からの習慣で使ってるだけ(「写メ」と同じ)。

その上で、たまにガチで「ソシャゲ」で認識が止まっている奴がいて、

ポチポチゲー」を思い浮かべながら「ソーシャル性」について語ったりするから嘲笑されるんだな。

2017-07-10

職業プログラマに向いてない

新卒プログラマー受託下請けじゃないSI会社で働いている。

現在ネイティブアプリの開発をしている。

プログラミングが嫌いなわけじゃない。

会社以外でもコーディングをしている。

副業のためのプロダクトを作ったり、単に自分にとって便利なスクリプトを書いたり。

ただ、業務で書くプログラム情熱が注げない。

rubyに比べて書きにくいJavaを使っているからか、それともモバイルが良くないのか、私がやりたいことはコーディングじゃなくてプロダクトを作ることだったのか、どれが原因なのかはわからないし、全てなのかもしれない。

ただ、情熱が湧いてこないのだ。

2017-07-09

BA以外の回答を見るにはChiebukuroViewer.exeインストールしてください

Y!知恵袋が少し前まで、スマホ版ではWebではBAしか見せず、それ以外の回答はアプリで見ろとアプリゴリ押ししてたのは記憶に新しいだろう。幸いにも今はWebで全部見れるようになった

なぜスマホサイトアプリゴリ押ししたがるのだろうか。Webで完結するサイトをわざわざネイティブアプリを介して見させる意味がわからない。(*よく利用する*人なら通知がくる、手軽に投稿できるなどネイティブアプリメリットはあるが)

togetterだってアプリ推してくるし・・・

もしPC知恵袋を見ててChiebukuroViewer.exeインストールして続きを見るとか言われたら(゚Д゚)ハァ?となるだろう。

ブラウザで完結するコンテンツでなぜスマホだけ専用アプリを使わそうとするのか。

2017-02-14

http://anond.hatelabo.jp/20170214124521

増田のようなスタンス否定する謂れは一切無いし、むしろそういうライトファンを如何に獲得するかがコンテンツの発展につながることは承知の上で、ではなんでゲームもふれて欲しいという熱心なファンが多いのかというと、やっぱり情報量が段違いなんですね

で、このアイドルゲームスタンスとしては、アイドルアイドルであるまえに人間だと

それを表すための膨大で多角的テキストゲームには詰まってるのです

しか最近ソシャゲベースで展開していますから時間軸という概念を獲得しまして、もはや容易には伝えきれない量になっていて、もう自分でやって自分で発掘してもらうしか無いのです

正直申し訳ない気はしないでもないです

ただ、メディアミックス展開や二次創作だけでなく、大本ゲームを、更に言うなら最新のネイティブアプリだけでなくブラウザゲームのほうも触れて欲しいというのはそういう事情があるのです

2016-05-22

http://anond.hatelabo.jp/20160522003506

http://anond.hatelabo.jp/20160522003506

ども。

この辺りの一連の発言特に後二者)を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAWeb APIといったフロントエンド世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます

ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データ配信DB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリレベルに追いつき、同じやり方ができるようになった、というだけの話です。

とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。

具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドリアルタイム集計が登場する勤務予定表的なものを、1人でjQuerySPAで作った際、数百行のHTMLと数千行のJSスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代ベスト」として自信を持って残せますJSX局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません(私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います)。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。

「変な独自拡張を入れてまでJSを使い続ける理由わからん」についても、まるでJS生来嫌われ者で、クライアント側でもPythonRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね? たぶんES6は人々から積極的に愛されています。現状、クライアント側にPython進出するのではなく、逆にデスクトップモバイルサーバ側にどんどんJavaScript進出する流れが起きています

速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね(mustache使うよりは速いよね)ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通JS技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

2016-04-26

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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

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

2015-09-01

リセマラした方がいいですか?

日本国内において家庭用ゲーム市場の衰退が叫ばれる中、スマホゲームアプリこそが最後フロンティアであると各企業はこぞって開拓船に奴隷を乗せて送り出している。

アプリ毎日のように生まれ出で、さながら夜空を埋める星のようである。そして生まれた星にはイナゴの群れが取り付き、多くはその重みと自重に耐え切れず地上へ落下し星屑と成り果てている。この星屑組成100%が糞であるから世界は糞とイナゴの死骸まみれで阿鼻叫喚である

では落ちない星はどうなのか、これは落ちるまでは糞でないと言える。どれもいつか落ちるだろうとは熟練イナゴの話だが、パズドラなんかはもう3年もかぷかぷと笑っている。イナゴ諸兄におかれましては取り付く星を選ぶに当たり将来の糞とこういった綺羅星とを区別する基準を手に入れるべきである

他のイナゴに一歩差をつけたいあなたがするべきことは何か。イナゴは主に2chスマホアプリ板とiphone板に生息している、そこを観察するのがよい。確認するのはリセマラの必要度合い、ただこの一点である。これが高いゲームは糞である

リセマラが必要になるということはつまりゲーム通貨(Nが出ないガチャを回すためのもの、以下これをパワストーンと呼ぶ)のゲーム内入手方法が限られており、プレイアブルかどうかがガチャの景品のレアリティに大きく依存していてなおかつ同レアリティ間でも格差が激しい(金特をよこさなPR以下に人権はなく、リセマラするならSR彼女一択。ただしエミリと小筆は除く)、加えてその排出率が極めて小さい(具体的にはSR以上で3%前後。ただしこの中には森河一派が含まれている)ことを意味するからだ。これは一般に糞ゲーである。6分以上かけて単発で1%未満の当たりを狙う過酷労働に多くの青少年は心身を破壊され二度とボールを握れない体になってしまった。またリセットのたびに大量のデータの再DLを促すコナミが各通信事業者癒着関係にあることも明白である。焦らずそのうちメダルSRチケを取ればいいじゃないという意見もあろうが、これにはやはり過酷労働を強いられる上に、森河一派によって神経衰弱に陥る危険性もあり、国際労働基準観点から賛同しかねる。

安易ランキングイベントを乱発しその都度累計ボーダーを上げていくコナミには猛省が必要であるが、パワストーンゲーム内配布が大幅に緩和された点を持って良運営とする向きも無いではない。しかしいくら配られたところで出ないものは出ないのだからこれに意味はないというのもうなずける話であるランキングイベントの乱発はモードの少なさに起因するところが大きい、すみやかなペナント実装が待たれる。

何にせよ伊集院の愛したパワプロは死に絶えた。彼が出したコナミへの絶縁状はまことに正しいものであった。

ところで、皆が皆ネイティブアプリを作りだしたためグリー任天堂に先んじて死んでしまった。無念である

その点DMMはすごいなあ。DMMPCブラウザゲームプラットフォーム王様だ。グリーにはとても出来ない。

2015-05-27

http://anond.hatelabo.jp/20140527230128

いまAndroidiOSネイティブアプリつくろうとしてるんだけどAndroidってあんまダメ

アプリ課金とか広告とかで稼げないかなあと思ってるんだけど。

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