「ウェブブラウザ」を含む日記 RSS

はてなキーワード: ウェブブラウザとは

2019-06-17

AdobeReaderの、拡大表示すると相対的スクロール量が減るのって解決済み

今はPDFを見るのにウェブブラウザを使ってるんだけど。

2019-01-28

anond:20190128000709

もう三・四年前から最近の子ウェブブラウザを使わない」と言われていると思う。

2019-01-26

はてブさよなら

はてブにもツイッターにもまあ問題点は色々あるのだけど、

はてブは一つの記事話題に対して様々な意見が集まるページがメイン。個人のページはサブな感じ。

ツイッター個人のページがメインで、一つの記事話題に対して様々な意見が集まるページはハッシュタグキーワード検索した場合に生まれ副次的もの

はてブには「非表示」という機能はあるがブロックに相当するものはない。

ツイッターミュートだけでなくブロックもできる。

はてブはかつては先進的な言論が集まる面があった。しかしその後ネトウヨ流入して言論の質はツイッターと変わらなくなった。そうなると、脳が腐っているとしか思えないネトウヨが大嫌いな自分にとっては上記の特徴は不快しかなかった。そのほか、

はてブは100文字だがツイッターは150文字、話を続けたければ自己返信や自己引用で続ける事が可能

文字制限の無い「はてなハイク」は間もなく終了予定。

こうなると、はてブを続ける意義はほとんど無かった。

スマホはてブアプリを消去し、パソコンウェブブラウザにあったはてブボタンも消去した今、とても清々しい気分だ。

2018-12-07

Firefoxの何が素晴らしいって検索欄とURL欄が分かれてることだよな。

あれを一緒にしはじめたのはChromeだったと思うけど、

そのせいでドメイン検索しようとすると当該ページに行ってしまったり、

英単語検索しようと思ったら勝手履歴から補完されてどっかのページに飛んでしまったりする。

そんなちょっとした、しか日常的に積み重なるとイライラしてしまうようなことも、

検索欄とURL欄を分けるだけで解決するんだ。

本当にChromeデザイン的にも機能的にもカスだし、

速い速いっていうけどメモリ馬鹿食いしてるだけだし、

個人情報を抜き取りまくって金に換えているし、

こんなのがデファクトスタンダードとしてウェブブラウザを寡占するだなんてゾッとする。

EvilGoogleを捨てよう!

みんなでFirefoxを使おう!

https://www.mozilla.org/ja/firefox/

2018-07-31

anond:20180731172845

もとからゲームとしてのVRは、家庭用じゃなく施設用でしかありえないと思うよ。

ハイスペックのゲーミングPC保有して、ルームスケールVRできるヤツなんて、世界で見てもどれだけいるのか。

ウェブブラウザが使えます」とか「PCの画面をVRに出力できます」とか、そういう実用方面に振ってきたのは生き残り術としてはそれしかない感じ。

Oculus Goウィンドウ自由ドラッグできないことのがっかり感がすごいよね。

それこそウェブブラウザでも複数のタブをVR空間のあちこちに配置したいのに。

2018-07-22

icloudかいうそびえ立つクソ、あるいは128GBモデルを買えない俺の敗北について。

正真正銘貧乏人なので数年前にNMP一括ゼロプラスキャッシュバックゲッツしたiphone6の16GBモデルをつこうております

バッテリーとかコネクタの交換とかで延命させてたんだけど結局それがとどめを刺すことになり挙動がやばくなってきたのでPCバックアップを取ることに。

16GBとかいう容量では対してなにか入れたつもりでなくてもアレで、ストレージに余裕を持たせるためにicloud写真をあげるようにしたのが数ヶ月前。

よくわかんないんだが撮った写真がいちいちクラウドに上がって、なにか使おうと思ったらいちいちダウンロードしてこないといけない。めんどくさい。

appleが悪いのか俺のPCが悪いのかよくわからんが、書いてあるとおりにやろうとしてもできない率の高さは異常

icloudとかなんなんだよ

iphoneストレージが足りないか写真icloudにアップしたんだけどPCに保存しようとしたら

icloud photo有効ではありませんとかでてきて、ダウンロード選択できない

ネットに書いてあるとおりやろうとしてもダウンロードっていうボタンが出てこない

しょうがいかウェブブラウザからicloudアクセスした

ctrl+Aで全選択できなくてctrl+Alt+ひとつひとつクリックでちまちま何百枚も選択しないといけない

その上、保存先が選択できなくて全部ダウンロードって名前フォルダに落ちてくる

2018-06-23

女の性的な部分が強調された広告から逃げたい

前提として私は女で漫画が好きなんだけど

twitterとか見てるとバンバン漫画とかスマホゲーとかの広告が出てくるわけ

それがかなりの確率主観)で女の性的なところが強調されてる画像なんだよ

女の尻どアップだったり、それどころかセックスしかけだったりしてたりした後だったり

いやもーーー勘弁してくれーーーーー

女向け漫画も男向け漫画も女の性的なところを強調する広告出してくるのやめてくれ

マンガアプリとかでも、実際使ってるやつの広告が出てくるときあるんだけど、

いやおめーー女の乳や尻がメインじゃないすげーいい漫画いっぱいあるのになんでそのシーンだけチョイスしたっていうやつ多くてしんどい

分かるよ、エロは人を惹きつけるよ。私もエロは好きだよ。こないだエロ漫画買ったし

けどそれを心構えしてない時にドーーーンバーーーーーンって出してくるのが心に負担なんだよ

それが何度も何度も繰り返されてしんどいんだよ

なんで「女といえばエロだよね!!!」って感じで女のエロ画像広告に使いまくるんだよ

見ててつらいよ、女が性的搾取されてたりいじめられてたりする漫画広告つらいよ

誰が最初に潮を吹くかゲームとかそういうの、いきなり広告で出すのやめてくれよ

誰かがそういうのを好きなのは分かるし誰かに需要があるのは分かるから、嫌いな人がそういうのを一括で拒否できる公的なやり方が欲しいよ

話がずれるけど、男の性的な部分が強調された広告ならいいのかっていったら、それはそれでしんどいんだろうなと思う

なにせこっちは性的なこと考えてない時に「はーーーーいセックスでーーーーーす!!!!!!!!」っていきなり広告ぶち込まれててさ

いや私のテンション的にいまセックス匂わす系はお呼びじゃねえんだわってかんじなのさ

