「iOS 6」を含む日記

はてなキーワード: iOS 6とは

iPhone Xでは昔のように、アプリのカードを長押しして出てくるバツボタンを押して強制終了になってて、これはすごく正しいデザインだと思う。だって強制終了っていうのは基本的には避けるべきことであって、iOSではそれほど大きな問題にはなりにくいとはいえ、うっかり強制終了してしまうような事故は避けたい。(ちなみに、アプリを強制終了するとバッテリーが長持ちするというデマがあるが、iOSの仕様をある程度知っていればそんな効果はほとんどないであろうことはわかるし、アップルも公式に否定している。)

ところが世の中は不条理なもので、アプリを強制終了したがる人たちがいる。それでそういう人たちが、「強制終了に手間がかかりすぎる」などと文句を言う。そのせいかどうかわからないが、次のiOS 12ではアプリのカードを上に弾くだけで強制終了してしまう、iOS 6から 10までの仕様に戻るらしい。

まったく困ったものである。この仕様のせいで、いったい何回、アプリを切り替えようとして不意にアプリが強制終了されたかわからない。

基本的に、同じ画面の同じ箇所から指を滑らせる操作では、縦の動きと横の動きに違う操作を割り当てるべきではない。片方のみに機能を割り当てて、もう片方は無割り当てが理想だが、それでも両方に割り当てるなら、非破壊的な機能でなければならない。例えばホーム画面では横スクロールの他に、縦にスワイプするとSpotlightが出てくるが、これは非破壊的だからまだマシだ。アプリの強制終了は、例えば何かの処理中だった場合に破棄されてしまうし、そうでなくても次回起動した時に前回の画面から再開できなくなる。

Appleも悪いが、とにかく、なぜかアプリをやたらと強制終了したがる人たちを撲滅しなければならない。

Permalink | 記事への反応(15) | 18:51

2017-07-26

■iOS 8 以前を使ってる人来て

Appleによると全ユーザーの内、

iOS10が86%、

iOS9が11%、

それより古いのを使ってるのはたったの3%だそうだ。

iOS8も7も6も全部含めて3%だ。

マジかよ。

ホントにたった3%かよ。

嘘くさいとすら思える。

本当です、アイフォーンならねってか。

ちょっと我こそはこの3%だと言う奴、出てきてくれ。

そしてなぜお前は3%でいるのか、3%であり続けるのか、その理由を教えてくれ。

その理由の如何によっては俺のアプリのiOS 6 サポート継続もやぶさかではないからさぁ！

Permalink | 記事への反応(0) | 23:05

2014-09-27

■iOS 8.0.2でバッテリが異常消耗すると思ったらやってみたほうがいいこと

病院に行け。神経系の。

アップデート後たった数時間でバッテリー持ちの違いが分かるわけがないだろ。

iOS 6の時もiOS 7の時もﾊﾞｯﾃﾘｰｶﾞｰとか言って大騒ぎしていた人は今すぐに。

Permalink | 記事への反応(0) | 08:53

2014-03-20

■（今さら）ドラゴンクエストモンスターズ　 スーパーライト 運営の酷さ

返金祭りで騒動を起こしたソーシャルゲームのサポートセンターとのやりとりがあまりにも酷いので、吐き出させて下さい。

何かと話題を振りまいたゲームですが、ユーザーありきのサービスであるはずがユーザー無視の最悪のサポート対応です。

※ソシャゲーに興味ない方は、あまり面白いものではないです。スルー推奨。※

以下に、ドラゴンクエストモンスターズ　スーパーライト（以下当アプリ）のサポート担当とのやりとりを記します。

経緯

私は、ドラクエは1から6までリアルタイムでやっています。

年代はお察しの通りで、FFよりドラクエ派でした。

今回ドラクエの名を冠したソーシャルゲームということでかなりの期待と

今までのドラクエへのお布施という意味も込め、当アプリ、金のロトガチャに 15,000円近く課金しました。

ところが、2月に虚偽表示による返金騒動があり、私もアップルストアに返金依頼をしましたが、

アプリの運営事業者から保障がすでに成された、との理由で返金を断られました。

実際に、当アプリ WEBサイトの告知で、アプリ内通貨であるジェムでの保障があったとアナウンスがありましたが、

私のiPhone5 (当時ios 6 → 現在7.1) では、アプリのタイトル画面から次の画面に遷移する際に、

「通信に失敗しました」というエラーが延々と出て次の画面に進めない現象があり、ジェムの受け取りが確認できていませんでした。

サポートとの受け答え

以下、私と「ドラゴンクエストモンスターズ　スーパーライト」運営事務局サポート担当者（以下サ）のやりとりです。

最初から最後まで、一ヶ月くらいかかっています。

私：今回の虚偽表示を受け、アップルストアに返金を希望したが、運営事業者と直接やりとりをしてくれとのことで断られた。返金を希望します。
サ：【5.バーチャルコインシステム】
　5.6 返金不可法令により認められる場合を除き、ユーザーは未使用のバーチャルコインについて返金を受けることができないものとします。
　上記より、返金はできません。
私：返金できないのは理解した。しかし「通信に失敗しました」とエラーがでて保障のジェムの確認ができない。
この時、私の環境がiPhone5 ios6 などの情報を伝える。推奨環境は満たしています。
サ：引継ぎコードを発行しました。再インストールして、コードを入れて下さい。

