風柳メモ

ソフトウェア・プログラミング関連の覚書が中心

ワイモバイル(Y!mobile)のサポートは、ほんとに使えないな（嘆息）

自社のサイトで案内している最新ソフトウェアwww.ymobile.jp
が、具体的にどういうものなのかも、把握していないらしい。

経緯

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 の窓口の対応は感じがよくて丁寧なので、相対的に評価が上がるのだけれど。

「ベストエフォートなので、そんなもんです」（要約）……BIGLOBE光ネクスト(大阪)の通信速度問題をサポートに問い合わせた結果

[2016/10/15 追記]
以下の記事も参照のこと。
furyu.hatenablog.com
furyu.hatenablog.com
v6プラスを利用するようにしたら、IPv4での通信速度が改善（安定化）したというお話。
ただし、v6プラスにするためにはホームゲートウェイ（ひかり電話ルータ）かサードパーティ製の対応ルータが必要で、かつ制約も多いので注意。


「自宅で利用している、BIGLOBE光ネクスト ファミリー・スーパーハイスピードタイプ隼（NTT西日本エリア・最大1Gbps）が遅い！」ということを具体的に示すため、実際に一週間測定を行った結果を
furyu.hatenablog.com
のような記事にまとめたわけだが、そこに至るきっかけとなった、BIGLOBEサポートとのやりとりを記録しておく。

まぁ、結論から言えば

速度についてはベストエフォート型サービスとなるためお客様のご利用環境、回線の混雑状況などにより通信速度が変化する場合があります。

という、木で鼻をくくったような回答だったわけだが。

この「ベストエフォート」という言葉、プロバイダ(ISP)は便利に使い過ぎだろう。「最善の努力」しているの、ほんとに？

通信事業者のインターネット回線品質がベストエフォート型を標榜する場合、網の能力を超えたトラフィックが入力された場合に超過分が捨てられる仕組みを意味することが多いが、それは同時に同料金を支払っている契約者の中で大きく異なるサービスが提供される結果になるため、契約履行の公平性を失ったサービス提供が消費者トラブルの要因となることがある。いわゆるブロードバンド接続などに関連して、プロバイダー事業者などが無責任範囲を恣意的に拡大解釈し、「通信事業者がいかなる意味でも品質に関する義務を負わないこと」と解して顧客に対して回線品質の劣化や提供サービスの上げ底化を弁護する行為が典型である。

ベストエフォート - Wikipedia

まさにこの通りで、“最大1Gbps”をうたい文句にしている通信サービスが、「その数百分の一程度しか出ない時間帯が恒常的に存在する」状態というのは、そう簡単に納得してもらえるとは思えないのだけれども。

弊社としても速度が出にくい時があることは確認しており、解消できるよう努めてまいります

という言が本当であることを願う。


BIGLOBEサポートとのやりとり（要約）

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

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

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

■フレッツ測定サイト

シングル計測 90～120Mbps程度
マルチ計測 300Mbps～400Mbps程度

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

実効速度 10～26Mbps程度

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アドレスの確認
◆通信速度測定サイトでの測定
※測定サーバー:大阪-新町

時刻 19:10 21:18 23:06 25:05 30:10
下り回線速度 10.47Mbps 5.494Mbps 2.588Mbps 11.52Mbps 23.25Mbps

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

時刻 19:12 21:20 23:11 25:04 30:12
下り回線速度 37.31Mbps 5.360Mbps 2.379Mbps 25.93Mbps 43.49Mbps

[私見]

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

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

時刻 18:51 21:17 23:15 25:08 30:15
シングル 123.60Mbps 121.90Mbps 121.69Mbps 125.45Mbps 125.80Mbps
マルチ 503.19Mbps 423.14Mbps 392.34Mbps 455.11Mbps 426.67Mbps

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

時刻 18:55 21:15 23:16 25:06 30:13
シングル 118.31Mbps 116.10Mbps 119.98Mbps 92.00Mbps 119.98Mbps
マルチ 348.30Mbps 415.42Mbps 357.42Mbps 327.16Mbps 395.37Mbps

[私見]

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

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


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

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

サポートからの回答（2015/08/06）

  • BIGLOBE網内を確認し、該当回線で遅延の要因となりうる工事/障害等はなし。
  • 時間帯によっては利用者（トラフィック）増加による速度が出にくい状態を確認。
  • ベストエフォート型サービスのため、回線の混雑状況により通信速度が変化する場合がある。
  • 回線を切断→再接続により、変化する場合があるので試してほしい。

サポートへの質問（2015/08/06）

[1] NTT の回線との速度乖離について
そもそもの質問は、
「NTTの速度結果と御社ISPでの測定結果の乖離が酷いが、どうしてか？」
というもの（前回送った測定結果でもこれが裏付けられている）。
これに関して納得のいく説明をして欲しい。

[2] 再接続しての測定結果
再接続を試みたが、改善されない（むしろ測定結果は悪くなった）。

