Firefox + Greasemonkey

1. 上記のダウンロードリンクをクリックし、指示に従ってインストール。

Google Chrome + Tampermonkey

1. 上記のダウンロードリンクをクリックし、指示に従ってインストール。

その他ブラウザ

（未確認）

Twitter公式・ユーザーの最初のツイートを検索

Discover your first Tweet

First Tweet - Who Said It First on Twitter

First Tweet - Who Said It First on Twitter
一度検索されたキーワードはサーバー上に残る模様、二度目からは瞬時に表示される。

ghost.c

#include <netdb.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <errno.h>#define CANARY "in_the_coal_mine"struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

void ghost(void) {
  int a, b=0, c=10; for (; (a="!nBACAAUBJBPAOANAQALAFBFBCAJAFDDDBCHATBIACAFMGAESFAKCAAHACCEGADBDBAEBLMGCRANCBHBBE"[b++]);) for(;64< a--;) putchar((++c == 42) ? (c-=32) : (32^(b&1)));
  puts("GHOST IN THE SHELL\n");
}

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/size_t len = sizeof(temp.buffer) - 16*sizeof(unsignedchar) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    //puts("vulnerable");
    ghost();
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

CVE-2015-0235_GHOST/ghost.c at develop · furyutei/CVE-2015-0235_GHOST · GitHub

これを使用しているシステムでコンパイルして

$ gcc -o ghost ghost.c

実行すると、該当する脆弱性がある場合には、

$ ./ghost

              !! !!! !
           !!          !!
         !               !
        !                 !
       !      !!      !!   !
      !      !!!!    !!!!  !!!
      !                    !!
      !   !      !!!!!!!!!!!!!
     !     !!!!!!!!!!!!!!!!!!!
    !           !!! !        !
 !!!     !!!!!!! !!!!  !!!!  !
   !!            !!!!!!!!!!!!!
     !!!                  !
         !!!  !!!!!!!!  !!     GHOST IN THE SHELL

$ 

このように一目でわかるので、迅速な対応が可能になると思われる。適宜活用されたし。

などと、まじめに対応するつもりでもついついネタに走りたくなってしまうので、脆弱性案件にかわいい通称やアイコンはよくない。

wget で実行

$ wget -q-O - "https://raw.githubusercontent.com/furyutei/CVE-2015-0235_GHOST/develop/build_aa.sh" | bash
not vulnerable

curl で実行

$ curl -skL"https://raw.githubusercontent.com/furyutei/CVE-2015-0235_GHOST/develop/build_aa.sh" | bash
not vulnerable

◇ 13日の金曜日よりも14日の土曜日が重要なクラスタより

• タイムライン上に「そういえば13日の金曜日」のようなツイートがちらちら
• すると「14日は土曜日ではないか！」と反応しはじめる、偏った人々（ゆうきまさみフォロワーの方ね）

◇ 2月で「14日の土曜日」だった年を調べたところ…

『あ〜るのバレンタイン話は、確か1987年だったよなぁ』

$ cal 219872月 1987日 月 火 水 木 金 土
 12345678910111213141516171819202122232425262728

『うんうん。えーと、今年はそれから何回目？ついでに西暦1年から調べてみるか』

$ python
>>> import calendar
>>> all, counter =0, 0>>>for year in range(1, 1+2015):
...   if calendar.weekday(year, 2, 14)==5:
...     all +=1
...     if 1987< year: counter +=1
...     print year
...
4915:(中略)17501756:(中略)198119871998200420092015>>>print all, counter2884>>>

『ほぉ、西暦4年もそうだったのか』

$ cal 242月 4日 月 火 水 木 金 土
                1234567891011121314151617181920212223242526272829

『あ、あれれ……？』
：
（中略）
：

$ cal 217502月 1750日 月 火 水 木 金 土
             12345678910111213141516171819202122232425262728

『んん…？』

―　間　―

$ cal 217562月 1756日 月 火 水 木 金 土
 1234567891011121314151617181920212223242526272829

『あ、これはちゃんと14日の土曜日になってるな。このあたりが境目、か……？』

◇ 原因は？

$ man cal
CAL(1)                  FreeBSD General Commands Manual                 CAL(1)

NAME
     cal, ncal ― displays a calendar and the date of Easter

（中略）

     -s country_code
             Assume the switch from Julian to Gregorian Calendar at the date
             associated with the country_code.  If not specified, ncal tries
             to guess the switch date from the local environment or falls back
             to September 2, 1752.  This was when Great Britain and her
             colonies switched to the Gregorian Calendar.

なる程、デフォルトだと、イギリスがグレゴリオ暦を採用した1752年9月14日以降がグレゴリオ暦表示で、それ以前はユリウス暦表示なのね。

$ cal 917529月 1752日 月 火 水 木 金 土
       121415161718192021222324252627282930

ほうほう。グレゴリオ暦での1752年9月13日はユリウス暦1752年9月2日なので、こうなるのね。

◇ 国名コードを指定するとどうなる？

これ、他の国だとどうなるんだろう？

略号一覧

ISO 3166-1 - Wikipedia

コマンドの -s オプションで指定できる国名コード(country_code)は二字のもの、ただし、網羅されているわけではない。

そもそも、イタリア（1582年10月15日グレゴリオ暦制定）だと？

