Showing posts with label Web. Show all posts
Showing posts with label Web. Show all posts

2016-07-17

ダイヤルQ2風の電話番号でInstagramやGoogleやMicrosoftから金をむしりとれる脆弱性

セキュリティ研究者が、とても興味深い脆弱性を報告して報奨金をもらった記事が上がっている。

How I Could Steal Money from Instagram, Google and Microsoft – Arne Swinnen's Security Blog

プレミアムナンバーという電話上のサービスがある。これは一時期日本で行われていたダイヤルQ2と同等の仕組みを持つサービスで、プレミアムナンバーという電話番号にかけた電話の通話料は、通常より高い。通話料の差分は、電話サービスの提供元に支払われる。

ダイヤルQ2は電話越しに何らかのサービスを提供して、電話料金で利用料を徴収できる、手軽な仕組みだった。その利用例は、投資顧問、アダルト、占い、人生相談、義援金、ダイヤルアップISPなどに利用されていた。ダイヤルQ2自体は2014年に終わったが、海外ではまだ同等の仕組みをもつサービスが残っていて、一般に、プレミアム通話料金率電話番号と呼ばれている。

ところで、一部のWebサイトは、ユーザーが指定した電話番号に自動的に電話をかける機能を提供している。その理由は例えば以下のようなものだ。

  • ユーザーが人間であることを確かめるCAPTCHA文字列を合成音声で伝え、その文字列をWebサイトに入力させるため
  • 二段階認証のセキュリティトークンとなる文字列を合成音声で伝え、その文字列をWebサイトに入力させるため
  • アカウントに登録した電話番号が本人のものであることを確かめるため

それ以外にも理由はあるかもしれないが、ユーザーの入力した電話番号に自動的に電話をかけるという機能は、もし電話番号としてプレミアム番号が与えられた場合、課金される脆弱性がある。この研究者はこの脆弱性を研究し、それぞれ報告した。

Instagram:アカウントへの電話番号のひも付け

Instagramはアカウントに電話番号をひも付けて検索で見つけさせることができるが、その電話番号に対してSMSで文字列を飛ばし、入力させる。もし、文字列が3分以内に入力されない場合、カリフォルニアから電話をかける。通話時間は17秒だ。

電話番号のひも付けリクエストはレートリミットされているので30秒に一回しか送れない。しかし、Instagramはどんな電話番号にでも電話をかけてくれる。たとえば、eurocall24.comでは0.06ポンド/分の割合で課金できる。

したがって、計算をすると、30分で1ポンド、一日で48ポンド、1年で17280ポンド、1アカウントとプレミアム電話番号で稼げることになる。とはいえ、攻撃者は100アカウントほど用意して攻撃速度を100倍にできる。すなわち、一日で4800ポンド、一ヶ月で144000ポンド、一年で1728000ポンドだ。

また、複数のアカウントで一つのプレミアム電話番号を使いまわせる。

Facebookに連絡したところ、これは想定の範囲内であり、対策も講じてあり、許容範囲内のリスクであるとの返答を得た。手で100アカウントをつくって自動化した攻撃をするのは簡単であると重ねて連絡をとったところ、最終的に、2000ドルの報奨金と、慈善団体への4000ドルの寄付を得た。

Googleの場合: 二段階認証

Googleは二段階認証のための6桁のセキュリティトークンを、ユーザーが指定した電話番号に伝えてくる。電話番号はプレミアム番号も受け付ける。妥当なセキュリティトークンを入力しないと、数回ほど電話を試みたあとに、ブロックされる。

しかし、eurocall24.comは電話のSIPサーバーへの転送をサポートしており、SIPクライアント経由で電話内容を聞くことができる。

すると、あとは音声認識してトークンを入力してログインするまでの工程を自動化すればいいだけだ。

しかし、Googleはログインが試みられてさえいればよく、ログインが成功したかどうかまでは判定していない。電話がかかってきたあとにログイン試行さえ行われていればブロックはされない。そのため、音声認識の部分は省略でき、電話がかかってきたらそのアカウントにログインを試みるスクリプトを書いて自動化した。

電話は、一時間あたり10回に制限されているようだ。一回あたりの通話時間は約35秒だ。したがって、一日に12ポンド、一ヶ月で360ポンド、一年で4320ポンドせしめることができる。しかし、攻撃者は100アカウントを使うことで攻撃速度を100倍できる。一日で1200ポンド、一ヶ月で36000ポンド、一年で432000ポンドだ。Googleの場合は、プレミアム番号もアカウントごとにユニークなものが必要とされる。

Googleにバグ報告すると、「その脆弱性を使って[email protected]に侵入してみせよ」と返事が来た。そのような脆弱性ではないことを伝えると、「先のメールは手違いで送られたものである」と返事が来た。その後、「この問題は些細なものでセキュリティ上の懸念はほぼなく、バグ報酬に値しない」というメールが来た。問題が存在することをさらに解説すると、「先のメールは自動的に送信されたもので、送るべきではなかった。まだ調べている」と返事が来た。ただし、「金はユーザーデータに比べれば大した問題ではない。金は重要であるには違いないが、損失分を取り戻すのは、ユーザーの信頼を取り戻すことに比べれば、遥かに容易である。皮肉なことは私も認めるが、ユーザーにとっては理的だw」とのコメントもあった。