[3] 通信速度の変化について

  • ベストエフォート型といえど、時間帯によっては ～3Mbps と、光回線とは思えない速度になってしまうのは納得しがたいので、将来的に改善されていくことを期待。
  • 独自に定期的に取得した測定結果をサイトに掲載する予定なので了承願う。

サポートからの回答（2015/08/10）

[1] NTT の回線との速度乖離について
フレッツの速度測定サイトでは、

  • インターネット上の測定サイトとは異なり、インターネット上に出ておらず、フレッツ網内のみの測定。
  • 回線の混雑状態含め、通常の測定サイトと比べて影響を受けにくい。

このため、良い結果が出る。

また、フレッツの速度測定サイトとインターネット上の速度測定サイトで計測した数値が離れていたとしても、先日回答したようにベストエフォート型のサービスとなるため、そのようなことはありうる。

[2] 再接続しての測定結果
改善される可能性があったため、案内した。

[3] 通信速度の変化について
WEBページ上への掲載・公開は、BIGLOBEとして止めることはできない。

サポートへの質問と要望（2015/08/10）

[1] NTT の回線との速度乖離について
ご回答いただいた内容（フレッツの測定サイトとインターネット上の測定サイトの環境の違い等）については理解している。
繰り返すが、あなたの回線の速度を計測してみよう：BIGLOBE会員サポートで、

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

となっている、この「20～30％低くなる」というのは

  • ISP（インターネット・バックボーン）を経由することによる影響を受けることを前提にした上で（考慮に入れたうえで）、その程度の差が出る

という記述だと解釈していたが、違うのか。
「20～30％低くなる」という数値は、具体的にどのような環境で測定されることを想定しているのか教えて欲しい。

[3] 通信速度の変化について
それでは、データ取得が完了したら、サイト上にアップする。

いくら「ベストエフォート」という言葉で説明されても、満足のいく速度とはとても言えないため、特に夜間の極端な速度低下が解消されるよう願う。

また、ISP契約前に確認できるよう、お試し期間を設けるか、地域・時間帯毎の典型的な実効通信速度を参照できるようなページが必要ではないか。ご検討願う。

サポートからの回答（2015/08/11）

[1] NTT の回線との速度乖離について
20％～30％という数値は、ISPを経由しインターネットへ接続することにより影響を受けることを考慮したうえでの目安。
時間帯やご利用者数、トラフィックの混雑状況により速度は変化するため、想定していた以上に数値が悪くなることはある。

BIGLOBEとしても速度が出にくい時があることは確認しており、解消できるよう努めていくが、現時点では案内できる情報は持ち合わせていないので、ご了承願いたい。

[3] 通信速度の変化について
速度の確認ページについては、現時点において該当するページは用意しておらず予定もない。いち意見として担当へ報告した。

今頃になって はてなダイアリーから はてなブログに移行してみたらハマった件

↓のツイートを見て、いいかげん潮時かなぁ、と思い、愛着のある はてなダイアリー から はてなブログ へと移行することにした。


移行自体はhelp.hatenablog.com
を参考にして、特に問題なくできた……と思ったのだが、思わぬ落とし穴が。

  1. ダイアリー→ブログに移行
  2. はてなブログProに加入
  3. 設定→詳細設定→キーワードリンクにて、☑記事にキーワードリンクを付与しないにチェック


の順番でやってしまったため、過去の記事にすべてキーワードリンクが付いた状態になってしまった、という……。
ちなみに、はてなダイアリーPlus にはもともと加入しており、ダイアリー側でキーワードリンクをしないように設定していたが、これは無視される(?)模様。
また、記事を保存しなおせばリンクは消えるらしいが、数百ある記事ひとつひとつ操作するなんてやってられない。


しかたがないので、いったんインポートの取り消しを行い、再度移行手順を踏んだところ、今度はめでたくキーワードリンクが無くなった模様。


というわけで、移行時の正しい順番は、

  1. はてなブログProに加入
  2. 設定→詳細設定→キーワードリンクにて、☑記事にキーワードリンクを付与しないにチェック
  3. ダイアリー→ブログに移行

ということだと思われる。

BIGLOBE光ネクスト(大阪)の通信速度調査

[2016/10/15 追記]
以下の記事も参照のこと。
furyu.hatenablog.com
furyu.hatenablog.com
v6プラスを利用するようにしたら、IPv4での通信速度が改善（安定化）したというお話。
ただし、v6プラスにするためにはホームゲートウェイ（ひかり電話ルータ）かサードパーティ製の対応ルータが必要で、かつ制約も多いので注意。


今更ながら、「うちはBIGLOBE光ネクスト ファミリー・スーパーハイスピードタイプ隼（NTT西日本エリア・最大1Gbps）の割に、通信（ダウンロード）速度がめっちゃ遅いなぁ……」と気になった。

とりあえず、通信速度を測定してみたり、BIGLOBEサポートに問い合わせてみたりしていたが、