《参考資料》ユリウス暦からグレゴリオ暦への切り替え
・1582年にローマ法王グレゴリオ13世がユリウス暦からグレゴリオ暦への転換を宣言したことにより、この時期にユリウス暦からグレゴリオ暦への切り替えが行われた国があります。
・カトリック国のイタリア、スペインなどでは1582年10月に切り替えが行われ、1582年10月4日の翌日が10月15日になり、1582年10月5日から10月14日までは存在しません。

みんなの知識【ちょっと便利帳】 - その曜日は何日？ 各年・各月の曜日を調べる - 西暦と月を設定し、各曜日の日付を一覧表示

$ cal -s IT 101582
Usage: cal [general options][-hjy][[month] year]
       cal [general options][-hj][-m month][year]
       ncal [general options][-hJjpwy][-s country_code][[month] year]
       ncal [general options][-hJeo][year]
General options: [-NC3][-A months][-B months]
For debug the highlighting: [-H yyyy-mm-dd][-d yyyy-mm]

あ、-s オプションは ncal だけか。

$ ncal -s IT 10158210月 1582月   11825火   21926水   32027木   42128金  152229土  162330日  172431

うん、確かに10/15を境に切り替わっているな。
じゃあ、日本だとどうなの？

・1873年1月1日に当たる明治5年12月3日（旧暦）を明治6年1月1日（新暦）とする太陽暦への改暦（明治改暦）。

グレゴリオ暦 - Wikipedia

$ ncal -s JP -A112187212月 18721月 1873月      411182518152229火      512192629162330水      6132027310172431木      71421284111825金   181522295121926土   291623306132027日   3101724317142128

ん？日付は連続しているし……

$ ncal -s IT -A112187212月 18721月 1873月      291623306132027火      3101724317142128水      411182518152229木      512192629162330金      6132027310172431土      71421284111825日   181522295121926

イタリアの暦とも違っている、ということは、このあたりはまだユリウス暦で表示されている、ということ？

◇ ncalでは、日本はいつグレゴリオ暦に切り替えたことになっているのか？

$ ncal -s JP -A112191812月 19181月 1919月      310176132027火      411187142128水      51218152229木      61329162330金      714310172431土   18154111825日   29165121926

は、はい……？
1919年1月1日から切り替えたことになっているのか……なぜ？？？

◇ 注釈

そもそも日本の場合、べつにグレゴリオ暦の前にユリウス暦を使っていたわけではないので、定義するのはナンセンス、という話はある。
その上で、元のソースコード中で「グレゴリオ暦1919年1月1日」（厳密にはその前日に当たるユリウス暦1918年12月18日）が登録されている根拠もよくわからず、まだこれよりは、明治改暦が実施された「グレゴリオ暦1873年1月1日」（同1872年12月19日）を登録した方がもっともらしいのではないか、と考える次第。

◇ ncal のバグについて

そもそもncal中の国別のユリウス暦→グレゴリオ暦切替日定義は、日本以外に関しても信頼できるかどうかは怪しい、のかも。
ncal(1)

BUGS
The assignment of Julian--Gregorian switching dates to country codes is
historically naive for many countries.

https://www.freebsd.org/cgi/man.cgi?query=ncal&sektion=1&manpath=FreeBSD+6.0-RELEASE

$ ncal -p
 AL Albania        1912-11-30      IT Italy          1582-10-04
 AT Austria        1583-10-05     *JP Japan          1918-12-18
 AU Australia      1752-09-02      LI Lithuania      1918-02-01
 BE Belgium        1582-12-14      LN Latin          9999-05-31
 BG Bulgaria       1916-03-18      LU Luxembourg     1582-12-14
 CA Canada         1752-09-02      LV Latvia         1918-02-01
 CH Switzerland    1655-02-28      NL Netherlands    1582-12-14
 CN China          1911-12-18      NO Norway         1700-02-18
 CZ Czech Republic 1584-01-06      PL Poland         1582-10-04
 DE Germany        1700-02-18      PT Portugal       1582-10-04
 DK Denmark        1700-02-18      RO Romania        1919-03-31
 ES Spain          1582-10-04      RU Russia         1918-01-31
 FI Finland        1753-02-17      SI Slovenia       1919-03-04
 FR France         1582-12-09      SW Sweden         1753-02-17
 GB United Kingdom 1752-09-02      TR Turkey         1926-12-18
 GR Greece         1924-03-09      US United States  1752-09-02
 HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04
 IS Iceland        1700-11-16

※ラテン世界の9999年

$ ncal -s LN 999999991月                2月                3月                4月
月   181522295121926512192629162330火   29162330613202761320273101724水   310172431714212871421284111825木   4111825181522181522295121926金   5121926291623291623306132027土   613202731017243101724317142128日   714212841118254111825181522295月                6月                7月                8月
月      7142128162330火   18152229172431水   291623301825木   3101724311926金   4111825132027土   5121926142128日   61320271522299月                10月               11月               12月
月      61320274111825181522296132027火      71421285121926291623307142128水   181522296132027310172418152229木   291623307142128411182529162330金   3101724181522295121926310172431土   41118252916233061320274111825日   512192631017243171421285121926

◇ 覚書

• FreeBSD の cal コマンドは ncal コマンドのエイリアス
  バイナリレベルで同一。コマンド名で判別し、ncalの -C オプション相当の表示をしている模様。

◇ 愚痴