から女でも男でも組み合わせがヘテロでもホモでも性的なのをいきなり流されるのがしんどいんだろうけど

実はそこに更に「性的なのは女に偏ってる」っていう私の観測が入って、なんで女だけなんだよっていう主観的なムカつきが混ざってて、今はしんどいんだろうなと思う

あと私の性的なことを常に求めているわけではない性質とか混ざってさ

うーーんこのあたり支離滅裂でごめんね

更にずれるけどギスギスした追い詰められてる系漫画広告しんどい

人類みんなバトルロイヤル漫画いじめ復讐漫画が好きなわけではないんだよ

何かのつらさを全面に押し出す広告ばかり流れてくるのはしんどいんだよなあ

追記

twitterクライアントについて提案してくれてありがとうtwitter好きだからさ、「広告で金稼いで長生きしてくれよな!」と思って公式アプリを使ってたんだわ。けどなんかもうこの広告見続けるの限界かなって思ったので教えてもらったやつに乗り換えようと思う。

あとウェブブラウザに関してはアドブロック入れてるんだ。けど広告はすり抜けて表示されるし、cookie制限?とかで通販とか色々やりづらくてさ、それも難儀してる。アドブロック提供してる会社ウェブブラウザも入れたよ。あれ9割広告非表示にしてくれてありがたいよ。けど望ましい広告まで制限かけちゃうからさ、それはそれでどうかと思うんだよね。広告すること自体は悪くないじゃん。自サイト広告載せることで頑張ってるサイトはどーなんのかなーとかさ、利用者として申し訳なさあるんだよね

なんていうかさ、個人努力で嫌な広告ガードするのもいいんだけど、それって結構疲れるし知らない人はノーガードになっちゃうじゃん。いろんな人がネット使うわけだしさ、もっと楽に「ごめんこの広告無理だわ」ってやつを見たくないボタンみたいなの押したらそれに類似した広告体現れなくなるみたいなの欲しい。好きなものを見てる時に突然現れる苦手なものから逃げる方法が欲しい。私インターネット広告の仕組みよくわかってないか馬鹿なこと言ってるんじゃねーかなと思うけどさー

再追記

ブクマコメで一個どうしても見逃せないのあったから書くけど

文中に出した「ホモ」って単語についてなんだけど、「組み合わせがヘテロでもホモでも」って書いてる通り、ヘテロ(異なるもの同士)ホモ(同じもの同士)って意味でさ、高校生物の授業で出てくるヘテロ接合ホモ接合と同じ感覚で使ったんだわ。

別に誰かを貶めたいわけじゃないんだよね

けどもしかしてこういう使い方も今ってだめなのかな?ホモって単語使った時点でだめなのかな。不勉強でわからいから今度本とか読んでみるわ。指摘してくれてありがとね

2018-06-14

最近ウェブサイトに対する考え方がなんかおかしい気がする

昔のホームページしろブログしろ個人が好きなもの載せたり書いたりするところで、何を置くかはその人の好みで好きにすればいいところだ

来る人に優しいコンテンツでも一見さんお断りな感じでも好きにすればいい

怖い画像ブラクラみたいなのだって見る側の自己責任で作る人には問題ない

脆弱性ついてPCを壊すとかになれば別だけど通常のウェブブラウザ許可されてるもので何しようが自由


そうしたウェブページを公開してるのは、自分の部屋を一般公開して見に来る人に見せてるようなもの


見に来る人はわざわざ訪問してきて部屋の中を見てるわけで見たくなければ帰ればいい

わざわざ見に来て文句つけるような人は筋違いだし相手にする必要もない


なのに最近ではわざわざ自分で見ておいて文句ばっかり言ってる

独り言で言ってる分にはどうでもいいけど正式クレーム出してるとかまである

さらにはマイニングスクリプト犯罪とかまで言ってる


PC知識のないライト層まで使うことになったせいで前述のような考えがなくなってる気がする

ウェブサイト自分の気に入るコンテンツ提供するためにあって気分を害するものは全て許されないものとでも思ってるのだろうか


昔はもっと一般に普及して当たり前のようなものになったらいいなーとは思っていたがその結果がこれなら、面倒なライト層のいない昔のアンダーグラウンド感もあるくらいのウェブのほうが居心地のいいものだったと思う

2018-03-16

ブックマークが多い人

はてブの話じゃなくて、インターネットウェブブラウザでの話ね

あのブックマークが多い人ってなんか保留体質というか

いろいろやろうとするけど結局なにもやらないタイプの人多そう

2018-01-20

仮想通貨オートサーフ

この1,2か月、仮想通貨界隈の盛り上がりと、暴落後の阿鼻叫喚を眺めながら、不思議既視感にとらわれていた。

10年以上前オートサーフ流行し、急速に凋落した頃の雰囲気そっくりだったからだ。2005年から2006年頃にかけての話だ。


オートサーフとはなにかというと、

インターネット界隈で、オートサーフは、広告掲載したウェブサイトウェブブラウザー上で回転させるトラフィックエクスチェンジのことである。したがって、オートサーフ広告掲載したウェブサイトに大量のトラフィックを呼び込むことができる。メンバーは閲覧するサイト毎にクレジットを稼ぐことができ、このクレジットは、オートサーフの回転に追加することで、メンバーサイト広告することができる。オートサーフ業者に料金を支払う外部の広告掲載者は、サイトを追加することができる。

https://en.wikipedia.org/wiki/Autosurf


一見して、よくわからない説明かもしれない。あたりまえだ。その理由は後ほど。

ようするに、投資にうとい人間にとっては、オートサーフとは、業者お金を預けて、ブラウザー上で広告を表示させて放っておくと、預けたお金がたちまちのうちに何倍にもなるという、きわめて魅力的な「投資」話に見えたのだ。

12 DailyProとHYIP


オートサーフ業者のなかで最大手12 DailyProというアメリカ業者で、ユーザーが$6から$6,000の金額を預けると、12日間で144%の利益が得られると公言して、多数のユーザーを集めていた。

から見ると、じつにあほらしい話に見えるが、当時はこれがもっともらしい投資話に見えるようなネット上の光景があったのだ。その話も後ほど。

2005年の末頃には雨後の筍のように多数のオートサーフ業者が乱立し、高利率をうたってユーザーを集めていた。