furyu.hatenablog.com

結論から言えば、

ということが判明した。
ISP(BIGLOBE)のバックボーンが利用者に対して十分な帯域が確保できていないということだろう。


「実際にどのくらい遅いのか、また特に通信速度が低下する時間帯はどのあたりか」などをより具体的に知るために、一週間の間、定期的にダウンロード通信速度を計測してみた。その結果を次に示す。
大阪でプロバイダ(ISP)をこれから選択する人・乗り換えを検討している人などの参考になれば幸い。

測定結果（2015/08/05～08/11）

条件

f:id:furyu-tei:20150812015409p:plain
f:id:furyu-tei:20150812015414p:plain

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

参考

OCN 光ネクスト（神奈川）の速度問題について
OCN 光ネクスト（神奈川）の速度問題の実験詳細

以降の記録

HTML5・A要素(リンク)のdownload属性に関する覚え書き

これもコピィ・ライター作成時に、

  • 動的に生成した画像をボタンをクリックしてダウンロード

する機能を実現する過程で、HTML5・A要素(リンク)の download 属性について調べたことに関する覚え書き。

HTML5・A要素(リンク)の download 属性とは


download HTML5


この属性は、ユーザがリンクをクリックするとリソースをローカルファイルとして保存することを促されるように、リソースをダウンロードするために使用されるハイパーリンクであることをページ作者が意図して記述します。属性に値が指定された場合、ユーザがリンクをクリックしたときに開く保存プロンプトの、デフォルトのファイル名として解釈します (もちろん、ユーザは実際にファイルを保存する前にファイル名を変更できます)。使用可能な値に制限はありません (ただし / および \ はアンダースコアに変換して、特定のパスヒントを防ぎます) が、多くのファイルシステムには、ファイル名に使用できない文字があることを考慮する必要があります。ブラウザがファイル名を調整するかもしれません。

補足:

  • この属性は、ユーザが簡単に JavaScript を使用するプログラムで生成されたコンテンツ (例えばオンラインのお絵かき Web アプリを使用して描いた画像) をダウンロードするため、blob: URL および data: URL とともに使用できます。
  • この属性で指定したものと異なるファイル名を Content-Disposition: HTTP ヘッダで与えている場合は、この属性より HTTP ヘッダが優先します。
  • この属性を指定するとともに Content-Disposition: で inline を指定している場合、Firefox はファイル名と同様に Content-Disposition を優先しますが、Chrome は download 属性を優先します。
  • Firefox 20 では、この属性は同一生成元のリソースへのリンクにのみ受け入れられます。

a 要素 - HTML | MDN

とりあえず、Can I use... Support tables for HTML5, CSS3, etcで調べてみると、最新のFirefox・Chrome・Operaはサポートしている模様。
またIEは無いのか……と思ったが、代替手段（window.navigator.msSaveOrOpenBlob()）でなんとかなりそうではあった。
Safari？　えっと、知らない子ですね……。

実験とブラウザ毎の結果

  • [A] 画像ファイルを Data URL に変換したもの
  • [B] 画像ファイル(サイト内)へのリンク
  • [C] 画像ファイル(外部サイト)へのリンク

の三種類の A(リンク)要素を用意し、それぞれに download 属性でファイル名を指定した場合のテストを行った。
IE用には別途、スクリプトで window.navigator.msSaveOrOpenBlob() を使った細工をしてある。

それぞれのリンクをクリック(タップ)した結果、以下のようになった。

Google Chrome
43.0.2357.134 m		 Firefox
39.0		 Opera
30.0.1835.125		 IE11 Chrome for Android
43.0.2357.93
[A] ○ ○ ○ ▲ ○
[B] ○ ○ ○ ▲ ×
[C] △ × △ ※ ×
  • ○：download属性で指定したファイル名でダウンロード
  • △：download属性は無視され、href属性を元にしたファイル名でダウンロード
  • ▲：download属性で指定したファイル名でダウンロード
    IE用に、リンクに onclick トリガを設定し、window.navigator.msSaveOrOpenBlob() を使った細工を入れている
  • ※：別窓(タブ)で画像が開く
    IE用に、リンクに onclick トリガを設定し、XMLHttpRequest で画像を取得させ、エラーが発生したら別窓(タブ)で開く細工を入れている
  • ×：hrefで指定された先にページ遷移

外部サイト上のファイルの場合の動作はセキュリティがらみの制限なのだろうと推測されるが、Chrome for Android でサイト内ファイルへのリンクまでページ遷移してしまうのは謎。なぜ PC 版と動作を変える必要があったのか？

関連する処理など

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,(.*)$/)) {
        return null;
    }
    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);

その他気付いたことなど

  • A要素(リンク)の場合、jQuery によってクリックイベントを発生（ .click() や .trigger('click')）させても、ダウンロードやページ遷移は行われない。
    これらを発生させたい場合には、MouseEvent を作成するか、DOM の .click() をコールする。