というかそもそも、「とある年月を境にしてユリウス暦とグレゴリオ暦が切り替えられ、かつ、一見して（表示結果では）それとわからない」なんて仕様のカレンダー自体、やめて欲しいと思うのは自分だけ？
「デフォルトでグレゴリオ暦換算のカレンダーを表示、オプションでユリウス暦換算でも表示可能だよ」でええやん…。

◇ 一度のみ実行するループを用いた方法

result = ABNORMAL
// [I] 共通の前処理(スコープ内で使用するローカル変数設定等)<ループ> {
    if ( /* 異常系判定条件 */ ) {
        // [A] 異常系処理break
    }
    
    // [N] 正常系処理
    result = NORMAL
    break
}
// [F] 共通の後処理return result

for(;;){…} や while(true){…}、do{…}while(false)を使う手法。

問題点

• 初見の人には意図が判り辛い（do{…}while(false)であれば多少まし、ただし、言語によっては定数falseを使うことによる警告も）*1
• 一度しか実行されないループ→ループとして機能していない→構造化構文の誤用

◇ goto を用いた方法

result = ABNORMAL
// [I] 共通の前処理(スコープ内で使用するローカル変数設定等)if ( /* 異常系判定条件 */ ) {
    // [A] 異常系処理goto finally
}
    
// [N] 正常系処理
result = NORMAL

finally:
// [F] 共通の後処理return result 

問題点

• 前方への移動等の乱用を誘発しないか懸念（適切な使い方しか成されない保証があるのであれば可）

◇ 関数内関数を用いた方法

result = ABNORMAL
// [I] 共通の前処理(スコープ内で使用するローカル変数設定等)

(<関数>(){if ( /* 異常系判定条件 */ ) {// [A] 異常系処理return;
    }// [N] 正常系処理
    result = NORMAL
    return;
})()

// [F] 共通の後処理return result

問題点

• 一見してあえて関数内関数を使う意図が判り辛い
• 本来スコープ内に閉じ込めるべきローカル変数を外出ししている（必要な変数をすべて引数として渡す、という方法もあるが、それならば最初から外部関数なりにするのと変わらず、内部関数にするメリットがない）

◇ classのデストラクタを利用した方法

<クラス定義> {
    result = ABNORMAL
    // [I] 共通の前処理(スコープ内で使用するローカル変数設定等)<メイン処理>(…) {
        if ( /* 異常系判定条件 */ ) {
            // [A] 異常系処理return result
        }
    
        // [N] 正常系処理
        result = NORMAL
        return result
    }

    <デストラクタ>(…) {
        // [F] 共通の後処理
    }
}

問題点

• 目的（デバッグ用途）に比して、いささか冗長(コストが高い)かも？

◇「途中return禁止」ルール

もともとのガード節に関するツイートに対し、「出口が複数あって却って見づらい」旨の否定的な意見を受けて。

途中リターンの是非についてはこの辺りがいいかな。http://t.co/8DxWeuyMSJそういう意味では「MISRA-Cの呪縛」って呼んだ方が正しいかもしれない。ここには書かれてないけど、実は途中リターンはMISRA-C:2012では撤廃されているのもポイントね！

— たいたい竹流 (@torgtaitai) 2015, 2月 14

ここで注意すべきなのは、構造化プログラミングの文脈では、「1つの入り口と1つの出口を持つ、順次・選択・反復の3つの論理構造の組み合わせ」というスタイルはプログラム実行時のフローをソースコードから追いやすくするために用いられている、という点だ。

MISRA-Cにおける「関数の末尾以外の return 禁止」の真意 - 新・日々録 by TRASH BOX@Eel

関数内での途中returnは、大抵がネストを浅くする――つまり静的構造自体が複雑化することを避ける目的で使用されることが多いはずだ。構造化プログラミングでは考慮されていない部分なのだ。

こうなってくると、基本的には「1つの入り口と1つの出口を持つ、順次・選択・反復の3つの論理構造の組み合わせ」というスタイルをとりつつも必要に応じてルールを破る、というスタイルに落ち着く。

MISRA-Cにおける「関数の末尾以外の return 禁止」の真意 - 新・日々録 by TRASH BOX@Eel

◇「goto禁止」ルール

上述した「一度のみ実行するループを用いた方法」に関して、そういった（自分でも自覚しているような）トリッキーな方法を使うのではなく、gotoを使うべき、という意見。

• 「gotoを禁止」するルールによって、かえって可読性が損なわれてしまうのであれば、gotoを使うべき（上記他、多重ループから抜けるケースなど）であり、ルールの例外を許容すべき
• （移植などの関係で、言語間でなるべく記述方法の差異をなくしたい、という意見に対して）言語毎に適切な違うイディオム・作法があるため、極論すれば手法統一するという方針は無理がある

タイムリーな記事もあった。

200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行われていないことが判明した。これらのことから、実際にはgotoは有害でないものと考えられる。

C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」 - エキサイトニュース

「goto一律禁止」のルールで作られているものはそもそもgoto文が現れないので抽出されないだろうし、そうでない場合は思考停止すること無くよく考えて使う開発者の割合が高くなるような気もするので、この結果を鵜呑みにして実際に解禁したら無制限な使用が増える、という可能性も否定できない気はするけれど。

.htaccess からの参照時