Googleの最終的な回答としては、「我々は対策を講じてあるが、電話の仕組み上、完全に防ぐことは難しい。大量の金を引き出す試みは、対策により阻止される。そのため、我々はこの報告に対して報奨金を支払わない判断をした。先に述べた如く、Googleの金銭的損失はユーザーのセキュリティほど重要ではない。とはいえ、取り上げるには値する報告なので、殿堂入りリストには載せておく」

Microsoftの場合:Office 365の体験版の登録

Office 365の体験版の登録にあたって、電話番号を入力してMicrosoftに電話をかけさせることができる。電話番号にはプレミアム番号も受け付ける。番号は7回の登録失敗でブロックされる。

しかし、このブロックをすり抜ける2つの方法が発見された。

電話番号の前にゼロを追加する。ゼロは最大18個追加することができる。また、ゼロの代わりにプレミアム番号の国番号を追加することもできる。これにより、以下の数式の回数のブロック回避が行える

\[\sum_{n=1}^{18}n=171\]

トータルの回数は171+1で172通りだ。

電話番号の末尾に最大4桁のランダムな番号を追加する。

\[\sum_{i=0}^{4}10^i=11111\]

するとトータルの回数は

\[(172 \times 11111) \times 7 = {13377644} {電話回数/プレミアム番号} \]

一回の通話には約23秒かかる。計算を簡単にするために20秒にしよう。プレミアム番号の稼ぎは1分あたり0.15ユーロだ。

\[(13377644/3) \times 0.15 = 668882 ユーロ/プレミアム番号\]

Microsoftは同一の電話番号に対する並列した電話を認めている。攻撃者はこの手法を自動化すること多額の金を掠め取れる。

Microsoftにバグ報告したところ、電話番号の前と後に桁を追加してブロックを回避できる仕様が修正された。報奨金として最小の額である500ドルが支払われた。

Microsoftの回答によれば、電話サービスはアウトソースしているため、Microsoft自体には被害はないが、報奨金を支払う判断をしたそうだ。

「これは確かに脆弱性で、しかもうまいものだ。そのため我々は報奨金を支払う判断をした。セキュリティの立場から言えば、我々は顧客を守ることに重点を置いている。この脆弱性は報奨金に値するし修正に値するが、顧客のデータに対するリスクはない。我々は常に、セキュリティ研究者に、我々がユーザーを守るための役に立つような研究をしてくれることを依頼しているが、この場合、守られたのは我々と我々の協力会社のようだ。」

この脆弱性は大したものだ。

2016-03-17

Twitterでつぶやかれている絵文字のリアルタイムなトラッカー

emojitracker: realtime emoji use on twitter

Twitterでつぶやかれている絵文字のリアルタイムなトラッカーがある。

このサービスは近々、Twitterの歴史的に認められていた上限なしAPIアクセスの廃止に伴い、終わる見込みだそうだ。

U+1F647 PERSON BOWING DEEPLY 🙇 — Medium

面白いし参考になるので、今のうちに眺めておこう。

ちなみに、この絵文字トラッカーはユニコードコンソーシアムにおいて絵文字の実際の利用需要の参考に引用されたこともある。

Twitterがまだおおらかな頃、このような面白いサービスを作るために、APIへの上限なしアクセス権を気軽にホイホイ発行していたのだが、Twitterからのメールでの連絡で、近々そのような上限なしアクセスを廃止するので、商用アクセスAPIであるGnipに移行するか諦めろという言われたと報告している。残念なことだ。

Hacker NewsではTwitter社員だと自称する人間が今回の決定について適切な利用法であれば例外的措置もあり交渉も可能であり、我々に交渉もせずに公にしたのは残念であると言い訳がましいことを書き込んでいるが、公開されたメールの文面をみれば、商用APIに移行するか諦めろという最終通告にしか読めないが、公開されているメールの文面は間違っているのか? いかにも言い訳がましいと反論されている。

2015-12-20

HTTPステータスコード451(政治的な検閲)が正式に承認される

mnot’s blog: Why 451?

draft-ietf-httpbis-legally-restricted-status-04

HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。

元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。

451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。

このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。

このステータスコードは、法律や一般大衆の雰囲気がサーバーの運営に影響をもたらした時に透明性を高める情報開示のために使うことができる。この透明性はオペレーターとエンドユーザーにとって有益なものとすることができる。

RFC4924はインターネットの透明性を抑圧する勢力について考察している。その勢力にはコンテンツへのアクセスを禁止する法的な介入が含まれることは明らかである。参照先のドキュメントによる記述や、RFC4084のセクション4がしめす通り、そのような検閲の事実は公開されるべきである。

HTTPステータスコード451の採用には、結構な議論があったらしい。もともと提案したTim Brayと同志の者は、オンライン上における検閲の事実は開示すべきであると考えていた。403は単に「禁止されている」という意味だけで、「法的な理由により閲覧させることができない」という意味はない。

当初、IESGでは反対する委員も多かったようだ。というのも、HTTPステータスコードは限りある名前空間だからだ。400から499までしかなく、全てに意味が割り当てられてしまったあとは、もうどうしようもない。

とはいえ、賛同する委員も多く、また検閲事実の収集を自動化したいという声もあったため、採用に至った。