特に利率が高く、リスクも高いサイトHYIPと呼ばれていたのだが、そのリスクとはどういうものかよくわかっている人はあまりいなかったように思う。

(HYIPの公言する利率がどのようなものであったかの例として、本エントリーの末尾に当時受信したスパムメールを貼っておく)

利率が高いサイトほど胡散臭いという共通認識はあった。

実際、運営開始当初は高い利益分配報告をしていたHYIPのサイトが、やがて運営を停止し、ドメインごと消滅するという事態は珍しくなかった。

そのようなことが続くと、オートサーフ広告業からの出稿料金をユーザー間で分配しているのではなく、ユーザーが預けたお金を分配しているだけのねずみ講ではないか、と危惧する人が出てくるのはもっともなことだった。

そしてその危惧は的中した。

2006年2月SECアメリカ証券取引委員会)は12 DailyProを恒久的に営業停止とした。

SEC捜査により、12 DailyProは世界中で30万人以上の投資家から5000万ドル以上を集めた巨大なねずみ講であることが明らかになった。

12 Daily Proの運営カリスジョンソン逮捕され、12 DailyProは運営停止後、法定管財人管理下に置かれた。

当然、12 DailyProにお金を注ぎこんでいたユーザーは大混乱に陥った。

法定管財人はその後数年間にわたり12 DailyProの清算状況をユーザーメールで報告しつづけたが、ユーザーに戻ったお金ほとんどなかったと思う。



日本での反応


日本インターネット界隈では、2005年にはオートサーフに関する話題が盛り上がりを見せていた。

各種掲示板では有利なオートサーフ業者に関する議論が行われ、ブログ上で収益報告をする記事が相次いだ。

「楽して高収入」をうたいながら、オートサーフ業者への登録手順を解説し、アフィリエイト収入を得たり情報商材販売する者が現れた。

そういった人々は、オートサーフのことを、まだそれほど世の中に広がっておらず、知っている者(情報強者)だけが得することのできるおいしい「投資話」だとしていた。

このような「投資話」で読者を煽った人びとは責任を取らず、消えた。

昨年から仮想通貨への投資話がネット上で盛り上がりを見せていたとき自分にはオートサーフのことが思い出されて、投資する気にはなれなかった。

もちろん、仮想通貨オートサーフでは、技術的な背景も、行われている投資の規模も全く違う。それはわかる。

だが、仮想通貨が盛り上がりを見せたときの、日本インターネット界隈での反応、うごめいている人々の素性が、オートサーフ騒ぎの時と、あまりにもよく似ていた。

筋の悪い「投資話」の特徴



今回、仮想通貨暴落を受けて、筋の悪い「投資話」に共通する日本インターネット界隈の反応を、自分自身経験則としてまとめておく。


筋の悪い「投資話」の特徴

  1. これは海外からもたらされた新しい情報だとして、ブログで騒ぎ始める人物が現れる
  2. 騒ぎ始める人物は、アフィリエイト情報商材で読者から金を集める山師的な素性の者が多く、秘密めかして自分権威であることを装う
  3. 投資話」の内容は、ネット上で投資するだけで、多大なリターンが得られる楽なものであるが、仕組みがよくわからない
  4. 山師煽りを受けて、あまり勉強ができそうでない、金融リテラシーの低そうなユーザー投資を初め、自分最先端を行っており、賢いのだと、ブログソーシャルメディアでイキり始める
  5. 上記煽りを受け、金融リテラシーが低く、所得も低いが、真面目なユーザーが、人生一発大逆転のチャンスだとして「投資話」に飛びつき、真面目に論じ始める
  6. 投資話」がもっともらしい「投資」に見え始める





参考:HYIPの広告メール

New and Good HYIP!! Auto-Withdrawals!

http://dischargefunds.com/

125% after one day (Auto-Withdrawal)

Plan Spent Amount (US$) Daily Profit (%)

Plan 1 $1 and more 125.00

68% daily for 2 days(Auto-Withdrawal)

Plan Spent Amount (US$) Daily Profit (%)

Plan 1 $1 - $100 65.00

Plan 2 $101 - $5,000 68.00

165% after two days (Auto-Withdrawal)

Plan Spent Amount (US$) Profit (%)

Plan 1 $5 - $100 160.00

Plan 2 $101 - $5,000 165.00

2017-12-21

ただの攻略サイト攻略wikiと呼ぶな問題

攻略wikiっぽくない「自称攻略wiki」を見かけるようになった - シロクマの屑籠

http://p-shirokuma.hatenadiary.com/entry/20171221/1513820193


最近据え置きゲーをやっておらず、スマホゲーとブラウザゲーばかりの増田です。

ウィキペディアwikiと略すな、は十分周知されているとは思いますが、wiki的な編集過程でない普通の

攻略サイト攻略wikiと呼ぶな、というのは言われてみるに確かにそうね。

wikiとは何か。

多くのウィキ共通する特徴を以下に掲げる。
ネットワーク上のどこからでも、いつでも誰でも文書を書き換えることができる。
・文書の書き換えに最低限必要なツールウェブブラウザのみである
ウィキ特有の文書マークアップHTMLなどと比べて簡潔なので覚えやすい。
・同じウィキ内の文書間にリンクが張りやすくなっており、個々の文書が高度に連携した文書群を作成しやすい。
・大抵は、変更の事前許可を必要とせず、ウィキのあるサーバ接続できる人に開かれている。実際、ユーザアカウントの登録を必要としていないところも多い。

と言われているんやで

[要出展]


攻略wiki3分

現在の「攻略wiki」は3種類に分類される。

1.本来wiki要素で作成されている攻略wiki

2.従来の出版社ゲーム攻略サイトwikiを名乗っている系

3.特に増えている新興ゲーム攻略サイトwikiを名乗っている系

それぞれについて少し語る。


1.本来攻略wiki

攻略wiki以前はゲーム攻略ってどうやっていただろうか。

個人マニアが立ち上げた攻略サイト。新声社や電波新聞社といったプレイヤーもいた攻略本界隈。

友達の兄ちゃんに嘘テク教えられたり、実際は小数点以下の確率で盗める。

こんなゲームにマジになってどうすんの。


企業のネットが星を覆い、電子や光が駆け巡っても、個人攻略できるレベルを超えたボリュームゲーム

アフィリエイターが食い尽くすほど情報化されていない近過去