私：アプリを再インストールして、コードを入れて引継ぎをしたが、「通信に失敗しました」のエラーは変わらない。
　そもそもこのエラーの原因はなんですか？
私：（アプリのインストールもできて、引継ぎもできて、アプリ内の更新ダウンロードまでできるのに、起動の時だけ「通信に失敗した」というのはおかしいだろ。）
サ：引継ぎコードを発行しました。再インストールして、コードを入れて下さい。
私：前回も同じことをして状況は改善されませんでしたが、今回実行すると治る保障はあるのですか？
　そもそもエラーの原因も説明せずに、再インストールしろとは乱暴ではないのか？
サ：アプリをバージョンアップしましたので、改善されているかもしれないので再インストールして、引継ぎコードを入れて下さい。

私：アプリを再インストールして、コードを入れて引継ぎをしたが、「通信に失敗しました」のエラーは変わらない。
サ：ＯＳバージョンが推奨環境を満たしていないことを確認いたしました。
　つきましては、大変お手数ですがＯＳのバージョンを更新していただき、再度データ引き継ぎをお試しいただけますでしょうか。
私：（今までのメールを読んでない・・・？）
私：いい加減な回答をしないで下さい。以前連絡した条件で、推奨環境を満たしているでしょう。
　どうしてここまで滅茶苦茶な回答ができるんですか！ひどすぎます。こちらからのメール見てますか？
サ：ご連絡いただきました事象に関しましてお手数おかけしますが
　不要なデータを削除していただき、可能であればご利用環境以外の環境で改善されるかご確認いただけますでしょうか
私：他の環境はありません。でも最後にもう一度だけ、やってみます。

私：やはりダメでした。もう諦めます。
私：（もはや再インストールの作業も、引継ぎコードの入力も、このやりとりもめんどくさい・・・）
私：しかし、あなた方がやってきたことは、
　歴史ある「ドラゴンクエスト」ブランドの毀損です。
　今後どのように続けていかれるかは分かりませんが問題に対して原因を追求するような、
　真摯的な対応をとられる事を希望します。
　今まで長々とお付き合いいただきありがとうございました。

とメールを最後に送りました。それ以降、音沙汰はありません。

今までのサポートの経緯からすると当然でしょう。

上記のやりとりも最終的に私からのメールを以って「問題は解決した」と考えているのかと思うと、大変腹立たしいです。

サポートセンターでありながらユーザーから提示された問題を解決もせず、ただマニュアル的に受け答えしているだけです。

また、終わるにしても、普通の会社のサポートセンターならば、ましてや自社が起こした問題ならば、ユーザーから「もういい」と連絡があったとしても、

原因調査しますので、もうしばらくお待ちいただけないか、とか、どうにもならない場合は、お力になれず申し訳ございませんでした、

とお詫びの一文でも送ってくるのが普通かと思っています。

最後に

このやりとりから私が感じた事は、どこの国の誰がやっているのか分からないような受け応えをサポートセンターが行っている現実は、

運営事業者の根底の考え方がユーザーを大切にしていない、ということに他なりません。

このようなものが長く続くとは思えないし、また、続いてほしくもないです。

私はこのアプリをおすすめしません。これからも色々な問題を起こすでしょう。

これからゲームを始めようと思われている方は思いとどまって頂き、現在プレイされている方は、運営事業者は

ユーザーのことなどこれっぽっちも思っていないことをご理解頂ければ、幸いです。

このような運営事業者の横暴には、ユーザーが行動をもって示す事で対抗するしかないと思います。

感情的な乱文にて申し訳ございませんでした。

また、最後までお読み頂きありがとうございました。

Permalink | 記事への反応(3) | 16:17

2014-02-27

■Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Appleのbugがあるんだ。：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&amp;amp;hashCtx, &amp;amp;hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&amp;amp;signedHashes);
 SSLFreeBuffer(&amp;amp;hashCtx);
 return err;
}(Quoted from Apple's published source code.)

(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね！

この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」

今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。
ChromeとFirefoxはSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。
君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。
(訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙なバグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。：

extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}

もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ！！！

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

Permalink | 記事への反応(0) | 01:12

2013-10-26

■http://anond.hatelabo.jp/20131026214407

アメリカ合衆国アラスカ州の話だが、

「アップルの地図アプリ」で空港滑走路への突入が続出

　アラスカの国際空港で、アップルの地図アプリに従った運転者が滑走路に進入するという事件が連続して発生した。
　「iOS 6」の地図アプリが、英国のロンドンでなく、カナダのオンタリオ州にあるロンドンに人々を誘導して不興を買ったことを覚えているだろうか。
　アラスカの国際空港では、もっと大変なことが起きた。アップルの地図アプリに従ったドライバーが滑走路に進入するという事件が、連続して発生したのだ。
　『Alaska Dispatch』紙が9月24日付けで掲載した記事によると、アップルの地図アプリは、東ランプ経由で誘導路B（BravoのB）に入るよう指示したという。これはパイロットが滑走路にアクセスするところだ。そこからだと、ターミナルは滑走路のすぐ向こう側に見えるので、ドライバーは、（通過したすべての道路標識を無視して）目に見える手がかりに従い、真っ直ぐターミナルに向かったという。
　この出来事はまず9月6日に起こり、9月20日にもう一度発生した。Alaska Dispatch紙によると、最初の事件の後、アップルはこの問題に対処すると述べたという。しかしその後も、ハイヤーの運転手が、空港警備と警察によって包囲されて腰を抜かすという事件が発生した。現在は、問題が解決されるまで、一時的にバリケードが設置されているという。