451はどのように使われるのか。すべての検閲が451を使うことは期待できない。451はネットワーク検閲フィルターの役割を果たすファイヤーウォールが使うことも考えられるが、おそらく現実的には、発信元のWebサーバーが使うだろう。Github, Twitter, Facebook, GoogleといったWebサイトはしばしば検閲を要求されている。

抑圧的な国家は、検閲されている事実をも検閲するため、451を返すこと自体が検閲されるだろう。その場合、市民は国家が自国民を検閲しているという強力なメッセージを受け取ることになるだろう。

2015-06-29

そんなにセキュアではないお粗末なNoScriptのホワイトリスト(修正済み)

The NoScript Misnomer - Why should I trust vjs.zendcdn.net? | The Hacker Blog

「俺の環境はNoScriptを入れてるからセキュアだぜ」などと豪語する勘違い野郎に冷水を浴びせるために、デモ可能なNoScriptを迂回する方法を探していた人間が、NoScriptのお粗末なホワイトリスト指定を発見したそうだ。

NoScriptはデフォルトで、非常に有名なドメイン名(CDN、超有名Webサイト等)をホワイトリストに入れている。

しかし、このドメイン名をホワイトリストは、サブドメインもホワイトリストに入ってしまうという問題がある。もしサブドメインとページ内容を第三者が自由に作成できるようなドメインが入っていれば、信頼が破綻する。

さて、リンク先の著者は、まずホワイトリストに入っているドメインのWebサイトのXSS脆弱性を探そうと考えた。ところが、それをするまでもなく、ある重大な発見をした。

なんと、ホワイトリストに入っているドメイン名の一つ、zendcdn.netが誰にも所有されることなく空いていたのだ。

とりあえず同ドメイン名を10.69ドルで購入してJavaScriptを仕込んでみると、見事NoScriptが迂回できた。

しかし何故誰も所有していないドメイン名がホワイトリスト入りされているのか。

どうやら、ユーザーが有名なCDNをホワイトリストに追加するようNoScriptに要請したようだ。

InformAction Forums • View topic - JavaScript CDNs to add to whitelist

NoScript開発者のGiorgio Maoneに、この脆弱性について連絡を撮ったところ、彼の返事と対応は極めて迅速であり、一時間もしないうちに修正パッチがサイト上に上がり、2日後にはアップデートが全NoScriptユーザーに配布されたという。

リンク先の人間は、NoScriptユーザーはホワイトリストを確認し、自分が信頼しないドメインは取り除くべきであると書いている。

2014-10-18

XNGという新しいアニメーション画像フォーマット

[Phoronix] GNOME Developer Comes Up With New Animated Image Format

XNG: GIFs, but better, and also magical | Clean Rinse

GNOME開発者のJasper St. Pierreが、GIFに変わる新しいアニメーションフォーマットを作り出したそうだ。

ただ・・・作ったというか、ハックしたというか。

この新しいフォーマットは、なんとブラウザーのvideoやcanvas要素を使うものではなく、もちろんJavaScriptのライブラリを使う必要もない、単にimg要素のsrc属性に指定するだけで既存のブラウザー上で動作する。<img src="foobar.xng">「魔法だ」

原理としては、ファイルの中身はSVGファイルで、BASE64エンコードされたJPEG画像が入っている。

まあ、面白いといえば面白いが、普通にvideo要素を使ったほうがいいのではないかと思う。

2014-08-29

あるポルノサイトのアクセス解析によるOSシェア率によれば、GNU/Linuxユーザーは1.7%

この記事は大真面目に書いた。

[リンク先に危険な画像はない] OS Battle – Porn by the Platform

Phoronixに載っていて知ったのだが、有名なポルノサイトであるpornhubが、Webサイト上のトラフィックのOSに特化した解析結果をブログで大真面目に公開している。その例に習って、筆者も大真面目に内容の紹介と、大真面目な感想を書こうと思う。

まず、デスクトップOSのシェア率は、Windowsが85.5%、Macが10.9%、GNU/Linuxが1.7%だそうだ。

いかにWindows優位な市場とはいえ、Macのシェア率が世間一般より低いように思われる。Macユーザーはあまりポルノを必要としないのであろう。

Windowsの具体的なバージョンは、Windows 7が一番多く、ついでWindows XPである。なんと、Windows NTやWindows 2000を使っているものもいるらしい。また、月数千人は、Windows 95や98の利用者がいるそうだ。

モバイルOSのシェア率は、Androidが48.34%で、ついでiOSが40.60%だそうだ。

これも、実際の市場のシェア率とは異なり、iOSが低すぎるように思う。やはりiOSの利用者はあまりポルノ閲覧を必要としないに違いない。

タブレットOSでは、iOSが圧倒的なシェアを占めている。

これはどうみるべきだろう。Apple製品のユーザーはあまりポルノ閲覧を必要としないのではないかと思っていたが、Appleのタブレットユーザーはポルノを閲覧するらしい。あるいは、iPadの市場シェアが多すぎるためにこうなったのだろうか。

ゲーム機のシェア率もまとめられている。今のゲーム機はブラウザーを搭載している。ブラウザーを搭載しているということは、当然pornhubを閲覧できる。