一人で無理ならみんなで情報を持ち寄ろう、ネット匿名で平等で集合知でウィンウィン。

同好の士があつまり不特定多数が記事更新をする攻略wiki

2chのゲームスレテンプレに貼られているのがこういう攻略wiki


そういう純真ネット民もやがては気付く。

wikiに貼ってある広告のアフィってwiki開設者に入ってるんじゃね?

真偽は定かではないが、ゲーム攻略wikiは儲かる、他サイトデータコピペして作成し、ライバルの方には

デタラメ煽りを書き込んだりして評判を落とす。トップ攻略地位をもぎ取ればウハウハ、という手法

2chまとめ増田で読んだ記憶がある。

世はまさに大嫌儲時代、モンキーDアフィの五武海はちまjinやらおんハム速ニュー速VIPが追放されたり

2ch政府の内紛分裂があったり。

そんな嵐が過ぎて見回してみれば、1型攻略wikiは凋落して、3型の全盛期。

ゲーム単体の攻略も大変だが、リリースされるゲームの数も膨大。

人気ゲーム攻略ニーズは多く、PVが増えれば金も集まる。

世はまさにガチャゴールドラッシュ、だけど一攫千金でゲーム開発するより、シャベルジーンズテンプレ

儲ける方が固い商売だよね。


2.WARNING!! A HUGE BATTLESHIP KADOKAWA IS APPROACHING FAST

そうボスカドカワなんだ。たつきは帰ってこないんだ。君も人生と向き合うときなんだ。

ゲーム攻略Wikiまとめ - ファミ通.com

https://www.famitsu.com/wiki/

これが、アレでしょうね。出版社系の。攻略wikiの。なれそめ?初出?元凶?根源?大丈夫

Wikiサイトっぽい外見してますライター執筆記事やファミ通企画攻略動画へのリンク盛り盛り。

一般人ツイッター連携掲示板とかコメント欄には書けるけど記事編集は無理そう?

基本的ライターに書かせているであろう攻略サイトwikiと呼ぶのは、SEO有利・プレイヤー

親しみを持たれるからではないかと思う。が、外注ライターの個別記事をいちいち社内で検収して

からアップロードといっただるいスタイルを取らずに実際にwiki形式で登録ライターが直接編集

しています、ってことかもしれない。

ファミ通WikiはGzbrainが運営。カドカワ傘下で浜村編集長会社です。


で、出版社系言いますけども1.でちょっと触れたようなかつて攻略本出してた系の出版社死に体で。

お家騒動で分裂した電撃MWも、富士見書房ファミ通文庫オタク系は軒並みカドカワの軍門に降り、

時々絶妙インタビュー記事などを載せる電ファミニコゲーマードワンゴ運営。

電撃も、ファミ通も、ニコニコも、闘会議もカドカワなんだ。

電ファミWiki

https://wiki.denfaminicogamer.jp

これwikiシステムの貸し出しやってますよ。って形式ですね。


あとは出版社ゲーム関係出してるってなるとVジャンプとかスクエニとかですかね。

本屋行ってもあとはアプリシリアルコード載ってるような奴と、晋遊舎三才ブックスのようなのと

wikiを紙に落としこんだ素性のわからない出版社の完全攻略本くらいしかない。

というかね、FF7あたりから10年くらいの、攻略本が売れ行きランキングに載ってきてしまうほどの時代、

アレが攻略本バブルだったんですよ。攻略本の対象ゲームバンバン売れてたわけですよ。

CDがカラオケBOXブームとかもあってめちゃくちゃ売れてたのと概ね同じ。経済バブルの残り香的な。

攻略本バブルが無ければエルムドアだって


3.攻略は再び名人の時代へ

古の昔、連射こそがすべてであり、鋼の定規と16連射支配する、高橋名人の時代があった。

実際にはハドソン社員高橋名人ゲーム自体もそれほど上手いわけではないらしいが。

そのハドソン出身の山本大介が作った(※)パズドラがヒットしたけれども、アプリ内には外部の

攻略サイトへのリンクがあったんですよ。ファミ通Appbank

これね、パズドラが初めてじゃないとは思うんですけどね、衝撃でした。増田には。


※全くの余談。ゲームは1日1時間という標語ハドソン由来でパズドラでもランダムTIPSで表示される。

ほならね、ペアレンタルロックで1時間制限させてみろって話でね。

ゲームを作ったのは誰か論争、これ法隆寺は誰が建てた、みたいな話になるので難しい。

パズドラ山本Pが手動して作ったが、あのドロップが吸い付く操作性・移動に伴うクリック感ある音と

コンボエフェクトの快感、を実装したコアプログラマーアプリリリース後に抜けてしまい穴を埋めるのに

2年位かかっていたのではないかと増田増田は勝手に思うのです。なんでかつうと、パズル操作盤面内へ

の改修がその間ほとんど行われず、イラストステータス変えたモンスターの追加だけで2年間過ぎて

いったから。間を持たせるためにイベントとか生放送で盛り上げてごまかすぞ、ってニコニコみたいな話。

いや、それでガチャ回るんだから美味しい話だし、ゲーム的にも余計なことしないでくれて平和で良かった

と今は思うけれども。その間に、W、チャレンジ、3DS版、アーケードなどパズドラアプリの再発明で繰り返し

修行してようやく操作に違和感もたせないレベルで盤面システム(十字消し・立て追い打ち・雲・帯・

ルーレットなど)いじれるようになったのかなと。3マッチパズルだけど何か納得いかない消え方(ワロス消し)

についても修正されたのその後なんだよね。

コアプログラマーが重要ってのは拡散ミリアサの終了事由のインタビュー記事を参照されたし。

指導的地位といえばパズドラエグゼクティブPであるガンホー森下社長、わしが作ったと言っておりパズドラ

こうして産まれたとのマンガでもそう描かれている。消費者庁コラボhttps://anond.hatelabo.jp/20170719231854

での謝罪責任者名は森下、それ移行の山本Pの対外的露出自粛も、作った男の主導権争い的な面もあるのでは

ないかとはゲスの勘ぐりですね。極み極み。

閑話休題


攻略リンクの話に戻ると、ファミ通はわかる、みんな大好きマックスむらいAppbankは何もんだ?

iPhoneケース販売とかアプリ紹介とかやってるんだって、へえ。

