  |
はてなキーワード: Versionとは
2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。
そうしたらとんでもないことになっていた。
結論から言えばあからさまに怪しいデベロッパーが二次配布のソースコードを使って
itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8
www.gatobros.com/
play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween
www.pipletas.com/syobon/syobon.html
デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。
で、サポートURLのページをよく見るとOpenSource扱いになっていた
Original Source. Ported by @jezng using Emscripten.
sourceforge.net/projects/opensyobon/
Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeにアップロードしたようだ。
sourceforge.net/u/twoscomplement/profile/
で、SourceForgeのプロジェクト開設日が下記のとおりになっているが
Registered 2010-05-16
原作者のサイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの。
wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html
このSourceForgeのプロジェクト、再配布人が下記のライセンスで公開している。
www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると
としている。
SourceForgeに公開されているプロジェクトがGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。
が、まずこれ色々と問題がある
プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。
dxlib.o.oo7.jp/dxlicense.html より引用する。
<<ＤＸライブラリのライブラリファイルやソースコードの再配布について>>
ＤＸライブラリのライブラリファイル( 拡張子が lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず
クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz
なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか？
（配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。）
なお、実行ファイル形式で配布されている物の英語のReadMeには原作者のクレジットなし。
どうやらゲームファイルとソースコードが転載されたようだが、少々違和感がある。
Internet Archive内にあるソースコードとSourceForge内のソースコードが違う。
tiku氏のそのまま配布するなを遵守したのだろうか？ （配布されているソースコードには日本語が混じっているので非常に怪しいけど）
ただ、言えることはしょぼんのアクションがスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。
ここまで書いておいてなんなんだけど飽きた。
アマゾン（compute.amazonaws.com）による大量の不正クリックで頭を悩ませているアフィリエイトサイト運営者（まとめでもキュレーションでもない）は多いことだろう。
ASPのV社によると、これは「提携媒体様のサイト表記等のチェック」名目でのアクセスとのことだが、オーガニック検索で辿り着けるページだけでなく、広告出稿ページにまで広告経由で大量にやって来るから頭が痛い。しかも、課金されやすいように分単位、ときには秒単位でユーザーエージェントやホストを変更し、ひたすら同じ広告をクリックし続ける。リファラーなど一切ない。
例えば、このような具合である（サイトに関わる部分は*****にさせてもらった）。
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:15 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:25 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-198-222-214.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:35 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:44 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-197-86-194.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:05:45 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-76-193.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:26 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:30 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:32 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-199-85-63.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:38 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:39 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:06:39 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Win64; x64; Trident/6.0)"
ec2-52-198-49-221.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:07:06 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
ec2-52-68-194-244.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:07:17 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-198-243-110.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:11 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-198-243-110.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:25 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0"
ec2-52-196-112-20.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:48 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-193-171-45.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:54 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:08:58 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0"
ec2-52-198-169-39.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:02 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-192-198-30.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:04 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Win64; x64; Trident/6.0)"
ec2-52-193-171-45.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:40 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko"
ec2-52-197-156-176.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:09:46 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko"
ec2-52-196-112-20.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:16 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-44-248.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:25 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2"
ec2-52-69-168-106.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:32 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
ec2-52-199-85-63.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:10:52 +0900] ***** "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-199-44-248.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:08 +0900] ***** "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
ec2-52-68-45-242.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:08 +0900] ***** "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 OPR/34.0.2036.25"
ec2-52-69-169-154.ap-northeast-1.compute.amazonaws.com - - [14/Nov/2016:06:11:26 +0900] ***** "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36"
1日でクリックされる広告は多いときで2,000件を超え、ヤフーリスティング広告管理画面の「無効なクリック数」にはたった1日で1,000件を超える無効クリックが計上される始末だ。残念ながらヤフーのシステムでもすべてのamazonaws.comを無効にできず、クリック調査を依頼してわずかながら返金されるも、アマゾンによる不正クリックは数多くが課金計上され、支払っている。
この現状に気づいていないアフィリエイトサイト運営者も多いことだろう。たとえば商標で出稿するなどクライアントのガイドラインに違反している広告であればどんどんクリックしてもらって結構だし、むしろそのようなサイトは不正クリックで是非潰して欲しいところでもある。
だが、普通に出稿している広告にこのような異常なクリックをされるとたまったものではない。
amazonaws.comの地域属性はアメリカなので、では都道府県単位で限定出稿しても、普通に変わらず大量に不正クリックされる。
広告を引っ込めるわけにもいかないから狙われないようにキーワードを絞り込もうとするも、管理画面でクリックされた検索クエリーを確認すると、それはもう満遍なく不正クリックされている。
提携媒体のサイト表記チェック名目にしては数が膨大過ぎて迷惑だという旨をASPのV社に返信したが、それに対する返信はなく、要するに「我慢しろ」ということなのだろう。
それではと、不正クリックサービスの提供元であるAmazon Web Services (AWS) のabuseにサーバーの生ログを添えて通報すると、通報から10日経った頃に返ってきたメールは、
＞ We were unable to identify the customer responsible for the reported activity.
＞ Due to the frequency with which AWS public IP addresses can change ownership
とのことで（バカか）、もはや不正クリック代行業者どもが泣いて喜びそうなお粗末な現状である。
アフィリエイトサイト運営者は今すぐサーバーの生ログをチェックし、広告URLに異様な足跡が残っていないか確認すべきだろう。ヤフーリスティング広告の場合、不正クリックによる返金期限は過去60日しか遡れない。
あ、そうそう、最近ASKAで話題のギフハブらしき痕跡もあった。
ec2-52-198-19-198.ap-northeast-1.compute.amazonaws.com - - [23/Aug/2016:18:09:45 +0900] "GET ***** HTTP/1.1" 200 27625 "-" "Mechanize/2.7.0 Ruby/2.0.0p451 (http://github.com/sparklemotion/mechanize/)"
某qiitaの記事を読んでも伝えたいことがよく分からなかった。
仕事でバリバリ書いてないならシステムのPythonで十分だって主張も具体性に欠ける。
dockerとvagrantを勧めるんだったらpyenvだけじゃなくvenvもvirtualenvもいらないよね。
初心者がハマるからダメだっていうのはpyenvがダメな理由とは関係ないんじゃないの。
pyenvを使うと何がよくないのか説明ないよね。
声の大きな人の意見に初心者が振り回されて「pyenv捨てたらデキル人間」って思想が芽生えて、よくわからずtwitterで拡散していっちゃう。
python-versionを用意すると自動で環境を切り替えられるpyenv便利。
■youtubeエーリストガレージ(A List Garage)チャンネル
https://www.youtube.com/channel/UCzIh8D6mV3Bv2ev8IOOtjkA/videos
中古高級車販売店のエーリストガレージは、Youtubeに在庫のポルシェをはじめとした高級車の動画がある。
なぜか木彫りのカエルが高級車を紹介する、カエルversionの動画もある。
■ポルシェ 911(Type991) カレラS Martini Edition エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=rzg10CJF9i0
■ポルシェ911（Type997） ターボＳ カブリオレ カエルversion エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=JcCeWrgxedg
■ポルシェ 911(type997) ターボＳカブリオレ エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=GVX6PPieXiU
■ポルシェ911（Type997） ターボＳ カエルversion エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=BQ7wFzs8-jM
■ポルシェ 911(type997) ターボＳ エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=xFPMO8-lBl8
■ポルシェ ボクスターＳ カエルversion エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=3t34jDiggnQ
■ポルシェ ボクスターＳ エーリストガレージ(A List Garage)
https://www.youtube.com/watch?v=4rXosVuHXNI
結構売れてるっぽい。
買うなら早めにしたほうがいいのかな。
前書いたやつ
「ファイルまたはアセンブリ 'Microsoft.Web.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'、またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。 」
http://stackoverflow.com/questions/4742894/mvc3-deployment-dependency-problems
IIS を実行させているサーバの GAC に Microsoft.Web.Infrastructure.dll のアセンブリキャッシュが存在しないようです。
プロジェクト参照設定にある Microsoft.Web.Infrastructure のプロパティを開いて「ローカルコピー」を True に設定して、発行（デプロイ）しましょう。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (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 は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
ただの感想
「直すプロセスが働いていれば間違いは何も問題がない」とは言えず、やはり世の中には全部やり直した方が早いものはある
「翻訳は／誰がやっても／間違える」氏は、minghai 版と真鍋版の品質の程度の差に具体的に言及することから若干逃げているきらいがあるが（もちろん、数値的に評価するのはそもそも簡単なことではなかろう、そんな面倒なことに踏み込んで手間をかけて言及する義務はない）、全体としては、重要な品質の違いはない言っているようにも見える（推定であり、断言ではない）、少なくとも「「直すプロセスが働いていれば間違いは何も問題がない」とは言えず、やはり世の中には全部やり直した方が早いものはある」かどうかにかかわる程度において。
どちらにせよ、「「2ページに1個程度の誤訳があれば、それは確実に腐った翻訳だ」といった持論を述べたり、ご自身の翻訳に decent version と銘打ったりするにあたって、もう少し慎重を期されてもよろしいのではないかと思います。」という「翻訳は／誰がやっても／間違える」氏の指摘はかなり具体的で、誤訳の定義や誤訳といっても程度問題があるので単純に結論を導くこともできまいが、真鍋氏の普段の持論からすれば聞くべき所はあるのではなかろうかとも思われるが、果たして。
（思ったより反応をいただけたので少し追記しました。2015-11-16）
バンダイが展開する女児向けアーケードゲーム/アニメ「アイカツ！」
アイカツ！はいわゆる「音ゲー」の一種で、トップス・ボトムス・シューズ・アクセサリーの４種のカードを組み合わせてコーディネートし、オーディションという名のリズムゲームをクリアしてお仕事をゲットしていくという仕組みだ。
当然、豊富なバリエーションのオーディションステージが用意されるため、アイカツ！では年間20曲以上の楽曲が生まれている。
その楽曲の特徴は、キャラクターの声優とは別に歌唱担当が存在すること(STAR☆ANIS、AIKATSU☆STARS！など)、とにかくジャンルの幅が広いということ、そして“攻めてる”楽曲が多いということだ。
アイカツ！の立ち上げにはスーパーバイザーとしてアイドルにも造詣が深いアニメ監督、水島精二氏が関わっており、音楽制作については別のエントリを参照してほしい。
（アイカツ！における水島スーパーバイザーの仕事について - Togetterまとめ）
そして幅広いジャンルで攻めるという場合、楽曲の発注では、そのジャンルの先達の楽曲を参考にすることが当然多くなる。
特に水島氏はそこのイメージが具体的だったようで、アイカツ！の初期の楽曲は「何を参考にしたか」が比較的分かりやすい。
そこで、今回はアイカツ！の初期の楽曲を中心に、その元ネタ探しをしてみようと思う。（あくまで推察なので的外れなものもあると思う）
アニメの主題歌にこそなっていないものの、アイカツ！の原点ともいえる曲で、ゲームの企画段階の初期に作られたものだ。
「アイドル」というテーマの基本となる王道の曲であることから、当時の最も有名なアイドルグループを参考にしただろうことは想像に難くない。
明言はされていないものの、曲を聴いたイメージからおそらくAKB48のヘビーローテーションを参考にしただろうと推察できる。
アイカツ！で最も人気があると思われる曲で、YouTubeでの再生数が350万を超える化け物である。
いわゆる「メタル」であり、生粋のアイドルオタクである水島氏がBABYMETALを意識しただろうと考えることもできるが、
この曲はアイドルが歌うメタルというわけではなく、普通にかっこいいメタルなので、ベビメタが元ネタというには少し安易すぎる。
フルバージョンでは1分を超えるキーボード＆ギターソロがあり、「ベビメタみたいにしてください」という発注だけではこの曲は生まれていないのではないか。
実は、この曲については元ネタが明言されている。
「吸血鬼キャラを演じているユリカが歌う「硝子ドール」は特別にエッジのきいた楽曲ですが、あれも“NIGHTWISH”というオペラ風に歌いあげる女性ヴォーカルのヘヴィメタル・バンドを参考にしています。 」
Storytimeという曲を聴けば、なるほどと納得していただけるかと思う。
NIGHTWISH - Storytime (OFFICIAL MUSIC VIDEO)
（追記：DREAM THEATERっぽいとの意見もあるが、それは作曲の帆足圭吾氏がDREAM THEATERの大ファンである影響かと思われる）
DREAM THEATER - Forsaken (Official Music Video)
「最初のうちは「アヴリル・ラヴィーンのようなポップスで」とオーダーしても、どこか抑えてしまうので、「存分にお願いします」と言うのも僕の仕事になりました。 」
と発言している。つまり、アヴリルのようなポップスがアイカツ！の楽曲にあるのだということになるが、自分の考える限りではこの曲が最もアヴリル・ラヴィーンに近い。
もちろん没になった可能性もある。（例として、2年目に登場するDance in the rainという曲は実際にはかなり初期に制作されていた）
アイカツ！はアイドルがテーマであることもあり、実際のアイドルをイメージしたような曲がいくつか見られるのも特徴のひとつだ。
こちらの冬っぽい曲もおそらくそのひとつで、自分の考えでは広末涼子なのではないかと思う。
広末涼子の「MajiでKoiする5秒前」は、ケンタッキーのCMでいつのまにか冬のイメージになってしまった竹内まりやが作曲している。
ピチカート・ファイヴや初期のcapsuleをイメージするようなキュートな「渋谷系」っぽい曲である。
そのまま渋谷系っぽいオーダーで制作されたのかな、とも考えられるが、MVを見ると元ネタはなんとなく松浦亜弥の「ね〜え？」かもしれないと思った。
小さな箱の中で踊るというイメージが「ね〜え？」のMVと似ているからである。
しかも、「ね〜え？」は編曲がピチカート・ファイヴの小西康陽（作曲はつんく♂）ということもあり、渋谷系から外れてはいないのだ。
アニメの2番目のOPテーマで、主人公のいちごとあおいと蘭の3人によるユニット「ソレイユ」の持ち歌というのもあり人気の高い曲。
こちらも元ネタが明言されている。
kemuri良いわ〜！アイカツ！OP、ダイヤモンドハッピーはkemuriのPMAと戸松遥のQ＆Aリサイタルのようなイメージで制作したんす。両曲ポジティブで明るくて超盛り上がる名曲！Listening to “Here rise the sun again” by KEMURI ♫— 水島 精二 (@oichanmusi) 2013, 6月 20
KEMURI 「PMA (Positive Mental Attitude)」 Music Video (SKA BRAVO Version)
音ゲーにしてはかなりスローな曲で、おそらくアイカツ楽曲で最も遅いのでは。
Enya - Only Time (Official Music Video)
神崎美月、一ノ瀬かえで、藤堂ユリカの3人によるユニット「トライスター」の持ち歌。
アニメでは、トライスターの結成にあたってメンバー選抜オーディションが行われ、物語上の重要な転換点で登場する曲である。
STAR☆ANISとの雑談で「難易度の高い曲が歌いたい」って話が出て。ならばKalafinaのようなハモリが絡み合う感じがいいかなと。 - 水島精二
アイカツ！内に登場する近未来がテーマのブランド「フューチャリングガール」をイメージした曲。
いわゆるテクノポップな感じの曲なので、Perfumeがイメージなのかな？とは思うけれど、正直全くわからない。
2年目にもstranger alienというprism spiralの後継とでもいうべきテクノポップな曲が登場するが、単純にコンセプトから結果的にそうなっただけなのかもしれない。
（2015-11-19追記：prism spiralはどっちかっていうとハウスだろ、とお叱りを受けた。それは確かにそうかもしれない。stranger alienに引っ張られすぎて見失っていた。
大変申し訳ない。そして指摘とかほかにあったらどんどんしてほしい、というかむしろ自分より音楽の詳しい人にどんどん楽曲を分析してほしい）
これに関してはちょっと楽曲からズレた話になる。
かつて一世を風靡したレジェンドアイドルユニット「マスカレード」の代表曲となる1曲で、
アニメでは「懐メロライブガール・オーディション」で「懐メロの曲」として、いちごとあおいがカバーすることになる。
そして、マスカレードはピンクレディーをモチーフにしているユニットだと思われる。
僕的にはピンクレディー。それこそ社会現象を起こしたアイドルのイメージです。 - 木村隆一
僕のイメージでは、マスカレードがピンクレディーなので、キャンディーズくらい人気のライバルがいたんでしょう。 - 木村隆一
けれども、曲のイメージとしてはピンクレディーっぽい感じはとくにないので、そこまでは意識してはいなかったのだろう。
その代わりに、面白い仕掛けとして、この曲のメロディーはアニメの初期からBGMとして頻繁に使われており、女児にとっても「懐かしい」感じに聞こえるような工夫が為されている。
ドラマ「オシャレ怪盗スワロウテイル」のオーディションステージの曲。
ジャジーな曲で、怪盗がテーマなことからおそらくルパン三世を意識したところがあるのだと思われる。
「スワロウテイル」はかつてマスカレードが出演していたドラマだったのを考えると、「ペッパー警部」も念頭にあったのかもしれない。
余談だが、現在放映中のルパン三世新シリーズの監督はアイカツ！1年目にも深くかかわり、劇場版アイカツ！で監督も務めた矢野雄一郎さんである。
いわゆる「サンプリング」であり、クラシックの名曲が使われているのだ。
チャイコフスキー作曲「くるみ割り人形」より「行進曲」のメロディーが使われている。
はっきりと元ネタがあるわけではないが、「EDM」「ダブステップ」をキーワードに制作されたことが明言されている。
アイカツ！新OP/EDもお楽しみいただけましたけ〜！OPはEDMアイカツ流（笑）EDはカレンダーガール進化版を目指しました！OPを石濱さん/畑さんペア、EDを田中さん/こだまさんペアの鉄板チームで制作していただきました！最高です！CDの発売が楽しみ〜！#aikatsu— 水島 精二 (@oichanmusi) 2013, 10月 3
「KIRA☆Power」は、ダブステップという攻撃的なサウンドの音楽ジャンルを取り入れた、かなり攻めている曲です。
ダブステップのように旬なサウンドは、あとで遅れてやるとダサイので、「やれるうちにやっておこう」と思いました。 - 石濱翔
映画でいちごが出会うことになるシンガーソングライター・花音がいちごのために作った曲だ。
「アイドルとシンガー。異なるタイプの2人が出会い、新しい何かが生まれる。そんなストーリーを描きたかった。下敷きになっているのは、1980年代のアイドルの歴史の転換点です」
制作陣が、80年代と現代をつなぐイメージとして共有したのが、あの名曲「赤いスイートピー」だった。そして、当時トップアイドルへの階段を駆け上がっていた松田聖子さんが歌うこの楽曲こそ、木村さんの言う「アイドルの歴史の転換点」だった。
さらに、花音のイメージは赤いスイートピーの作曲者でもある松任谷(荒井)由実であるとも発言している。
アイカツ！3年目の2つ目のEDテーマであり、氷上スミレと黒沢凛が組むユニット「ダンシングディーヴァ」の持ち歌である。
「ダンシングディーヴァ」のイメージはSPEED。スミレが歌って、凛が横でダンスしている感じがカッコいいんじゃないかと思いました。 - 木村隆一
ではなぜ渋谷系なのか。それは、このステージが「レトロクローバー」というブランドをイメージしたものであるところにヒントがありそうである。
60～70年代のレトロフィーチャーなテイストをイメージしました。参考にしたのは、ツイッギー（英国の女優、モデル、歌手）のファッション。 - 中屋有貴（バンダイ・カード事業部）
華奢な体形からツイッギー（小枝）の愛称で呼ばれ、（藤原みやびが履くのをためらった）「ミニスカート」で話題になったツイッギーから着想を得ている。
そして、ツイッギーといえば連想するのがピチカート・ファイヴの「トゥイギー・トゥイギー」、繋がった。（ただのこじつけ）
U-MV053 - Pizzicato 5 - Twiggy Twiggy
大和撫子なブランド「桜色花伝」をイメージした曲で、とても和風。
近年よく耳にする「和ロック」な曲であるといっていいだろう。和ロックの出自についてはよくわからないが、「凛として咲く花の如く」「千本桜」などがよく挙げられるようだ。
何を意識して作られたのかはわからないけど、この多幸感がなんかすごい「っぽいな」と思ったので貼りたくなっただけです。
氷上スミレの持ち歌で、懐かしの歌謡曲を思わせるような不思議な1曲。
Winkっぽい。音楽理論とか全く詳しくなくてほとんどイメージでこじつけてるので公式ソースがあるの以外は参考程度に考えてください。
アイカツ！にはほかにもたくさん良い曲がある。ロカビリーな曲や映画音楽のような壮大なもの、80年代ディスコ風、渋谷系テイスト……とにかく幅が広い。
自分の好みの曲が必ずひとつは見つかるだろう、というくらいいろいろやっている。
そして、ときどき思わぬ人が楽曲提供をしていてびっくりすることもある。（NARASAKI、浜渦正志、ミト（クラムボン）、ナカノモリアヤコ、Kensuke ushioなど）
そんな楽曲を女児たちが聴いて成長すると思うと、音楽の未来は明るいなあと思ったりもする。
アイカツ！の○○みたいな曲ってなんていうジャンルなんだろう、と掘り下げたり、○○みたいな曲が作りたい、と作曲に手を出してみたり、
Free! Eternal Summer キャラクターソング
山崎宗介 "Just wanna know" の歌詞を英訳しました。
間違いや改善点などありましたらご指摘いただけると幸いです。
二次使用も可能です。使用する際はコメント欄にて一言いただけると嬉しいです。
I've translated the lyrics of "Free! Eternal Summer character song by Sousuke Yamazaki" "Just wanna know".
Translating Japanese, making rhyme in English, trying to sync translated lyrics with the music, etc, all at the same time were quite hard...lol
I'd appreciate any feed-backs like pointing out my mistakes or giving me some improvements.
Using my version of translated lyrics is always fine, but before u use it, plz let me know in the comment section herein below.
Plus I'd really love to hear if u guys sing this and upload it to YouTube/Tumbler/etc :P
somethin' in your eyes
is the reason movin' you
beyond the world 'bout to close off
on the path to the new picked hope
on the path to the new picked hope
let's go back to the same summer
just wanna know the reason
in the tie of relay
there'll be the feelin'
was I able to hide my face surprised?
you're always on your way, way
by sendin' off your runnin' back
(woah-woah) (woah-woah) (woah)
meddlin' even in the each way of thinkin'
wasn't a choice for us two (,was it?)
somethin' in your eyes
is the reason movin' you
someday I just wanna know the meanin' of "team"
the moment to be real is just in there
(woah-woah) (woah-woah) (woah-woah)
how deep was your heart healed
by the scenery showed by those guys?
you are questionin' to my empty heart
a tiny but brand new dream
things like "ties" are enough for me, right?
but seems like there're more than that
different from those days
(something I just wanna find)
kickin' the water straight
divin' to reach beyond the light
just a few meters ahead, ahead
just wanna know the reason
the tie of relay will tell me, me
somethin' in your eyes
is the reason movin' you
beyond the world 'bout to close (off)
on the path to the new picked hope, hope
the scenery in your eyes
(ah-ah) (woah)
2015/09/01時点での追試報告。
ttp://www.msi.com/support/mb/P67AC43_B3.html#down-bios
自分が入れたのは、
Release Date：2013-01-09のVersion：5.4
このverの更新にはUSBメモリが必須で、USBメモリ上でダウンロードファイルを展開して実行すると、再起動後USBメモリから起動してBIOS更新が行われた。
ちゃんとビデオカードが認識されたのでよかった。ちなみに交換先はR9-390。
あとbios更新後、win7の認証が入ったな。自分はクリックだけで済んだけど、環境によってはオペレータに電話することになるかも。
ご注文品
3920円
MONSTER エナジー 無糖 2ケース
7920円
228000円
合計239840円
↓注文内容確認はコチラ↓
ttp://tbhb.w06ewk1h.com/vghe045b314xwo-e266c420JRIC1106sxk51bfa751.M0BaDbF89zW
↓キャンセル等お問い合わせはこちら↓
ttp://tbhb.w06ewk1h.com/Ke2b6389aKjz/341BaF48UYj+B311cQPCE28CDFC+Zn3C8857bbn
Amozon.com
---
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: W06EWK1H.COM
Registrar: GMO INTERNET, INC. DBA ONAMAE.COM
Sponsoring Registrar IANA ID: 49
Whois Server: whois.discount-domain.com
Referral URL: http://www.onamae.com
Name Server: TS02.WINKL-WW.COM
Name Server: TS2.WINKL-WW.COM
Status: ok http://www.icann.org/epp#OK
>>> Last update of whois database: Tue, 11 Aug 2015 15:07:03 GMT <<<
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
For more information on Whois status codes, please visit
https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en.
Domain Name: w06ewk1h.com
Registry Domain ID: 1916126422_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.discount-domain.com
Registrar URL: http://www.onamae.com
Updated Date: 2015-07-10 14:03:18
Creation Date: 2015-04-03 08:56:56.0
Registrar Registration Expiration Date: 2016-04-03 08:56:55.0
Registrar Abuse Contact Email: abuse@gmo.jp
Registrar Abuse Contact Phone: +81.337709199
Domain Status: ACTIVE
Registry Registrant ID:
Registrant Name: eiji ootani
Registrant Organization: eiji ootani
Registrant Street1: 3-14-12 Ozukanishi
Registrant Street2:
Registrant City: Asaminami-ku Hiroshima-shi
Registrant State/Province: Hiroshima
Registrant Postal Code: 731-3167
Registrant Country: JP
Registrant Phone: 080-1359-5214
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: ozmsasssss@yahoo.co.jp
Registry Admin ID:
Admin Name: eiji ootani
Admin Organization: eiji ootani
Admin Street1: 3-14-12 Ozukanishi
Admin Street2:
Admin City: Asaminami-ku Hiroshima-shi
Admin State/Province: Hiroshima
Admin Postal Code: 731-3167
Admin Country: JP
Admin Phone: 080-1359-5214
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: ozmsasssss@yahoo.co.jp
Registry Tech ID:
Tech Organization: GMO Internet Inc.
Tech Street1: 26-1 Sakuragaoka-cho
Tech Street2: Cerulean Tower 11F
Tech City: Shibuya-ku
Tech Country: JP
Tech Phone: 03-5456-2555
Tech Phone Ext:
Tech Fax: 03-5456-2556
Tech Fax Ext:
Tech Email: admin@onamae.com
Name Server: ts2.winkl-ww.com
Name Server: ts02.winkl-ww.com
DNSSEC: Unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2015-07-10 14:03:18 <<<
なろうにかなり女性向けテンプレ作品が増えてきて、鬱陶しくなってきたからタイトルで引っ掛けてある程度フィルタするようにしてみた。
タグで切るか迷ったけど、テンプレをばさっと切るならタイトルのほうかなと。
素人でもこういうのが簡単に作れるようになるんだから、最近のブラウザのDeveloperToolとjQueryはすごいと思う。
// ==UserScript== // @name narou rank ng // @namespace http://use.i.E.your.homepage/ // @version 0.1 // @description enter something useful // @match http://yomou.syosetu.com/rank/list/* // @copyright 2012+, You // ==/UserScript== (function($){ // ここにNGワードを記載する var ngwords=["か[？\?]","令嬢","婚","ない","せん","王子","姫","乙女"]; $("div.rank_h").each(function(){ for ( key in ngwords){ reg = new RegExp(ngwords[key]); if( $("[id^=best]",this).html().match(reg) ){ $(this).css("display","none"); $(this).next().css("display","none"); } } }); })(jQuery);
こういう感じ http://i.imgur.com/LCbUGwe.png
// ==UserScript== // @name metaBKM // @include http://b.hatena.ne.jp/entry/* // @version 1 // @grant none // ==/UserScript== (function(){ function make(){ var list = document.querySelectorAll('#public-bookmarks .bookmark-list > li'); for(var i = 0;i < list.length;i++){ var commentLink = list[i].querySelector('.user-comment-link'); if(!commentLink) {continue;} var bkmImg = 'http://b.hatena.ne.jp/entry/image/' + commentLink.href; var img = document.createElement('img'); var a = document.createElement('a'); img.setAttribute('src',bkmImg); a.setAttribute('href','http://b.hatena.ne.jp/entry/' + commentLink.href.replace(/.*?\/\//,'')); a.appendChild(img); var parentElm = list[i].querySelector('span'); parentElm.insertBefore(a, parentElm.children[2]); } } function check(){ if(document.querySelector('.commentlist-loading')){ return false; } else { return true; } } var timer = setInterval(function(){ if(check()) { console.log(check()); make(); clearInterval(timer); } }, 1000); })();
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）
https://chrome.google.com/webstore/detail/masudalert/clkiaalhgfhgcllngddndbghoaahhnfa
とりあえず自分が投稿した日記にトラバやブクマがついたらわかるようになってます。
現時点で申請後にいくつか修正したので、バージョン1.1を申請してます。
できればバージョンを見て1.1であることを確認してからいれてください。
仕様は下記のような感じ
なんかフィードバックもらえると嬉しいです。
http://anond.hatelabo.jp/20150201190857
--
（追記）：いろいろトラバやブクマありがとうございます。
火狐版は簡単そうならやろうかと調べてみました。どうやらFxはバッジないんですね・・・。
メールみたいに常にページを開いておいてもらって、タブで通知するとかはアリかもしれませんが、自分があまりFx使わないので正解がわかりません。
Github にソースもあげたので誰かがやってくれるのを期待します。
https://github.com/katsuren/masudalert
--
（追記2）
バッジがあがってきても、どの記事なのか、トラバなのかブクマなのかわかりづらかったので、
リンクに見出しとトラバ/ブクマ数を表示するようにしておきました。
--
（追記3）
荒川マラソンが前代未聞の理由で開催中止に → 返金の連絡先が『振り込め詐欺に利用された要注意住所』と一致して大炎上ｗｗｗｗｗ
http://www.kimasoku.com/archives/7982053.html
http://fields.canpan.info/organization/detail/1026339646
Content-Type: application/pdf Creation-Date: 2014-11-20T10:23:34Z Last-Modified: 2014-11-20T10:23:34Z Last-Save-Date: 2014-11-20T10:23:34Z created: Thu Nov 20 19:23:34 JST 2014 date: 2014-11-20T10:23:34Z dc:format: application/pdf; version=1.5 dcterms:created: 2014-11-20T10:23:34Z dcterms:modified: 2014-11-20T10:23:34Z meta:creation-date: 2014-11-20T10:23:34Z meta:save-date: 2014-11-20T10:23:34Z modified: 2014-11-20T10:23:34Z pdf:PDFVersion: 1.5 pdf:encrypted: false producer: Microsoft® Excel® 2010 xmp:CreatorTool: Microsoft® Excel® 2010 xmpTPg:NPages: 2
http://hill.xsrv.jp/3minute-essence/nomi-479
Domain Name:ATDAWN.TOKYO Domain ID:GMOREGISTRY-DO186691 WHOIS Server:whois.nic.tokyo Referral URL:http://nic.tokyo Updated Date:2014-11-28T03:59:43.0Z Creation date:2014-09-26T13:07:28.0Z Registry Expiry Date:2015-09-26T23:59:59.0Z Sponsoring Registrar:GMO Internet, Inc. Sponsoring Registrar IANA ID:49 Domain Status:ok http://www.icann.org/epp#ok Registrant ID:15981FC9FAA55F Registrant Name:MORIYO MOMOHRA Registrant Organization:MORIYO MOMOHRA Registrant Street:Saitoaominami6-8-3-102 Registrant City:Mino-shi Registrant State/Province:Osaka Registrant Postal Code:562-0028 Registrant Country:JP Registrant Phone:+81.08085010056 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email:domain@onamae-server.com ...
Domain Information: [ドメイン情報] [Domain Name] POTUS.JP [登録者名] 桃原 守代 [Registrant] MORIYO MOMOHRA [Name Server] dns02.gmoserver.jp [Name Server] dns01.gmoserver.jp [Signing Key] [登録年月日] 2014/11/13 [有効期限] 2015/11/30 [状態] Active [最終更新] 2014/11/13 01:39:04 (JST) Contact Information: [公開連絡窓口] [名前] 桃原 守代 [Name] MORIYO MOMOHRA [Email] munokokoroha@gmail.com [Web Page] [郵便番号] 562-0028 [住所] 大阪府箕面市 彩都粟生南6-8-3-102 [Postal Address] Mino-shi Saitoaominami6-8-3-102 [電話番号] 080-8501-0056 [FAX番号]
http://v.hitomachi-kyoto.genki365.net/gnkk14/mypage/mypage_group_info.php?gid=G0000921
http://ark.npo-marathon.jp.net/service.html
Author: FJ-USER Content-Length: 464992 Content-Type: application/pdf Creation-Date: 2014-10-02T02:37:57Z Last-Modified: 2014-10-02T02:37:57Z Last-Save-Date: 2014-10-02T02:37:57Z created: Thu Oct 02 11:37:57 JST 2014 creator: FJ-USER date: 2014-10-02T02:37:57Z dc:creator: FJ-USER dc:format: application/pdf; version=1.5 dcterms:created: 2014-10-02T02:37:57Z dcterms:modified: 2014-10-02T02:37:57Z meta:author: FJ-USER meta:creation-date: 2014-10-02T02:37:57Z meta:save-date: 2014-10-02T02:37:57Z modified: 2014-10-02T02:37:57Z pdf:PDFVersion: 1.5 pdf:encrypted: false producer: Microsoft® Excel® 2010 resourceName: santa.pdf xmp:CreatorTool: Microsoft® Excel® 2010 xmpTPg:NPages: 4
http://anond.hatelabo.jp/20140925002959 に続き、準メジャーブラウザとその他のブラウザの現状。
Firefox派生のブラウザは全く使ったことがないので、省略。
Chromium派生のブラウザは(レンダリングエンジンの性能に関しては)どれもChromeを超えられる存在にはなりえないので、とりあえずOperaだけ。
かつては独自のレンダリングエンジン(Presto)を載せ、独自機能を数多く搭載し、一部の人から「Opera最強伝説」と絶賛されていたブラウザ。
Web標準にいち早く準拠させた一方で、IEなどの互換性も配慮していたようだ。
しかし、HTML5やCSS3の準拠度は後発のWebKitエンジン搭載ブラウザに押されてしまった。
そのせいなのか、もしくはPCが廃れそうだから独自レンダリングエンジンに投資するのは無駄と考えたかどうかは不明だが、PC版はBlinkエンジンを採用することになってしまった。
Blinkエンジンを手に入れることによって、得られたのはHTML5の準拠度UPとブラウジングスピードと安定度。失ったのは、マウスジェスチャのカスタマイズやサイドバーといった今までのメリットだった独特のUI。ただのChromium派生ブラウザになってしまった。
バージョンアップタイミングはChromiumと同期するためバージョンアップ頻度が高くなり、現在では24まで上がっている。
それでもなお、独自エンジンを搭載した最終バージョンを使い続けるユーザーが少なからずいるようだ。
国産ブラウザ代表。かつては、IEコンポーネントなタブブラウザの定番だった(少なくとも国内ではそうだった)。
最近、Version 5系が出て、何を思ったのか不明だがバージョンが6まで上がった。5からは文字がボケボケ滑らかになったり、タブがページサムネイルになったり、Blinkエンジン専用になったり、4でできたカスタマイズができない、6で「お気にタブ」というネーミングセンスを疑う新機能など、ある意味で大化けしてしまった。
一方で、2系や4系のバージョンアップは継続するようだ。実際はこれらの処遇を決めかねているのではないだろうか。
2, 4, 6の中で不満の少ないのを模索しているようにも見える。
ちなみに、BlinkエンジンはChromiumをいじってChromiumのタブとかボタンとかを隠しているだけ。このおかげで、Chromeの拡張機能がそのまま使えるようだ。Blinkのプロセスを単独で実行させれば素のChromiumが起動する。4系で確認。6系は未確認。
全バージョンに共通して言えることは、起動が遅い、UIがごちゃごちゃしすぎ。機能に振り回されている。さらに、Chromiumのバグまで引きずるダメアプリ。
国産ブラウザ代表。昔は軽量だったのに、「世界初 トリプルエンジン搭載」だとかなんとか言ってるせいで、いつの間にか重量級ブラウザになってしまった。WebKitエンジンの更新が止まり、セキュリティ的にやばいんじゃないかと言われ続けたが、最近になってようやく更新し始めた模様。
ブラウザ本体にAds by Lunascapeと広告を載せる実験をした実績あり。
感想はSleipnirと同じ。どちらかというと、レンダリングエンジン自体が重いせいなのかもしれない。せっかく3種類のレンダリングエンジンが使えるといっても、重いのでは全く意味がない。
というか、Sleipnir4 - 安定感 + Geckoエンジン = Lunascapeという数式が頭をよぎる。
レンダリングエンジンをどう改造しているかわからないが、HTML5testではなぜかChromeよりスコアが高い(正式リリース前のバージョンだが)。
最近はChromeより30%軽いとか言っているMxNitroを作ったらしいが、まだベータ版らしくブラウザとしての基本機能が足りない。Chrome拡張機能が使えないので、Chromeと同列に扱うのは反則だと思う。
30%軽い理由の1つは、Chromiumの組み込み向けフレームワークであるCEF(Chromium Embedded Framework)ベースと推測されるため。これは間違っているかもしれない。
それにしても、UIが全体的にのっぺりな平行四辺形なのはどうなんだろうか・・・。
国産はごちゃごちゃしたものばかり作るなよと言いたいところだ。ユーザーの要望に安易に答えすぎた結果なんだろうか。技術的には中国産ブラウザに負けているような気がするが、気のせいだろうか。
Operaが独自レンダリングエンジンを止めてChromium派生になってしまった上にスマートフォンやらタブレットやらが普及してしまった以上、もうPC向けに力を入れる時代ではなくなったのかな・・・。
等位 Coordinating Conjunctions
相関 Correlative Conjunctions
お悔やみの言葉
会話一般
（語学学習サイト個人的リンクメモ / Lists of Language Learning Links）
http://anond.hatelabo.jp/20090101193230