• %{SERVER_PORT} には、SSLかそうでないかによらず '80'が設定される。
  このため、%{SERVER_PORT}ではSSL接続かどうかの判別はできない。
  「RewriteCond %{SERVER_PORT} ^80$」や「RewriteCond %{SERVER_PORT} !^443$」は常に真となるために、リダイレクトループが発生してしまう。
• SSLアクセス時には通常、 %{ENV:HTTPS} には 'on'が、%{HTTP:X-Sakura-Forwarded-For} にはクライアント（リクエスト元）のIPアドレスが設定される。*1
  ただし、SSLアクセスした場合であっても、mod_rewrite.c の RewriteRule によりリライトされるケースでは、リライト後には %{ENV:HTTPS} が未設定となってしまう。
  RewriteRuleの[R]フラグによりhttps://〜にリダイレクトされた場合には 'on'が設定される。

上記の .htaccess では、リダイレクトするかどうかの判別に、

RewriteCond %{ENV:HTTPS} !^on$

だけでなく、

RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$

のような条件（%{HTTP:X-Sakura-Forwarded-For}が未設定）を設定している。

これをせずに %{ENV:HTTPS} のみで判定してしまうと、例えば WordPress を設置したサイト上の http://〜/wordpress/year/month/day/ というページ(URL)にアクセスした場合、

のように、意図しないURLの PATH の書き換えが発生してしまう。
このため、[C] (3→4)のリダイレクトを発生させないように、条件を追加している。
むしろ「RewriteCond %{ENV:HTTPS} !^on$」の方は無くても現状では動作する。

PHP からの参照時

• SSLアクセス時には、$_SERVER['HTTP_X_SAKURA_FORWARDED_FOR'] および $_ENV['HTTP_X_SAKURA_FORWARDED_FOR'] にはクライアント（リクエスト元）のIPアドレスが設定される。
• SSLアクセスした場合であっても、mod_rewrite.c の RewriteRule によりリライトされるケースでは、$_SERVER['HTTPS'] と $_ENV['HTTPS'] が設定されない。
  RewriteRuleの[R]フラグによりhttps://〜にリダイレクトされた場合には 'on'が設定される。

WordPress 等では、SSL 接続かどうかを $_SERVER['HTTPS'] もしくは $_ENV['HTTPS'] の状態で判別している。
このため、上記のように $_SERVER['HTTP_X_SAKURA_FORWARDED_FOR'] が設定されているかどうかで SSL かどうかを判別し、SSL の場合には $_SERVER['HTTPS'] および $_ENV['HTTPS'] に 'on'を設定するような処理を追加してやる必要がある。

■ 集約版（2015.07.08 追記： 下の各々のブックマークレットの機能をひとつに集約したもの・ユーザースクリプト版と同等）

歌詞解禁(KashiKaikin) - Hatena::Let

■ 歌詞検索サービス 歌ネット用

歌ネット(Uta-Net)の歌詞抽出 - Hatena::Let

例） トゥッティ！ - 北宇治カルテット - 歌詞 : 歌ネット

■ うたまっぷ 歌詞を無料で検索表示用

うたまっぷ歌詞無料検索の歌詞抽出 - Hatena::Let

例） 北宇治カルテット(黄前久美子(黒沢ともよ)/加藤葉月(朝井彩加)/川島緑輝(豊田萌絵)/高坂麗奈(安済知佳))/歌詞:トゥッティ!/うたまっぷ歌詞無料検索

■ 歌詞検索サービス 歌詞ＧＥＴ用

歌詞GETのコンテキストメニュー解禁 - Hatena::Let

例） トゥッティ!/北宇治カルテット [黄前久美子 (CV:黒沢ともよ), 加藤葉月 (CV:朝井彩加), 川島緑輝 (CV:豊田萌絵), 高坂麗奈 (CV:安済知佳)] - 歌詞検索サービス 歌詞ＧＥＴ

■ 歌詞ナビ 無料歌詞検索サービス用

歌詞ナビの歌詞抽出 - Hatena::Let

例） トゥッティ！ 北宇治カルテット - 歌詞ナビ

■ 歌詞検索J-Lyric.net用

J-Lyric.netのコンテキストメニュー解禁 - Hatena::Let

例） 北宇治カルテット(黄前久美子(黒沢ともよ)/加藤葉月(朝井彩加)/川島緑輝(豊田萌絵)/高坂麗奈(安済知佳)) トゥッティ! 歌詞

長所

• JavaScript だけで動作している（クライアントサイドだけの処理で、サーバーとの通信は行わない）ため、比較的さくさく動作する。
• フレーズ数の上限は設けていない（ただし、多すぎると重くなる）。
• 途中保存して中断（設定をダウンロード）や再開（設定の読み込み）が可能。
• 設定ファイル（JSON形式）内の値を編集すれば、バナーの大きさやフォントも変更可能。

短所

• サーバーサイドの処理は一切ないため、はてなコピィのような一覧ページやリンクページといったものは自動では作れない。
• はてなコピィとのデータ上の互換性はない。
• 同じく、操作性も異なるので、慣れるまで若干とまどうかも。
• ブラウザによって出力結果が異なったり、うまく動作しない可能性あり。
  基本、PC版のブラウザのみ対応。IE11・Chrome・Firefox・Operaの最新版であれば多分動作する。ただしSafariでは多分うまく動作しない。