アプリリリース当時はAppストアの規制もぬるく、ダウンロードランキングの売買アプリ(他のゲームインストール

するとゲーム通貨発行)とか、シリアルコードとかセーフだったんで、単純に攻略データ誘導すると便利だね、

以上の素敵なサムシングの期待があったのかな。

Appbankwiki僭称せずに攻略記事を書いてるようです。

後にパズドラアンケートでは、攻略の際の参考にするサイトとしてどういうところを利用しているかの問に

ファミ通アプバンの他に、appmedia、gamewith、game8などが選択肢に上がっていた記憶がある。

こいつらwiki名乗ってますぜ旦那ァ!

こういう攻略サイト系、幅広くゲーム攻略してまして、運営は会社組織でやってまして、攻略ライター募集してまして、

ライターには石購入補助金も出まして、何それガキの小遣いじゃないか。

ゲームアプリは随時更新され日々攻略必要、またリリースされる数も半端じゃない。

どれがヒットするかわからないからツバつけておかないと後発では攻略覇権取れない。

きららファンタジアだってぐだぐだから離陸したFGOのように羽ばたくかもしれない。

からwiki形式で小遣いライターに委託するよ。

あるゲームでは充実した攻略情報が載っているサイトでも、他のゲームではテンプレ作って終わりだったりするのは

ライターの層の厚さの違いによるものなんだろうねえ。

そして栄枯盛衰、他サイトにどうしても勝てそうもないとなれば撤退やむ無し。


【FGO攻略wikiからのお知らせ】
2017年8月25日を持ちまして、FGO攻略wiki更新を停止いたしました。短い期間でしたが、これまでのご利用ありがとうございました。

https://game8.jp/fate-go/144602


これね、一つの攻略サイトは適当でも複数横断して集計すればまともな結果でるんじゃね、と星4鯖配布の時に調べてて

みつけた。ニトクリスもらいました。

https://anond.hatelabo.jp/20170921034548

ああ、終わりってこういう風に来るのか、って微妙気持ちになったね。


さらに話題転換。

Appbankといえばユーチューバーマックスむらいユーチューブの前はニコ生ガンホー公式放送でのメインプレイヤー

もやっていました。彼はそこそこ上手い程度ですがAppbankからユーチューバーとしてコスケとかが出てきたようです。

ヒカキンヒカキンゲームズやってますし、先述の攻略サイト運営会社の中にもユーチューブAbemaTVタレント事業

手がけてる会社もあり、サイバーエージェントやらGMOと取引あるところもあり、界隈ですなあ。

時代は上手いプレイヤー個人ゲームプレイ動画の攻略に移っていこうとしてるのかなあ。

プロスポーツとしてのeゲーム業界団体統合?して来年から本格始動みたいですしどうなるんでしょうね。


金の話とか

情熱あるゲーマー有志がボランティア攻略してどうこう、っていう集合知の善性は容易に横から収奪されて熱量が失われる。

上手い個人はプロゲーマーとか、ユーチューバーとしてマネタイズできる。

ゲーム上級者の増田があったけれども我々凡人は商業の攻略wiki見て満足すればいいんじゃないか。


攻略本出版社ライターに金出して作って、プレイヤーが金払って買った。

攻略サイトは運営がライターに石援助して、プレイヤーPVで金を稼ぐ。

「そこに何の違いもありゃしねえだろーが。」「違うのだ!」

どこに線をひけばいいかわかる人いる?それ、はあちゅうに教えてあげてね。

増田としては資本がどうであれ有用なデータがあるサイトが検索上位に来てくれればいい。

WELQのように信頼できない情報や、はてなキーワードの未作成ページにランディングすると

いちいちnaoyaは嫌いだけど、と前置きつけながら告訴したくもなる。


嫌儲問題とか村上隆の金の話https://anond.hatelabo.jp/20170925233933とかしようと思ったけど時間がなくなった。クエスト回さねば。

この辺で筆を置きます。短い期間でしたが、これまでのご愛読ありがとうございました。

2017-07-06

無知無理解プロジェクトが殺されそうだ

当方フリーIT 技術者。ある Web ベースシステムを開発しているのだが、プロジェクトマネージャーリーダーをはじめとするメンバー無知無理解のおかげで作業が進まずに困っています

ブラウザーキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。

登場人物

私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。

A 社内のチームメンバーは以下のとおり。

さて、今開発しているシステム(以下システム P)はもともとスタンドアローン運用する形態だったが、最近クラウドバージョン提供も始まり現在スタンドアローンバージョンクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバー管理や、私や W さんが作った部分のテスト担当している。

問題発覚

クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードアップデートすると、ブラウザーキャッシュが効いていて表示がおかしくなるというのだ。

プログラマー以外の 4 人は実は Web システム案件は初めてで、ブラウザーキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーキャッシュクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミークエリ文字列をつければよい。アップデートのたびに数字を変える。これは一般的採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。

これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。

前回リリースから変更のあったファイルの洗い出しを命じられる

X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルリストを出してほしい」と言われる。変更のないリソースにはクエリ文字列をつけたくないらしい。

内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコード確認し、この一覧表に載っているファイルにはクエリ文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイル対象にしたほうが作るほうもテストするほうも楽です」と伝えた。

問題発生箇所の調査を命じられる

6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラスID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。

私は「ブラウザーキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュ問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。

ブラウザーキャッシュの仕組みを基本から説明する

プログラマー 4 氏の知識底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーキャッシュの仕組みを解説する文書投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまりかいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。

キャッシュとは

キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります

ウェブブラウザーにおけるキャッシュ一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイルJavaScript ファイル画像ファイルなど)に対して適用されます

キャッシュが作られるタイミング

ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。

キャッシュが破棄されるタイミング

キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルキャッシュが同じ期間だけ存在するかどうかも分かりません。

キャッシュユーザーブラウザー操作で明示的に削除(クリアー)することはできますが、 サーバーからクライアント(ブラウザー)のキャッシュクリアーすることはできません。

ウェブアプリケーションキャッシュ対策

ウェブアプリケーションアップデートした際、クライアントキャッシュ無効にするために、以下の手法がよく使われます

link rel="stylesheet" type="text/css" href="style.css" >
< script type='text/javascript' src='script.js' >< /script >
< img src="picture.jpg" alt="" width="640" height="480" >