ゲーム機のシェア率は、PlaystationとXBoxが二強である。Nintendo Wiiでポルノを閲覧する人はあまりいないらしい。

人気の検索クエリーで面白いのは、GNU/Linuxユーザーの検索クエリーは、インド女優の名前やインド人が多いらしい。なぜかというと、GNU/Linuxの利用者のかなりがインド人だからである。

OSごとの国別の閲覧者は、WindowsとMacではアメリカ合衆国が圧倒的であるが、GNU/Linuxでは、二位に圧倒的にインドが上がってくる。どうやら、インドのポルノ閲覧者におけるGNU/Linuxの普及率が相当に高いらしい。

ソースがソースなだけに、なかなか興味深いアクセス解析結果だ。

ちなみに、ここ一ヶ月のこの本の虫ブログ閲覧者のOSシェアは、Windowsが46.74%、iOSが20.58%、Macが13.40%、Androidが12.14%、GNU/Linuxが6.53%である。6割がデスクトップ、3割がスマートフォン、タブレットは4%ほどだ。

2013-12-21

Google、Chrome Web Storeから多目的の拡張を禁止する

GoogleはChromium Blogで、Chrome Web Storeから、複数の目的を有する拡張を禁止する発表を出した。

Chromium Blog: Keeping Chrome Extensions Simple

本日、我々はChrome Web Storeポリシーの変更を告知する。Chrome Web Storeの・拡張は、必ず、狭く簡単に理解できる単一の目的を有さなければならない。これはChrome拡張システムの意図であるが、すべての拡張はこの理想に従っていない。奴ら、多目的拡張(mutli-purpose extensions)は、ブラウザーのUIをごちゃごちゃとさせ、Webブラウジングを愚鈍にし、時には悲惨なことになる。我々はこの問題を修正し、ユーザーにブラウザーの支配力を与えるために、今回のポリシー変更を行った。

簡潔で高速なブラウジング体験は、Chromeのはじめからの、基本理念である。簡潔性は我々にとって重要なことで、その理由は、ブラウザーはとても複雑になり、重量級のユーザーインターフェース(俗に"chrome"(ブリキ化)と呼ばれている)を持っているからだ。この複雑なUIは、ブラウザーのそもそもの存在理由である、ページ内のコンテンツから注意を空してしまう。"Chrome"という名前は、我々は「コンテンツ」に注力したいというこの理念からきている。

現在、ブラウザーの重量化に強力に貢献しているのは、万能ツールバーのような拡張だ。ユーザーが複数のそのようなツールバーをインストールした結果は、悲惨なものになる。

我々の簡潔性の理念を維持するため、我々は異なるアプローチをとることを決定した。Chrome拡張は自然に簡潔で単一の目的用になり、単一のbrowser actionか単一のpage actionという、単一の可視UI「サーフェイス」しかサポートされない。ツールバーは設計上サポートされず、ユーザーはこれによりブラウザーに追加する機能について一層のコントロールを得ることとなる。

残念ながら、一部で、このような設計を技術的に矯正できない。 content scriptにより、拡張の開発者はページに対する完全なコントロールを得、結果として、どんなUIでも実現できる。たとえ、ツールバーをページに作成するような機能であったとしてもだ。他には、content scriptを使って、多数の機能がごちゃまぜになったような、どのような拡張とも分類しがたいものをつくりだす。多くの場合、Chrome Web Storeは、ある拡張が変な挙動をしていることを、低評価により示しているが、そうでもない場合もある。

なお悪いことに、拡張がローカルのコンピューターに、間接的に読み込まれた時(たとえば、他のインストールしたソフトウェアに同梱されていたなど)、ユーザーはChrome Web Storeの恩恵を受けることができない、そのため、望まない機能や低評価の拡張のインストールにユーザーが同意したことに気が付かないことがある。

このため、当初の単一目的の設計を強制させるため、Chrome Web Storeのポリシーを変更した。我々は、これにより既存の拡張に大きな変更が必要になることを承知している。一部の拡張は、複数の拡張に分離する必要があるだろう。開発者は、我々が追加した、拡張への送金方法を簡単にする方法に変えて、別の方法による課金方法に切り替えないといけないだろう。これらの変更には実装に少し時間がかかるため、2014年6月まで強制を見送る。新しい拡張については、このポリシーは直ちに適用される。

Googleもだいぶ邪悪になってきたようだ。ある拡張がどう実装されようとどうでもいいわけで、これはユーザーにコントロールを与えるなどというのは詐欺もいいところだ。問題の本質は、Windowsにまともなパッケージマネージャーがないことに起因すると思うのだが。

Google announces ban on "multi-purpose" Chrome extensions | ZDNet

Google announces ban on "multi-purpose" Chrome extensions | Hacker News

2013-12-13

JavaScriptへVimを移植

Vim.js - JavaScript port of Vim

なんと、JavaScriptへVimを移植したのだそうだ。準備に時間がかかり、さらに反応も悪いが、たしかにこれはVimだ。いや、Vimそのものだ。

Hacker Newsでは、さっそく、Atwordの法則を引用するものがいる。Atwordの法則、「JavaScriptで書かれ得るプログラムは、いずれJavaScriptで書かれる。」