HTML5 Canvas と SVG のテキストの baseline の対応（今回対象としたもののみ）

em square＝文字の構造的な大きさを表す四角形、EM box・em quad 等とも。

■参考

textBaseline プロパティ - Canvasリファレンス - HTML5.JP
svg要素の基本的な使い方まとめ

それで、実際やってみたところ……

1枚目はChromeで、2枚目はIE11で、それぞれ見たイメージ。 IE11はそもそもdominant-baseline未サポートなのか、それとも設定の仕方がまずいのか。代替手段はあるのか…？ pic.twitter.com/7g6FRrLovE

— 風柳 (@furyutei) 2015, 7月 13

のように、IE では効いていないように思われた。

それで調べてみると、確かにサポートされていないようだ。

IE9 Mode, IE10 Mode, IE11 Mode, and EdgeHTML Mode (All
Versions)

The dominant-baseline attribute is not supported.

[MS-SVG]: [SVG11] Section 10.9.2, Baseline alignment properties

Google Chrome (バージョン 43.0.2357.132 m)

Windows 7 上で確認した限りでは、Firefox や Opera の最新版でもほぼ同様に見えた。

IE11

canvas 要素の Data URL への変換

参考：toDataURL() メソッド - Canvasリファレンス - HTML5.JP

var dataURL = canvas.toDataURL(type); // canvas は HTML5 Canvas の DOM要素、typeは画像の種別('image/png', 'image/jpeg'等)

データの Blob オブジェクトへの変換

参考：Blob - Web API インターフェイス | MDN

var blobObject = new Blob([data], {'type' : mimeType}); // data は元データ、mimeType は元データの MIMEタイプ('image/svg+xml'等)

Data URL の Blob オブジェクトへの変換

参考:Canvas に描いた画像を png などの形式の Blob に変換する方法: Tender Surrender

function make_blob_from_dataurl(dataurl) {if (!dataurl.match(/^data:(.*?);base64,(.*)$/)) {returnnull;
    }var type = RegExp.$1, base64 = RegExp.$2;
    
    var bin = atob(base64), bin_length = bin.length;
    var buffer = new Uint8Array(bin_length);
    for (var ci=0; ci < bin_length; ci++) {
        buffer[ci] = bin.charCodeAt(ci);
    }var blobObject = new Blob([buffer.buffer], {type: type});
    
    return blobObject;
}

ファイルを Blob オブジェクトとして取得

参考：バイナリデータの送信と受信 - XMLHttpRequest | MDN