このような外部リソース読み込みについて、ファイル名の後ろにクエリ文字列を追加します。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >
< script type="text/javascript" src="script.js?v=2.4.0" >< /script >
< img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" >

スクリプトでない静的ファイルクエリ文字列を付加しても、読み込まれファイルは同じです。つまりstyle.cssstyle.css?v=2.4.0 は同じ style.css というファイルを指します。

ブラウザーが style.cssキャッシュしている状態で、この行を読み込んだとします。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >

ブラウザーは「style.css?v=2.4.0 というファイルキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれスタイルシート更新されます

この HTML をまた読み込んだ時は、「style.css?v=2.4.0 というファイルキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。

ウェブアプリケーションバージョン 2.5.0 にアップデートする時には、「?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。

link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" >
< script type="text/javascript" src="script.js?v=2.5.0" >< /script >
< img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" >

同様の仕組みで、2.4.0 時代キャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれキャッシュ問題は起こりません。

この手法は、キャッシュ問題解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます

上記に長々と書いた内容を踏まえ、今回の問題についてご説明します。

「暫定対応」の指示が出る

日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(< div style="..." >)で指定すればよい」と結論づけていた。

報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。

この報告書を元に、X さんから「この行とこの行にインラインスタイル指定してください。これで暫定対応します」と指示が出た。

私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境たまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業完了した。Gitコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。

しばらくすると X さんから「うまく表示されていますOK です」と報告があった。

その日のうちに問題再発

夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScriptキャッシュですね」。

聞けば、Y さんは「キャッシュスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタン有効だったとも。

私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。

Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。

私は繰り返し、ブラウザーキャッシュ環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。

「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者意見を聞いてください」

対応が先送りになる

この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。

聞けば、リリースを急いでいるのは特定顧客要望によるものらしい。その顧客スタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーキャッシュを消してくればいいとのこと。

リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。

レビュー開催

そして今日夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。

X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。

ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態対応策を一生懸命協議していたのですな。

レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者説明してもらったって、信じないんだったら意味がないのにねえ。

追記

文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。

https://anond.hatelabo.jp/20170706122924

2017-04-17

タブを何個も開いてブラウジングする感覚は「異常」なのか

僕は、毎日インターネット上の情報を閲覧する。スマホからも、パソコンからも、時にはタブレットからも。ニュースアプリを使ったり、はてなブックマークを使ったり、普通にブラウザーを使ったりなど、情報の入手の仕方は様々だ。

去年か一昨年くらいの話だが、友達PCで困ったことがあるから助けてほしい、と言われた。実際友達の家に行って助けようとしたのだが、内容の覚え具合が曖昧だったので、友達の家のPCを使って情報を調べることにした。その時に言われたのが、

「え、(タブを)めっちゃ開きすぎやん」って。

当時は8個くらい開いていたのだと思いますが、中学生にとってはおかしいのかな。

情報収集するときは、なるべく様々な視点から情報を得たいので、1つの話題に最低でも4個はタブを開く。そこに調べた情報の中に書かれている付帯情報も調べようとするので、さらに2個はタブを開く。そして、「あ、じゃあこれはどうだろう」と別の事柄を調べるために、またタブを開く。

ブログ記事を書くときは、情報収集を含めて10個ぐらいはタブを開くことが多い。この記事も、情報収集やこのブログデザイン変更をしている時に、ふと思いつきで書いたものなので、執筆時にはタブは12個開いていた。

そこに現れた「Vivaldi」というウェブブラウザは、タブをひとまとめにすることができるため、現在愛用している。

果たして、タブを何個も開いてブラウジングする感覚は異常なのだろうか。

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

2017-01-03

freeeの自動仕分け特許は本当に当たり前なのか

freeeがマネーフォワードを訴えた事で、その特許自体批判するコメントが多く見られる。

これは、ニュース記事などでも「文字列を元に自動仕分けする技術なんて世の中的にはもう何十年も前から存在するでしょ…」

といったように発明でもなんでもないとする論調が多い為だと思う。

http://cards.hateblo.jp/entry/freee-moneyfoward-saiban/

しかし、本当にこれが当たり前の技術なのか、特許審査官は当たり前の事に簡単特許を認めるのか。

そもそも、「文字列を元に自動仕訳する特許」という広範囲権利が及ぶ基本特許が取れたというのは正しい認識なのか。

という事で、実際の特許文献を見て確認してみた。

まず、上記引用記事で紹介されていた特許文献はこちら

http://astamuse.com/ja/granted/JP/No/5503795

そして、特許範囲を決める特許請求項を引用する

請求項1

クラウドコンピューティングによる会計処理を行うための会計処理装置であって、ユーザークラウドコンピューティング提供するウェブサーバを備え、前記ウェブサーバは、ウェブ明細データ取引ごとに識別し、各取引を、前記各取引取引内容の記載に基づいて、前記取引内容の記載に含まれうるキーワード勘定科目との対応づけを保持する対応テーブルを参照して、特定勘定科目自動的仕訳し、日付、取引内容、金額及び勘定科目を少なくとも含む仕訳データ作成し、作成された前記仕訳データは、ユーザーが前記ウェブサーバアクセスするコンピュータ送信され、前記コンピュータウェブブラウザに、仕訳処理画面として表示され、前記仕訳処理画面は、勘定科目を変更するためのメニューを有し、前記対応テーブルを参照した自動仕訳は、前記各取引取引内容の記載に対して、複数キーワードが含まれ場合キーワードの優先ルール適用し、優先順位の最も高いキーワードにより、前記対応テーブルの参照を行うことを特徴とする会計処理装置

この請求項を見ればこの特許権利を主張している範囲がざっくり分かる。

要約すると以下のような要件構成されている。

特許の仕組みは、請求項に記載されている事が全て満たされた場合のみ自分特許範囲だと権利主張できる。

まり、この特許

これだけ特許範囲限定されると、「文字列を元に自動仕訳する」仕組みがあればどんなシステムにでも権利主張できるものではない。

まり、これはfreeeがコア事業としているクラウド会計サービスが最大の強みとする「自動仕分け機能」に特化して特許取得したものと言える。

そして、この特許が出願されたのは「2013年10月17日」。

この時点で、クラウド会計サービス自動仕分けを行うという事が当たり前の仕組みだったのか、前例があったのかという事になる。

当然、審査官はその出願日を起点として過去に同一または類似の公知文献が無いか調査している。