この法則は、Tim Berners-Leeの the Principle of Least Powerをもとにしている。Tim Berners-Leeは、WebでJavaScriptのような貧弱なプログラミング言語が使われていることを大変喜んでいる。なぜならば、JavaScriptは比較的簡単に解釈できるからだ。そのため、データやプログラムは、他人にも比較的簡単に処理できる。これがもし、Javaアプレットとか、Flashなどで書かれていたならば、なるほど、確かに見た目はいいかもしれないが、とても他人にとって使いづらいデータになってしまう。

Design Issues for the World Wide Web

2013-10-30

Dellのラップトップ6430uが、猫の小便みたいな臭いを発するとの報告多数

New 6430u smells awful - Laptop General Hardware Forum - Laptop - Dell Community

Dellの新品のラップトップ、6430uを購入したユーザーの多くが、ラップトップのキーボードから猫の小便のような臭いがすると、Dellのサポートフォーラムで苦情を出している。いくつか紹介すると

で、数週間前に、新品のLattitude 6430uを仕事用に買ったんだけどさ。

コンピューター自体は問題ないんだけどさ、でもどうも、近所の猫達のトイレ箱を全部集めたような臭いがするんだよね。マジで最悪。

どうも臭いはキーボードからきてるらしい。

誰かこの臭いを取り除く方法を知らないか?

同じだ。はじめは、うちの猫がやらかしたのかと思ってたんだが、なにか調子がおかしかったので交換した後、交換品もやっぱり同じ問題がある。ひどく臭うので、仕事にこれでお客さんの対応をするのは恥ずかしい。

以下、同じような報告が続く。報告は、新品のラップトップのキーボードから、猫の小便のような臭いがするという点で一致している。

フォーラムでは、Dellのサポート要因らしきアカウントが、キーボードの洗浄方法について説明しているが、ユーザーはいくら洗浄しても臭いは取れないと報告している。

そして、とうとうサポート要因らしきアカウントから、以下のような書き込みが出た。

この問題によりお客様にご迷惑をお掛けしたことをお詫び申し上げます。この問題は、数週間前に解決され、いずれ技術者が問題の原因と解決方法を公開する予定となっております。弊社はただいま、この問題の原因の分析と解決の最終的な確認を行っており、近いうちに結論が出ることを予定しております。その後、公式に案内させていただきます。現在、確認済みのことをいくつか申し上げます。

  • 臭いは製造工程上の問題であり、現在ではすでに変更されております
  • 臭いは生物的な混入によるものではございません
  • 臭いに健康上の問題はございません

今からご注文いただくE6430uには、この問題はございません。

ただいま弊社で行っております最終的な不具合解析が済み次第、より詳しい情報をただちに公開いたします。弊社は今週中にも情報を公開できることを予定しておりますので、今しばらくこのスレッドをご確認ください。

このコメントの下にあるholysmokecpというユーザー名によるコメントも面白い。

で、その「問題は解決されております」っていうのは、俺がコンピューターを開けても、膀胱パンパンの野良猫達が射撃練習の的にした跡のような臭いがしないという意味での解決かね、それとも、この問題を発生させた謎の原因の解明かね。ちょっと聞きたいだけだけどさ。

サポート要因の返事

上記にありますように、生物的な要因ではございません。弊社の製造工程上の問題であることを確認しております。製造方法は変更されましたので、新しく製造される製品では、この問題は解決されております。この問題が発生しました製造品をお持ちのお客様におかれましても、問題を修正する対応をいたします。詳しい情報をこのスレッドで公開いたしますので、今しばらくお待ちください。

ところで、実際のサポート要因の言葉は、私が翻訳したような敬語を使っていない。これは、英語に起因するものだろうか。あるいはそもそもネット上のフォーラムだからだろうか。言葉こそ敬語ではないが、対応としては悪くない。問題の認識や解決などの情報を迅速に出しているわけだから。

Users complain their Dell 6430u laptops smell like cat piss | Hacker News

Hacker Newsのスレッドでは、ついこのあいだ、店頭で売られていた新品の靴から猫の小便のような臭いがしたとか、新車から猫の小便のような臭いがしたという報告があり、おそらく、接着剤の臭いなのではないかと推測されている。

2013-10-13

古典的だが面白い効果

Zoomquilt

これは面白い。

効果的には、80年代に流行ったテクニックで、例えばちょっと探しただけでも、1977年の例も見つかる。

▶ Powers of Ten™ (1977) - YouTube

2013-05-21

なかなか表に出てこないツチノコとDMM

dmmのエンジニアと話をしてみたいという話 - たごもりすメモ

DMMというWebサイトがあるそうだ。どうもよくわからないのだが、dmm.comの方が一般商品を扱うWebサイトで、dmm.co.jpの方がエロ商品を扱うWebサイトらしい。

[dmm.com]DMM.com DVDレンタル、通販、動画配信、FX等の総合サイト
[dmm.co.jp]動画、DVD通販、オンラインゲーム等の総合サイト - DMM

主に動画とか同人作品などの電子的媒体のダウンロード販売を行なっているらしいが、家電なども、コンピューター周辺機器などへの偏りは観られるものの、幅広く扱っているようだ。

Webサイトは日本語で提供されていて、規模的にはだいぶ大きく、これを支えるには、裏で技術的に興味深いことをしているにも関わらず、DMMの技術者は一切表に出てこないし、日本人技術者のつながりからも外れていて、謎に包まれているらしい。