var xhrObject = new XMLHttpRequest();
xhrObject.open('GET', url, true);
xhrObject.responseType = 'blob';
xhrObject.onload = function(event) {var blobObject = xhrObject.response;
    // ◆ 以下、blobObject を用いた処理を記述};
xhrObject.onerror = function(event) {//※(許可されていない)外部サイトのファイルを取得しようとすると以下のようなエラーが発生（IEの例）//  SEC7118: (取得しようとしたURL) の XMLHttpRequest には Cross Origin Resource Sharing (CORS) が必要です。//  ファイル: (元ファイル)//  SEC7120: 元の http://(元ドメイン) が Access-Control-Allow-Origin ヘッダーに見つかりません。//  ファイル: (元ファイル)//  SCRIPT7002: XMLHttpRequest: ネットワーク エラー 0x80070005, アクセスが拒否されました。window.open(url);   // 次善の策として、例えばポップアップで開く};
xhrObject.send();

Blob オブジェクトの Blob URL への変換

参考：window.URL.createObjectURL - Web API インターフェイス | MDN

var blobURL = (window.URL || window.webkitURL).createObjectURL(blobObject);

Blob オブジェクトをファイルとして保存したり開いたりするイベントの発生(IE10+)

参考：msSaveOrOpenBlob method (Internet Explorer)

window.navigator.msSaveOrOpenBlob(blobObject, filename);

条件

• さくらのレンタルサーバ（スタンダード）上に、20MBのファイルを設置
• CentOS 6.5 上から、wget コマンドにて上記ファイルを10分間隔でダウンロードし、転送速度を記録

注意事項

• さくらのレンタルサーバにおける帯域制限の影響は考慮していない。
  ただし傾向としては、04時～08時頃の測定時には頭打ちになっているように思えることから、これはさくら側の帯域制限の影響だと推測している(1TCPセッションにつき、40～50Mbpsあたり、とか？)。
• ISPは現状BIGLOBEしか契約していないため、他のISPとの定性的な比較はできていない。

サポートへ問い合わせ（2015/08/03）

フレッツ(NTN)網内回線速度と、BIGLOBE(ISP)経由の速度の乖離が大きいが、

• 原因としてはなにが考えられるか？
• 改善する方法はあるか？

■フレッツ測定サイト

■BIGLOBEサイト上の測定ツール
あなたの回線の速度を計測してみよう：BIGLOBE会員サポート

NTT回線の場合は、フレッツ・スクウェアでも回線速度を計測できます。
一般に、上の通信速度測定は、フレッツ・スクウェアとは計測方法が異なるため、フレッツ・スクウェアで計測した速度より20～30％低くなります。

http://support.biglobe.ne.jp/faq/speed/sokutei.html

とあるが、20～30％の低下に収まらない。

サポートからの情報提送付依頼（2015/08/03）

BIGLOBE網に問題がないか確認するので、下記情報を返信して欲しい。

＜１＞ tracert／ipconfig/allの実施

＜２＞ 通信速度の測定／IPアドレスの確認
◆通信速度測定サイトでの測定netspeed.studio-radish.com
◆NTTでの測定結果
◆IPアドレスの確認（ルータ・グローバル側）

＜３＞ ご利用環境の確認
◆パソコン環境
◆問題発生時の詳細

なお、当方の質問に対する具体的な回答はなし。

サポートへ情報の送付（2015/08/04）

依頼された情報に、私見も添えて回答。

＜１＞ tracert／ipconfig/allの実施
◆ tracert

> tracert -4 /d www.biglobe.ne.jp

を、時間帯を変えて五回測定した結果を送付。
[私見]
いずれも13ホップで同一のルート・RTTは時間帯によるバラつき(12～21ms)も許容範囲と思う。

◆ ipconfig/all
ipconfig /all の結果、および、ルータ上の接続情報も付記。

＜２＞ 通信速度の測定／IPアドレスの確認
◆通信速度測定サイトでの測定
※測定サーバー:大阪-新町

※測定サーバー:東京-WebARENA

[私見]

• 大阪＜東京の傾向あり（理由不明）。
• 19時台・25時(1時)台・30時(6時)台と、21時台・23時台とを比較すると後者の速度が大阪・東京共に大幅に落ち込んでいる。輻輳か？
• 最も安定した(測定品質の高い)データは30時(6時)台のものだが、それでも
  大阪：～23Mbps・東京：～44Mbps
  程度であり、後述のNTTの同時間帯(シングル計測)
  IPv4：～126Mbps・IPv6：～120Mbps
  と比較すると、20～30％程しか出ておらず、サイト上の情報（20～30％程度の低下）とは大きく乖離している。

◆NTTでの測定結果
※フレッツ速度測定 (IPv4) サイト

※フレッツ速度測定サイト(IPv6・大阪)

[私見]

• 通信速度測定サイトの結果と比較して、数倍～10倍以上速いという結果になっていることから、BIGLOBE(ISP)網側に問題があるのではないか、という見解。
• 時間帯による差異は、通信速度測定サイトの測定結果ほどには、大きくない。フレッツ(NTN)網内は比較的安定していると思われる。

◆IPアドレスの確認（ルータ・グローバル側）
※先方から指定されたURLにアクセスし、取得したIPアドレスを送付。

＜３＞ ご利用環境の確認
◆パソコン環境
※自分のPC環境(Windows7)の詳細な情報を送付。

◆問題発生時の詳細
※開通時から一般の測定サイトの結果は通常時10～40Mbps 遅延時2～15Mbps程度の速度であった、今回NTTフレッツ測定結果とも大きな乖離があることが判明した旨付記。

Stagefright 脆弱性が話題になっていたので

自分の所持しているワイモバイルの Nexus 5 (EM01L) は SMS/MMS 対応だったこともあり、ワイモバイルのサポートに 2015/07/30 に問い合わせを行った。

OSにAndroidを採用しているスマートフォンにおいて、深刻な脆弱性が存在する、という記事を見かけました。
http://japanese.engadget.com/2015/07/27/android-95-mms/
・動画再生エンジンの脆弱性であるため、メディアファイル読み込みの時点で、リモートからのアプリ権限での任意コード実行が可能となる。
・経路の一つとして、MMSをGoogleハングアウトで受信した場合は受信した瞬間にコードが実行されうる。
ということのようで、特にMMSをサポートしている御社のAndroid端末においては危険性が高いものだと思われます。

この脆弱性について、
1. 現時点で、対策等はなされていますでしょうか？
2. ユーザー側での暫定的な対処方法などはありますでしょうか？
3. 今後の対策スケジュール等はどのようになっていますでしょうか？
お手数ではありますが、ご回答いただけますよう、お願いいたします。

すると、まず 7/30 に返信があり、

• 現在確認中のため、詳細についてわかりかねる
• 現時点において対処方法などの情報はない
• メーカーへ確認し、回答が出次第連絡する

という内容。

さらに、8/1にそれぞれ違う方から返信があったのだが、これも似たようなもので（内部で連携していない？）

• Androidの脆弱性につきましては、現在詳細を確認中
• 端末メーカーへの確認したところ、現時点においては各社ともセキュリティリスクが発生する脆弱性である認識がある旨の回答
• セキュリティパッチの提供時期等に関しては明確な回答は得られていない
• 現在、メーカーと協力し、順次対策を講じる準備を進めており、対策が準備出来たら、ソフトウェア更新などの形でお客さまへお知らせ
• ユーザサイドでの暫定的な対処についても、具体的、断定的な対処が出来かねる状況

という回答。

結局、連絡待ちだと認識したので、とりあえずハングアウトでMMSを自動的には開かないように設定して待つことにした。

そうこうしているうちに、案内が

2015/08/06付で、ワイモバイルのサイト上にwww.ymobile.jp
のようなお知らせが掲載された。
ただし、サポートからの連絡はない。

更新内容 セキュリティおよび動作安定性の向上

Nexus 5 （EM01L）をご利用のお客さまへ ～最新ソフトウェア配信のお知らせ～ | ワイモバイル（Y!mobile）

となっていたため、おそらくStagefrightがらみだろうと、ビルド番号「LMY48I」をキーに調べてみると、

LMY48I

08/05/2015

Patch for critical security vulnerability ('Stagefright')

Find and update the software version on your Google Nexus 5

ということなので、間違いなさそう。配信を待つことに。

配信されてきたところで、再度問い合わせを投げてみたところ……

2015/08/12 の早朝に、うちの Nexus 5 にも LMY48I が配信されてきたので、この機会に再度ワイモバイルに問い合わせをしてみた（抜粋）。

先日、Android の深刻な脆弱性(Stagefright)に関して質問させていただきました。
その後、カスタマーセンター ○○様、△△様からご回答があり、セキュリティパッチ等の対処方法が判明次第ご連絡をいただける、とのことでしたが、その後どうなりましたでしょうか。

http://www.ymobile.jp/info/2015/15080602.html
には、2015年8月6日付で、「セキュリティおよび動作安定性の向上」のソフトウェア配信のご案内があり、また、今朝方当方の Nexus 5 にも同ソフトウェア（ビルド番号「LMY48I」）が配信されたようですが、これで上記の脆弱性についても対応されたものという認識で宜しいでしょうか。

なお、もし上記ソフトウェア配信で解消されているにせよ、当方の最初の問い合わせから2週間弱・サイト上へのご案内の掲載時(8/6)からでも6日も経つ段階で当方になんのご連絡も頂いていないというのは、御社のサポート体制としては疑問に感じてしまいますので、できれば改善していただきたいと思います。

すると、こういう返事が……（抜粋）

弊社ホームページにて、ご案内しております最新ソフトウェア更新内容といたしましては、「セキュリティおよび動作安定性の向上」となります。
こちらはGoogleからの直接提供となりますので、詳細の内容はわかりかねます。
お手数をおかけいたしますが、ご確認ご希望の際は、
Googleサポートチームへご相談くださいますようお願いいたします。

◇Googleサポートチーム　
　0120？950？065（通話料無料）　
　9:00？18:00 （無休）

××さまからのご指摘・ご意見は真摯に受け止め、貴重なご意見として承り、
担当部署に上申させていただき、今後同様のトラブルが起こりませんようサービス向上に努めてまいります。
ご迷惑をおかけいたしましたことを重ねてお詫び申し上げます。

「なにが配信されるかよく知らないけれど、とりあえず案内だけしとくね。詳細知りたかったら自分で Google に確認してね！」
ってことだよなぁ、どう読んでみても……雑すぎないか？

というか、問い合わせがあった段階で、サポート側で Google に確認するなりの対応すら、しないということだろうか？
前にも機種変更時に関して問い合わせてみたら要領を得なかったり、Nexus5 のコンパス機能についてワイモバイルに問い合わせたら Google に丸投げされた経験があるのだけれど、お客さま窓口として機能していないよなぁ、これ……呆れてしまう。
一方、Google の窓口の対応は感じがよくて丁寧なので、相対的に評価が上がるのだけれど。

■ OCN

service.ocn.ne.jp

■ Yahoo! BB

bbpromo.yahoo.co.jp

■ ぷらら

www.plala.or.jp

■ So-net

インターネット接続・プロバイダー乗り換え・通信回線変更｜So-net

■ BIGLOBE

BIGLOBE接続サービス:プロバイダならビッグローブ

■ @nifty

setsuzoku.nifty.com

■ BB.excite

bb.excite.co.jp

■ ASAHIネット

プロバイダはASAHIネット｜料金、接続品質、満足度で選ばれるISP

傾向

• いずれの場合にも（ベストエフォートであるためやむを得ないとはいえ）通信速度のばらつきが非常に大きい。
  個人レベルでの「○○は速いよ（遅いよ）」という話は参考程度にとどめておく方が無難かも知れない。自分の地域で快適かどうかは運次第か、と感じる。
• 一般的な傾向として、21～25時の時間帯は特に（利用者が集中することによる輻輳を反映してか）低速を示すデータ数が増加している。
• 輻輳の発生する時間帯であっても、十分高速に通信できている方も一定数存在する（全国のデータなので同じ地域・時間帯であっても差が極端に出ているのかどうかはこれだけではわからないが）。
• @niftyとASAHIネットは、輻輳時間帯でも低速を示すデータの割合が少なく、比較的余裕があるように思える。
  取得できたサンプル数が十分とは言えないため、断言できるものではないが。

本来なら、測定地でフィルタをかけて自分の地域の傾向を知りたいところだが、そうなると現状では十分なサンプル数が取れない。
例えば、上記のOCNのデータに「神奈川県」でフィルタをかけると、

のような分布になるため、
OCN 光ネクスト（神奈川）の速度問題について
で述べられている拡張工事による品質改善が功を奏している、という結論に短絡したくなるが、サンプル数が少なく、輻輳時間帯のデータがあまり無いこともあり、確かなことは言えない。

■ NTT フレッツ

flets.com
flets-w.com

■ au ひかり

www.au.kddi.com

■ K-OPTI.com eo光ネット

eonet.jp

■ So-net NURO光

www.nuro.jp

■ CTCコミュファ 光

ネットも電話もテレビもまとめてコミュファ光

傾向

• NTT フレッツ以外のサービスは全般的に比較的中～高速域のデータが多いし、夜間の輻輳も今のところは目立ったものではなさそうなので（NURO光は若干多い？）、通信速度のみに着目する場合、自宅が対応しているのであれば乗り換えを検討する価値はありそう。
• NTT フレッツは（当然ながら）上記のプロバイダの結果をそのまま重ね合わせた傾向となっている。加入者が圧倒的に多く、その分輻輳も発生しやすいということか。
  自分の経験や知人の話、ネット上の口コミ等をみても、往々にして（プロバイダを介さない）フレッツ網自体の速度は十分、という場合が多いようだし、プロバイダにがんばってもらうしかない……。

使用方法

1. みんなの測定結果 - Radish Network Speed Testing -で、1頁表示件数を設定（推奨：100・後述）。
2. 絞り込み条件を設定し、検索。
3. ブックマークレットを実行（取得データ数がカウントされていく）。
4. データが取得し終わると、CSVファイルがダウンロード可能となるリンクができ、自動的にダウンロード開始。
   ただし、HTML5・A要素(リンク)のdownload属性がサポートされているブラウザとIE10以降のみ。Safari等はNG。

[2015/08/17] [検索]ボタンを押す手順および1頁表示件数を設定する手順を省略（取得時の1頁表示件数は100固定に）。

1. みんなの測定結果 - Radish Network Speed Testing -で、絞り込み条件を設定（[検索]ボタンを押す必要はない）。
2. ブックマークレットを実行し、基準日と期間を入力（データの取得が開始され、取得データ数がカウントされていく）。
3. データが取得し終わると、CSVファイルがダウンロード可能となるリンクができ、自動的にダウンロード開始。
   ただし、HTML5・A要素(リンク)のdownload属性がサポートされているブラウザとIE10以降のみ。Safari等はNG。

CSVファイルはBOM付のUTF-8形式になっている。
【参考】

ブラウザだけで Excel 向け日本語 CSV ファイルを作る方法 - do_akiの徒然想記

Windows版Excelだと文字化けせずに開けるはず。Mac版はNGらしい。

みんなの測定結果 - Radish Network Speed Testing -では1頁表示件数により得られるデータ数が異なる

例えば、1頁表示件数を 100 にした場合のデータ数は、1 にしてさかのぼって取得したデータと比較すると、かなり少なくなる。
この件を株式会社Studio Radish様に問い合わせたところ、

• 同一のユーザーによるデータは、1ページの中で最初のデータのみを代表として表示（グループ化）。
  当該ユーザーのその他のデータには、"この人の測定履歴(件数)"で表示可能）。
  非常にアクティブな（測定登録回数の多い）ユーザーがいると、多様な環境での結果を比較する上で妨げとなるため。
• グループ化は 1ページ内でのみ実施され、ページが変わると再度最初のデータのみが表示される。
  時系列での比較のため。

という仕様になっているためとのこと。

今回の記事でも、なるべく多様な環境でのデータを取得したかったため、グループ化が最大の効果を得られるように、1頁表示件数を 100 にして取得している。
また、1頁表示件数が少ないとその分取得ページ数が多くなり、サーバーに負荷をかけてしまう、という理由もある。

【付記】Two column location の設定方法

Edit → Change columns
にて、カラムを追加・削除したり、名前や型(Type)等を編集したりできる。

カラムの Type で "Location"を選んだ場合には、地名や住所、緯度・経度の組み合わせ（カンマ区切り）などを入れることができる（これは Map の方にも反映される）。
このとき、緯度・経度しか使用しない場合には、「□ Two column location」にチェックを入れて、緯度(Latitude)、経度(Longitude)として使用するカラム名をそれぞれ指定すればよいのだが、最初これを行おうと、Latitude カラムを追加してみると、

Type を Location に変更しても、「□ Two column location」が選択できない（灰色表示）。

いろいろ試してみたところ、先に Longitude に該当するカラムを Type = Number で作成してから、

一旦[Save]し、再び、Edit → Change columns から開くと、

今度は選択できるようになっているので、チェックし、Latitude/Longitudeにそれぞれ対応するカラム名を選択して（ついでに、不要になったLocationカラムは削除して）、再度[Save]する。

このようにカラムを設定してから、実際に緯度・経度を指定したデータ(行)を作成してみると、

"Map of Location"タブで、当該データがプロットされているのを確認できる。

簡単なスクリプトの実行

Googleドキュメント上の Fusion Tables のテーブルにアクセスして、行内容を表示するだけのサンプルスクリプト。

var tableId = 'your-table-id';

function getRows(request) {var sql = 'SELECT * FROM ' + tableId + ' LIMIT 10';
  
  var result = FusionTables.Query.sqlGet(sql);
  for (var row_number=0; row_number < result.rows.length; row_number++) {var columns = [];
    for (var column_number=0; column_number < result.columns.length; column_number++) {
      columns.push(result.columns[column_number] + '=' + result.rows[row_number][column_number]);
    }
    Logger.log(columns.join(', '));
  }}

ここで、"your-table-id"の部分には、自分で作成した Fusion Tables のテーブルの画面右上にある[Share]ボタンを押して表示される共有リンク

の、"……?docid=～"の～部分をコピーして貼り付ける。

これを実行すると、

承認を求められるので、[続行]を押し、

許可のリクエスト画面にて、[承認]を押す。

実行が終わり、メニューから
表示 → ログ
を選んで、

実行結果が表示されていれば、無事 Fusion Tables のテーブルへのアクセスが成功している。