まだクラウド会計処理をするという事が一般化されていない時期に、ベンチャー企業クラウド会計サービスで最もメリットとなりえる

自動仕分」を知財化し、後追いサービス牽制する戦略を取るのは当然とも言える。

しろ、もしこの特許が国際出願されており、海外に対しても権利化できるのであれば、今後海外展開した時に海外クラウド会計サービス

クロスライセンスを契約する際のカードにもなると思うので、取れる範囲はどんどん取っておくべきだと思う。

特許に関して批判が上がる原因としては、

が大きいと思う。

もしこの特許が当たり前だというのであれば、出願日時点より前に公知となっていた文献やサービスシステムを明示し訴える事で

特許無効化できる手続き手段も用意されている。取得できた特許権利絶対ではない。

何十年も前からある当たり前の技術だと言う人は、是非出願日以前に遡ってこの特許範囲と同一または類似する文献を明示してみて欲しい

2016-11-26

検索避けのれん

検索避け
アクセス制限とか「けlんlさlくlよlけ」とか
のれん
レンタルビデオ屋なんかでアダルト向けとかを隔離するアレ

非公式二次創作について検索避け部外者から強要されて従ういわれはない。ナマモノについては、わたし(筆者)のメインジャンルではないうえ、少々ややこしくなるので、保留とする。

配慮

配慮」という言葉が、「検索避け」の強要理由として使われているように思う。アダルトエログロや、原作にない性愛関係などを描いた二次創作物を見たくない「だれか」への配慮だ。

なるほど確かに、見たくない人もいるだろうな。ウンウン。そうかそうか、不快な思いをさせてしまうのか。

いや、待て待て。つまりそれはアレか? 「だれかが不快な思いをするから検索避けをしてくれ」と言うのか? 「だれかに不快な思いをさせたくないか検索避けをしてくれ」?

冗談じゃない。キリがない。万人に受け入れられるものはない(そんなものがあるなら教えてほしい)。これがまかり通るとき検索しうるあらゆるもの検索避けをさせられているわけだ。

刀剣乱舞」知ってる? 略してとうらぶ伝説刀剣やらが付喪神になって(擬人化して)男性の姿をとって、刀剣男士となったんだ。わたし実在したものを題材にしている作品二次創作から云々」と検索避けを押しつけるのを山ほど目にしてきたけれど、それなら、そもそも「刀剣乱舞自体検索避けをさせるべきじゃない? 「加l州l清l光」って。もちろん、DMMブラウザゲームのページにはアクセス制限もさせてさ。だって刀剣勝手擬人化して、あんなことやこんなことを言わせて、あまつさえ戦わせている! 不快な思いをするひと、いると思うんだけどな。

家庭教師ヒットマンREBORN!」は? ごく普通中学生だった沢田綱吉ことツナの前に殺し屋リボーンが現われて「おまえはマフィアの十代目だ」なんていう。かれに家光という父親がいることからわかるように、名前元ネタ徳川家なんだ。どう? 徳川綱吉のことを調べようとしたのに、沢田綱吉ばかりが出てくる! なんていうことを不快に思うひとは、絶対にいないの? 名前を変えさせるべきじゃない? あの主人公

いやいやいや。キリがないよね。田中鈴木佐藤。(申しわけないが)このありきたりな姓の持ち主はありふれていて、創作物に登場することも、ままある。一郎、太郎、幸子。いるぞ。

言っとくけど、違わないからな。これは「アダルトエログロや、原作にない性愛関係などを描いた二次創作物を見たくない」のと違わないんだぞ。根底には「不快感」があるんだ。この配慮の点で検索避けを求めるということは、「嫌な思いをするだれかのために検索避けしろ」ということと、違わないからな。

この「配慮」の面から検索避け強要するひとたちは、世界のあらゆる人の不快感を解消するため、あらゆるところへ検索避けを呼びかけてくれ。ぜひに。

トランプを探しているの。カードゲームよ。でも、あら、なんということかしら。わたしの大嫌いなドナルド・トランプばっかり出てくるわ! 嫌だわ。不快だわ。

ほらほら。(わたし別にドナルド・トランプは嫌いじゃない)

著作権

二次創作は実質違法行為なので、公式に見咎められないよう隠れて活動しなければならない」というアレ。

著作権二次創作とのことで、TPPとともに話題になった。TPPに参加すると、著作権親告罪がどうのこうのというあれそれ。まあ今のところ、公式が突きつけるまで、それは罪ではないということになっている(はずである)。

公式が、それ(二次創作)が犯罪かどうかを決める。

はい終了。

違法かどうかは公式判断することである

公式に見咎められないように……そうだね。公式利益を損なうのはよくない。

でも、判断するのは公式だ。「見咎められないよう隠れて」など、まるでやましいところがあるようではないか

公式の指示に速やかに従う。これだけでよいだろう。

のれん

ところで、アダルトとの境目にはのれんがある。物理的なフィルタだ。わたしたちは、物理フィルタのないところに、フィルタを見ることはできない。

まだ、その技術は普及していない。ARを目にし続ける将来は訪れるかもしれない。そうしたら、見たくないものを見なくてよくなるかもしれない。たとえば、露出度の高い女性水着広告だとかなんだとか。

でも、今はない。だから店側が物理的なフィルタとしてのれんを設け、年齢と覚悟を問うわけだ。おそらく。

検索避けのれん

で、検索避け強要する舞台がどこかというと、インターネットだ。あなたコンピュータだ。フィルタがかけられる。お互いに。けれど、あえて「不快に思うかもしれないだれか」のために、作者がのれんを用意する必要はない。どうしても見たくないものなら、それは見たくないひとが、見ないために努力をするはずだからコンピュータは、見たくないものを見ないことができない舞台ではない。

法的に年齢制限をかけるべきあれそれに検索避けを求めるのは、わかる。だが、それについては、検索避けより直接的な手段をとるべきだと思う。ここではおいておく。

そして、それ以外の「見たくない」ものについても(コンピュータでは)、検索避けより直接的な手段をとるべきだ。検索の仕方を工夫する(not検索とか)とか 、NGワードを設定するとか。やり方は、ぜひ自分検索してほしい。「ウェブブラウザ ngワード」とか。で、そうする手段がまだ用意されていないと思うなら、自ら開発するか、おとなしく待つといい。それすら我慢できないなら、もうやめたほうがいいと思う。インターネットが向いていないかもしれない。