これだけのことをやっているからには内部のシステムは物凄いことになっているに違いない、きっとその話はありとあらゆる世界の教訓になるに違いない。どんな分野の勉強会に行ってもひっぱりだこだ。

のだが、ありとあらゆる技術系勉強会でdmmの人というのに会ったことがない。これでもそれなりに広い範囲の勉強会に行っていろんな人と話をしたと思うんだが、dmmの人は本当に会ったことがない。誰に聞いてもまったく会ったことがある人がいない。

なんなんだ。どこにいるんだ。ツチノコか。技術的にあらゆる意味で意義があるはずなのに。単独でタイトルにあげて1日カンファレンスやれるレベルのはずなのに。なぜだ。どこだ。出てこい。

参照先の人は、ぜひDMMの技術者と勉強会が開いてみたいらしいのだが、果たしてツチノコは発見できるのだろうか。

2013-05-02

Blink、新機能に対して新たなベンダープレフィクスを追加しない決定

Blink and the end of vendor prefixes | NCZOnline

Developer FAQ - The Chromium Projects
Blink - The Chromium Projects

Webkitからたもとを分かったBlinkは、Mozillaの方針に近い、新機能に対して新たなベンダープレフィクスを追加しない決定をした。これだけでもforkしたかいがあるというものだ。

ベンダープレフィクスとは、実験的実装のCSSプロパティを使うには、ブラウザーベンダー特有のプレフィクスの記述を要求することである。たとえば、border-radiusだ。

<p style="border : solid 1em red ; border-radius : 2em ; padding : 1em ;">
この文章は1emのサイズのボーダーで囲まれ、四隅は半径2emの弧を描く。
</p>

と書けば、以下のように表示される。

この文章は1emのサイズのボーダーで囲まれ、四隅は半径2emの弧を描く。

ただし、まだ実験的な実装のブラウザーは、ベンダープレフィクスを要求する。ベンダープレフィクスはブラウザーごとに違うので、現在メジャーなブラウザー全てに対応するのならば、以下のように書かなければならない。

-webkit-border-radius : 1em ;
-moz-border-radius : 1em ;
border-radius : 1em ;

もし、IEやOperaも対応している実験的な実装のCSSプロパティも使いたければ、-ms-とか-o-などのように書かなけれならない。馬鹿馬鹿しいにもほどがあるし、有害である。

ブラウザーベンダーの言い分としては、まだ実装が完全ではなく、今の挙動に依存されてもらっては困るので、安全のためにベンダープレフィクスを使っているということだ。しかし、実態は、非推奨の利用にも関わらず、多くの製品に利用されおり、末端ユーザーのブラウザーで表示させている。実際に動くのだから使わない手はない。

Blinkの新しい方針は、新しい実験的機能はベンダープレフィクスを使うのではなく、about:flagsで有効、無効を切り替えるものになるそうだ。もちろんそうすべきだ。

ブラウザーベンダーが新機能をろくな設計や検証もせず、詳細な仕様を公開せず、他のブラウザーベンダーとも協議せずに、とにかく他所に負けじと競って実装していたブラウザー戦争の時代は終わった。戦争時代の技術的に間違った遺物は終わらせなければならない。

さて、あとは単一文化への危機だ。webkitがforkでも、単一文化の危機は去らない。今後、webkitはApple製品専用になり、従来のwebkitの地位はBlinkが占め、Gecko(Firefox)は独立を保つことになるだろう。まだまだ望ましくない寡占状態だ。

2013-04-25

DMCAは1972年2月15日以前に州法でライセンスされた歌には無効

Court denies Grooveshark DMCA protection for songs like “Johnny B. Goode” | Ars Technica

DMCAにより、WebサイトはいわゆるSafe Harborな地位を手に入れた。たとえばユーザーがアップロードする著作物を受け付けて公開するようなWebサイトでは、DMCA取り下げ要求を処理すれば、Webサイト自体が著作権侵害に問われることはない。これにより、動画サイトなどは、ユーザーがアップロードする動画を、著作権侵害の恐れなく公開できる。もし、ユーザーが著作者ではなく許諾も得ていない他人の著作物を侵害する動画を上げた場合(大量のユーザーが大量にアップロードするので、到底事前にチェックできない)でも、DMCAが送られ次第削除すればいいのだ。

ところが、アメリカ合衆国というのは州法と連邦法がごちゃごちゃで、どうも裁判の結果、DMCAには歴史的な経緯のみ解決問題が色々とあり、法解釈の結果、1972年2月15日以前に州法でライセンスされた歌は、DMCAの適用範囲外であるという。

つまり、昔の歌にはSafe Harborが働かないので、Webサイト自体が著作権侵害に問われる。

しかし、DMCAが適用されないという事は、DMCA取り下げ要求も無効という事になり、権利者としても正式な訴訟を起こさなければならなくなるだろう。

ちなみに、YouTubeなどの大手動画サイトには影響しない。なぜならば、このような大手Webサイトは、すでに音楽パブリッシャーと独自の同意をしていて、パブリッシャーの判断で勝手に動画を取り下げていいような仕組みを作っているからだ。

著作権法はどの国も歴史的経緯から無駄に複雑になっているものであるが、アメリカ合衆国は特にひどいと思う次第。

2013-04-13

ブラウザーのCanvas/WebGLのブラックリスト

各ブラウザーのCanvasやWebGLのGPUやドライバーによるブラックリストの具体的な内容がどこかに載っていないかと探したので、忘れないようにメモしておく。各ブラウザーといっても、自由なソフトウェア実装のブラウザーでCanvasやWebGLをサポートしていて主要なものは、FirefoxかChromiumしかないが。

まず、総合的な情報としては、khronosのWikiが便利だ。

BlacklistsAndWhitelists - WebGL Public Wiki

Firefoxでは、以下のページで詳細が公開されている。

Blocklisting/Blocked Graphics Drivers - MozillaWiki

GNU/Linux環境では、Cairo経由でXRenderを使う(Canvas 2Dはこれにあたるか?)。これにはブラックリストはない。WebGLはデフォルトで有効化されている。よほど古いMesaやプロプラドライバーな環境でなければブラックリストには引っかからない。GL layers accelerationは、今のところ無効化されている。

Chromiumは公式にそのようなドキュメントはないので、ソースを読むしかない。ブラックリストはJSONで定義されていて、以下から読める。

[chrome] Contents of /trunk/src/content/browser/gpu/software_rendering_list.json

GNU/Linuxでは、Canvas 2DのGPU利用は無条件で無効化されている。また、WebGLもデフォルトでソフトウェア実装のものが使われている。

2013-04-09

Firefox 23では、デフォルトでSSLページ内で非SSLコンテンツの読み込みをブロックする

Site Compatibility for Firefox 23 | MDN

Firefox 23では、とうとうSSLページ内から非SSLコンテンツのロードをブロックするそうだ。

つまりとても簡単に言うと、httpsなページ内からhttpなURLで提供されるCSSやスクリプトやプラグインやiframeが読み込まれなくなる。しかし、Web FontやWebSocketにまで言及しているのに、何故か画像には言及していない。まさか画像だけは特別扱いするのだろうか。動画や音声も言及されていないがどうなのだろうか。

どうも、Nightlyの動作では、やはり画像だけは特別扱いのようだ。

ちなみに、Firefox 23は2013年の8月6日にリリースされる予定だ。

2013-03-15

1300曲の歌の和音を解析した結果

I analyzed the chords to 1300 songs for patterns. This is what I found. (part 3) Interactive Discovery | Blog – Hooktheory

1300曲の歌の和音を解析し、その関連性を公開しているそうだ。

もっともよく聞く以下の疑問に答えることができるそうだ。

  1. 俺はX, Y, Zからなる和音が好きなんだが、この和音を使っている歌にはどういうものがあるんだろう?
  2. なかなか良く聞こえる和音をいくつか作ったんだけど、この次に来るのにふさわしい和音が知りたい。和音のつながりから次に最も現れやすい和音とはなんだろう。

Find Songs With The Same Chords - Hooktheory Trends

とても面白そうだが、残念ながら音楽の素養のない私には分からない。ちゃんとFlashではなくCanvasを利用しているのも評価できる。

2013-03-11

WebサイトのFlash利用率が20%まで下がった

Usage Statistics of Flash for Websites, March 2013

w3techs.com調べによれば、WebサイトのFlash利用率が、とうとう20%にまで下がったそうだ。

調査方法はWeb Technologies Statistics and Trendsに書かれている。それによれば、

上位100万件のWebサイトを毎日調査。ランキングはAlexaより取得。Webサイトを構成するページひとつに、特定の技術が使われていれば、Webサイト全体が特定の技術を使っているとみなす。サブドメインを別のWebサイトとして扱わない。リダイレクトされるドメインはカウントしない。ここで定義するWebサイトは、Alexaの定義するWebサイトとは異なるため、実際に集計されるWebサイトの数は、100万件よりすこし少ない。

この調査結果では、一年前に比べてWebサイトのFlash利用率が5%も下がったそうだ。

Flashが死につつあるのはいいことだ。

2013-02-17

mozilla.orgのブログより、ブラウザー戦争、ゲーム

Browser Wars, the game « Fink @ Mozilla

先日、OperaがWebkitに移行することを発表した。これにより、ブラウザーのシェアは事実上、Firefox(Gecko)か、webkit系ブラウザーに二分されることになる。IEはすぐに死亡するので考えなくて良い。log.mozilla.orgのブログで、このままWebkitがシェアを独占した場合の危険性について書いている。

単一文化は、短期的には優れている。労力を集中させることができるし(みんな同じことに対して働く!)、今日動くリッチなWebアプリを書きたければ、(つまり、今日のブラウザーで動くやつを書きたければ)、状況はだいぶマシになる。

しかし、Webとはプラットフォームである。プラットフォームは、また違った厄介者なのだ。

今、モバイルWebがすべてWebkitになったとする。何が起こるか考えてみよう。

下位バグ互換: ここにひとつのバグがあるとする。幅長が素数の背景SVGイメージは、半透明が無効になるというものだとする。一年後、7328件のWebサイトがこのバグに依存するようになる。誰かが直しました。Webサイトが開発版ビルドでぶっ壊れました。修正は取り消され、単に警告がログに出るだけになる。何も壊れません、世界はWebkitが牛耳ってます、誰も気にしやしません。こうして、バグは今や、Webプラットフォームの仕様となったのであります。