世界の、なにかを不快に思うだれかのために、調べたやり方を共有すれば、より具体的に不快感を減らせるだろう。

(そのために、わざわざ嫌なものを一度は見なくてはならないのかとか文句を言うひとは、「食わず嫌い」の意味を調べてくれ)

もちろん、公式からなんらかの対処を求められたときは、それに速やかに従いますよ。でも、それまでは、なんら疚しいところのないわたしは、堂々と二次創作をする。公式原作)への感謝も忘れずに。いつもいつも原作を、たのしませてくださって、ありがとうございます

2016-10-13

ネットの闇?

注)リンク先が消えているため記事最後魚拓あり

http://anond.hatelabo.jp/20161012195410

子供出会い系サイトとのことで、色々エグい内容が書かれている。ただ、さすがにちょっと信じがたい。

記事でも書かれているが今どき児童ポルノ画像が堂々と貼られている場所があるってのが信じがたいし、直接画像が見れるのに警察が動かないのも首を傾げる。何より謎なのが、そんなサイトがあるのにロリコンが騒がず記事にしても無視されてるって状況が謎すぎる。本当なら絶対2ちゃん炎上する案件だ。

なので、実際に行って確かめてみた。

記事で書かれている3DS専用掲示板と、その管理者運営してる外部2ちゃんサイトは割と簡単に見つかる。

児童ポルノ画像で溢れかえっているように表現されているが、結論から言うとそのような画像は一枚もなかった。

隠しページもあったけど(懐かしいノリだな!)そちらも何もなし。

2ちゃんサイトのほうは、とにかく糞スレに糞レスが書き込まれてるだけで画像を貼ってるやつなんかいない。

3DS専用掲示板はどんなシステムかというと、オープンスレッド3DSフレンドコードを交換し、3DSメッセージで共有したパスで鍵付きスレッドに引きこもるって感じ。

専用っつーけど3DS関係いねこれ、たまたま子供の持ってるネット端末が3DSってだけで他のハードでも可能だな。

ともあれこっちの3DS掲示板は眉をひそめたくなるスレッド目白押しで、特に鍵付きスレッドではエロチャット画像の交換をしてる気配があり、いかがわしい空気が漂ってる。

しかし当然当事者以外は中を確認することはできないので疑惑しかなく、オープンスレッドを見るかぎり中学生猥談しつつ「学校だりー」とか「宿題めんどい」とか駄弁りながら、カゲプロとか戦国BASARAの話とかしてたまに鉛筆書きのオリキャラ画像をアップするみたいな場所らしい。

あれだな、子供の頃近所にあったエロ本秘密基地全国版だなこれ。

管理人がその手のスレッドを削除して証拠隠滅したのかとも思ったが、それもちょっと違う気がする。

何が違うのかって言うとこの2つのサイト、とにかく閑散としてる。

時間を置いて何度か見たけど、まともに書き込みがあるのは極一部のスレッドだけで、その書き込み常連らしいコテハンのくだらない馴れ合いレスばかりだ。

新しく立つスレッド殆どないし利用者も少ないように見える。良くも悪くもゴルスタのようなダイナミズムは欠片もない。

まあ、管理者は間違いなく変質者のたぐいだし、鍵付きスレッドでは子供同士が顔を晒しエロチャットしてるっぽいので子供を近づけるべきじゃないサイトなのは確かだ。

そして勘違いしてる人が多いようだけど、どちらのサイトPCスマホでも普通に使えるわけで任天堂は基本関係ない。元記事では3DSエロチャットしてるように書かれてるけど、そういう事ができないよう3DSのフレンド機能制限が多く貧弱に作られてる。問題なのはブラウザなのだ

全国の親御さんに伝えるべきは、小中学生ゲーム機はペアレンタルロックウェブブラウザ使用制限ときましょうってことかな。

何故か元記事が消されたようなので魚拓

http://archive.is/gwdyb

追記

一晩立ったが3DS画像掲示板のほうは管理者が削除したようだ。

すでに見れないが、自分の見た限りだと児童ポルノなどは存在しない、子供の多い下品掲示板だった。少なくとも表面上は元記事にあるような違法画像が溢れるような場所ではない。

ただし、鍵付きスレッドの中では画像ありのエロチャットがあったようで、実際オープンスレッド鍵部屋エロチャットしようみたいな誘いも見受けられた。外から見るぶんには疑惑しかないが。

管理者権限を使って覗き見して画像収集することも、多分やっていただろう。

しかし正直なところ、元記事告発されたような内容ではない。

しかしたら告発者の言うような悪い意味で活気のあった時期もあったのかもしれないが、自分の見たもの告発内容は完全に別物だった。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-05-18

また女が頭の悪いオレオレルールを主張しだした

絶えることなバカッター

RT 何度も言って申し訳ないのですが、引用RTは呟き元の相手に通知が表示されるのです。あなたはTLに現れた事象について述べたつもりでも、呟き元にとっては「いや知らんがな」の文句を言われたような状態になることがしばしばです。目の前の呟きは無料コンテンツではなく、生きた人間のそれです

https://twitter.com/yosinotennin/status/732882497944485889

何故こんなに何回も言うかといえばですね、こういったことが重なって興味深い・楽しい呟きをする方々(大抵フォロワー数が多い皆さん)が嫌になって呟かなくなってしまうとツイ廃としては困るのです。「引用RT相手に通知がいく」とご記憶いただければ幸いです。

https://twitter.com/yosinotennin/status/732883206601482240

ごめん、何を言っているか本気で分からないんだ。

一応わからないなりにまとめると、

1. 引用RTを使うな(公式RTを使ってその後ツイートしろ

2. なぜなら相手に通知が行くから

3. 相手に通知が行くとそれが嫌になって呟かなくなってしま

ということらしいのだが。

相手に通知が行くのは公式RTでも行くし、そもそもそれはウェブブラウザとか公式スマホアプリで見てるからだろ。

まあそれはいいとしても、「相手に通知が行くから控えろ」????????

公開されているツイートを用いて意見をいうことをやめろって???

でも公式RT後に自分つぶやくのなら良いって???

この理論を主張しているのみんな女なんだが、俺にはもう理解不能だ。誰か解読してくれ。本気で頼む。

2016-04-26

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

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

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