イノベーションの阻害: あるハッカー集団が、2018年のラップトップでは当たり前になっている100コアを効率良く使う新しいブラウザーを開発した。旧態依然のブラウザーは、タブひとつにつきひとつのCPUを使い尽くすのとはえらい違いだ。これは完全な再設計であり、彼らのすんばらしい働きにより、世の中の99%のWebサイトをサポートしている。いや、98%にしよう。さて、Webkitがちょうど新機能を公開したので、皆がただちに製品のWebサイトに使い始めた(使わない理由なんてないだろ?)。おっと、サポート率90%にダウン。あるWebkitのバグは、対処したくないほど汚らしいバグであり、新ブラウザーのスレッド実装では動かない。なんじゃこりゃ? 80%だと? 何が起こってるッ! 急げ、このままだとどんどんサポート率が下がるぞッ!

このハッカー集団はとうとう諦めて、かわりに、求人サイトとか小鳥さんSNSとか、セキュリティ研究者とかに成り下がる。というわけでハッカーは今や、「ともだちんこぶぁい」とか言ってる。

不適切な支配:ある者が複数のストリームを使ってDJアプリを実装できるような同期APIを開発した。Appleの音楽スタジオパートナーは恐れをなし、実現を防ぐため、ブラウザーに付け加えたり、付け加えるforkをだそうとするもの全員に、根拠のない脅しの手紙を送りつける。

複雑化: 標準団体はもはやその目的を失い、死んでいく。いままでに出来なかったことを可能にする新機能はすばらしい。新機能の花が咲き誇る。ある花は他の花の上に咲く。Webサイトごとにてんでばらばらの機能を使う。機能のいくつかは保守しにくいので、カネをたっぷり持っている大企業が依存しているのでなければ、生き残れない。Web開発者は、現在の市場とユーザーの状況から、どの新機能が生き残るかというギャンブルを余儀なくされる。

混乱: CSSセレクターには多くの落とし穴がある。多くのチュートリアルでも言及されているし、regression test suiteにも入っている。そうそう、それとこれと'~'オペレーターを一緒に使えば、最初のはクラスのある要素にしか適用されないよ。規格書をみても乗ってないぜ。なぜなら、この数年アップデートされていないからだ。みんな調べるよりまず書いて試すしね。規格を更新する責任者は、いまCSS5にかかりっきりだよ。第一、規格書なんてyoutubeでチュートリアルをみれないやつのためにあるもんだろ? だろ?

ゲームクリア: Webは今や、2013年よりはるかに発達した。昨日、発売されたばかりのAppleのハードウェアの新機能も完璧にサポートしてるよ!(去年発売された時代遅れの大昔のパッド(笑)を持ってるなら、さっさとアップグレードしとけよ)。問題を実装する方法はいくつもある。そのうちのいくつかには、なんとまともに動くものもある。一部のwebkitベースのブラウザー限定だけどね。何が何なのか把握するのは難しい。期待通りに動かないことがあったしても、規格書はそこまで詳細を規定しているわけではないし、実装とて何も保証していないのだから。まあ、なんだね。ネイティブAPIはそれなりにドキュメント化されていて、上位互換なんだから、同じアプリをそれぞれのプラットフォーム向けに何度かネイティブに書きなおすのなんてそれほど苦でもないだろ。

これは、皆がWebkitを標準するから起こるのだろうか。否、皆が使うシリコンやTCPも同じだ。あるものが安定していれば、単一文化でも問題はない。まあ、大半は。TCPにもほころびがではじめているとはいえ。この憂慮は、複数のまともな解決方法があり、素早く進化し、今までにない分野にも進出し、実際のアプリからどのように使われるかわからないようなレイヤーに限定された問題であり、複数の独立した存在によって対処されるべきであるのだ。

2013-02-13

不自由ソフトウェアのOperaがWebkitに移行

邪悪な不自由ソフトウェアのOperaがレンダリングエンジンとJavaScriptエンジンの内製をやめて、webkitとV8を使うニュースが流れてきた。

しかし、それは単にUIがちょっと違うだけの不自由版Chromiumに成り下がるだけではないだろうか。

いずれにせよ、これでブラウザーといえば、事実上MozillaとWebkitしかなくなってしまったわけだ。

2013-01-31

FirefoxがFlash Player、Adobe Reder、Silverlightプラグインのデフォルトでのブロックを検討中

Firefox to block content based on Java, Reader, and Silverlight | Ars Technica

Firefoxの開発者は、主要な3つの不自由なプラグインであるAdobe Flash Player, Adobe Reader、Silverlightプラグインが必要なコンテンツをデフォルトでブロックし、ユーザーによる明示的なクリックがない限り表示しない、いわゆる「クリックして再生」機能をデフォルトで有効にすることを検討しているようだ。理由は、安定性とセキュリティのためだ。Flash、PDF、Silverlightは、Firefoxにおける主要な3つのクラッシュ要因かつ攻撃ベクターであり、これらを無効にすることで、大幅な安定性とセキュリティの向上が図れる。

ちなみに、これらのプラグインは不自由なソフトウェアであるので、このようなソフトウェアでシステムを汚染してはならない。