Facebookにブロック解除のバグ――80万人に影響あった(修正済み)

Facebookで誰かをブロックした場合、ずっとブロックし続けていたいと思うはずだ。ともかく別の決定をするまではそうだ。Facebookがさきほど明らかにしたところによると、80万人のユーザーが「ブロックリストの一部の相手が勝手に解除されてしまう」」というバグの影響を受けたという。

Facebookのブログによれば、このバグは5月29日から6月5日まで存在した〔現在は修正ずみ〕。

ただし、このバグのせいで、(もしブロックした相手がそれ以前に友達だった場合)友達として復活するようなことはない。つまりバグの影響を受けたユーザーであっても、「友達のみ」で投稿した記事がブロック相手に読まれることはない。しかしこれらのブロック相手が友達リクエストを送ってきたり、メッセンジャーで連絡してきたりすることは可能だった。

Facebookではこのバグが起きた経緯についてあまり語っていないが、ともあれこのバグの影響を受けた可能性のあるユーザーには通知を送っている(上のスクリーンショット)。

アップデート: FacebookではTechCrunchのJosh Constine記者にTwitterで若干の説明を追加している。

ジョッシュ、こうしたブログ記事でどの程度まで詳しく技術的詳細を説明すべきか、その判断はいつも難しい。今回のバグについて前後関係をさらに付け加えるなら(バグあったのは)、ユーザーのソーシャル関係データの主要な部分を格納しているassociationsだ。これはユーザーの投稿を誰が見ることができるか、ユーザーに対してどのようなアクションを取ることができるかを決定している。今回のバグはassociationsデータの一部を誤って削除してしまったというものだ。これによりFacebook本体とMessengerで一部の相手のブロックが解除されることになった。

〔日本版〕スクリーンショットを見ると、バグの影響を受けたユーザーにはMessengerで注意が送信されている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

見捨てられるPenryn世代: Intelは古いチップのSpectre対策を中止

チップの欠陥MeltdownとSpectreに対して、引き続き行われているパッチ努力の一環としてIntelは先月、2005年までさかのぼって開発コードYorkfield以降のプロセッサーにも修復を適用する、と示唆した。しかし最近のガイダンス文書によると、これらの古いプラットホームの多くは結局、修復を受けないことになった。

具体的には、Spectre Variant 2(変種2)のための対策は、チップの世代で言ってBloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, SoFIA 3GR, Wolfdale, Yorkfieldに対しては行われない。(IntelのコードネームのリストはWikipediaにある。)

変種2はブロックや回避がいちばん困難な欠陥なので、対策も難しい。マイクロコードのアップデートで何かをコピペして終わり、という仕事ではない。

そのガイダンス文書(PDF)には、修復対応をやめる理由が書かれている:

  • マイクロアーキテクチャの性格により、変種2を緩和する機能の実効的な実装ができない
  • システムソフトウェアの商用サポートが不十分
  • 顧客からの入力によると、これらの製品の多くが“クローズド・システム”として実装されているので、これらの脆弱性への露出の可能性が低い。

言い換えると: それは超難しい、サポートが薄い、そしてバグが悪用されるような使い方をしている人がとても少ない。

そもそもそれら古い機種は、リストが膨大であるだけに、Intelとしてもリーズナブルな後退をした、と言えるだろう。しかしそれでも、システムの管理者は、これらの世代のチップが自分たちのシステムの中で外部者に対してむき出しになっていないか(悪用の可能性がないか)、チェックしたいだろう。

そしてユーザーに関しては、Core 2 Duoに代表されるPenryns世代は、まだ古いラップトップを使っている人が少なくないだろう。2008年には、それがIntelのすべてだった。ぼくみたいに、古い機種に愛着があって捨てられない人は、重要な仕事をその上でやらないようにしよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Intelは今年後半に発売するチップにSpectreとMeltdownのハードウェアレベルの対策を導入

SpectreとMeltdownはハードウェアの設計レベルのバグなので、簡単なパッチなどでは修復できないことが明らかだった。しかし幸いにも、これらに対して十分な時間を投ずることのできたIntelは、今年後半に発売する新製品のチップに、その欠陥からユーザーとアプリケーションを保護する、ハードウェアのアーキテクチャレベルの改良を盛り込んだ。

このニュースは、CEOのBrian Krzanichが同社のブログ記事で発表した。パートナー数社に対する感謝の言葉に続いて彼は、過去5年以内の感染製品に対しては、それらの動作をバグから守るソフトウェアのアップデートを行った、と述べている。もちろんその効果に関しては議論の余地があるし、パフォーマンスへの影響も無視できないが、なにしろ一応、バグフィックスがあることはある。

本当は、互いにやや関連するバグが三つある: Spectreには変種1と変種2と変種3があり、研究者たちは変種3をMeltdownと呼んでいる。いちばん対策が難しいと思われているのが変種1で、Intelにもそれに対するハードウェアのソリューションはまだない。しかし変種2と変種3は、今回対応できた。

“プロセッサーのさまざまな部分の設計を変えて、変種2と3の両者に対して防御するパーティショニングにより、新たなレベルの保護を導入した”、とKrzanichは述べている。Cascade Lake Xeonと第8世代Coreプロセッサーにこれらの変更が含まれ、2018年の後半に発売される。現状では情報はまだ漠然としているが、リリースが近くなればIntelは大宣伝を開始するだろう。

なお、第1世代Coreまでさかのぼる古いハードウェアも、マイクロコードがアップデートされる。NehalemやPenrynをおぼえておられるだろうか? それらも、いずれはパッチされる。驚いた方もおられると思うが、大企業や政府機関ではまだまだNehalemのシステムが使われている。たとえばエネルギー省のどこかでは、Pentiumの上で動くWindows 98SEシステムが今でも使われているだろう。

この発表に関してユーザーがすべきことは何もないが、コンピューターとOSを最新の状態に保つことは必ずやるべきだ。そして、分からないことがあればカスタマーサービスに尋ねよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

iOSとmacOSがユニコード文字の爆弾対策を完了、今日からダウンロードできる

先週本誌が報じた、特定のユニコード文字でAppleのオペレーティングシステムがクラッシュするという問題を今日(米国時間2/19)Appleは、iOS 11.2.6とmacOS 10.13.3でフィックスした。どちらも今日からダウンロードできる。

Aloha Browserが通常の開発過程で見つけたこの問題は、英語以外の文字の取り扱いがお粗末だった、というバグだ。われわれもiOSとmacOSのさまざまなアプリで、それらが直ちにクラッシュすることを確認した。この脆弱性は、CVE-2018-4124という名前でMITREに載っているから、興味のある方はご覧いただきたい。

Appleは先週本誌に、フィックスを近く提供する、と述べた。実際にはそれは、ベータではすでにフィックスされていた。しかしプロダクションバージョンのパッチは、ほんの数分前にリリースされたようだ(iOSmacOS)。Appleはその魔の文字を、“ヒープの破損”に導く“悪意ある人工的文字列”〔たまたまの自然発生ではない〕、と呼んでいる。macOSの10.13.3より前にはないようだから、古いバージョンのユーザーは安心だ。

iOSのパッチは、“一部のサードパーティアプリが外部アクセサリに接続できない問題”もフィックスしているが、これはテキスト爆弾問題とは無関係だ。

どちらのアップデートも、今すぐダウンロードできるはずだ。なまけると、またいたずらに遭うかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

iPhoneやMacのアプリがクラッシュするユニコード文字のバグ、Twitter上でいたずらが急増

【抄訳】
昨日(米国時間2/15)本誌TechCrunchが報じたユニコードのバグを悪用して、iPhoneやMacの上で動いているアプリを一瞬でクラッシュさせる馬鹿たちが急増している。その様子は昔のAlt+F4のいたずらや、スクリプト坊やの愚行に近いが、結果は、迷惑行為ですむものから、デバイスが使用不能になるのまで、さまざまだ。

そのバグは、南インドのテルグ語の二つの文字を表示しようとすると多くのiOSやMacのアプリ/アプリケーションをクラッシュさせる。その文字を見ないようにすればいいのだが、誰か悪意のあるやつがメールや通知などで送ってくると避けられない。

大量のTwitterユーザーが昨日(きのう)からその文字に、“read this to log off instantly”(これを読めば一瞬でログオフできる)とか“retweet this to crash anyone using an Apple device”(これをリツイートすればAppleのデバイスを使っている誰でもクラッシュする)、などのメッセージをつけてツイートしている。しかし幸運にも、彼らのフォロワーは少ない。でも、@のリプライや、ツイートをいいねした誰かのハンドルにその文字があれば、今開いているアプリは即死する(MotherboardのライターJoseph Coxが、自分の痛い体験からこのことを学んだ)。本誌が知ったかぎりでは、アプリは最初から再インストールしないと正常に動作しない。何度も何度もやられているときは、再インストールに時間がかかってたいへんだ。

Twitter上では、あるセキュリティ研究家が自分のUberのハンドルにその文字を加えて実験をした〔下図〕。“スマートフォンがクラッシュすると次のドライバーに回されるが、それもまたクラッシュする。まるでUberのルーティング・ワームのように”、と彼は書いている。今Uberに問い合わせているので、返事があったらこの記事をアップデートしたい。

【中略】
〔このバグを起こす文字は二文字よりももっと多い…Mozillaの技術者の実験より〕

Appleは、もうすぐ“マイナーアップデート”(小数点以下のバージョンナンバーのアップデート)をリリースすることを確認した。ただしそれがiOS 11.2.6になる、とは言わなかった。なお、iOS, tvOS, macOS, watchOSの現在のバージョンでは、このバグは解消しているそうだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

あるUNICODE文字がAppleデバイス上でアプリを破壊する――iOS、Mac、Watchの主要ソフトすべてに影響

TechCrunchはAppleのデバイスに深刻なバグがあることをつかんだ。

モバイルブラウザを提供しているAloha Browserの開発チームは多言語対応のニュースフィードを開発中に特定のUNICODE文字がAppleのアプリをクラッシュさせることを発見した。これはAppleのデフォールトのSan Franciscoフォントを利用している場合に発生した。アプリのクラッシュは英語以外のUNICODEの2文字によって引き起こされ、iPhone、iPad、Macの各機種のアプリばかりでなく、WatchOSでテキストを表示する場合にも影響する。

これらの2文字がアプリ内で表示されるとそのアプリは即座にクラッシュする。多くの場合、アプリは再起動できず、再インストールが必要になる。 TechCrunchは旧バージョンのiOSを搭載したiPhone、2台とiOS 11.2.5を搭載したiPhone、High Sierra搭載のMacBook Proそれぞれ1台ででこの現象を再現することができた。

このバグによってクラッシュするソフトウェアにはMail、Twitter、Messages、Slack、Instagram、Facebookなどメジャーなアプリが含まれる。われわれのテストではMac向けコピー&ペースト・プラグインのJumpcutもクラッシュした。当初、 Mac向けChromeは影響を受けないかと思われたが、やはりクラッシュした。Chromeも問題の文字を表示したアプリもその後起動せず、アンインストールと再インストールを必要とした。OSがクラッシュし、リスタートする場合もあった。

TechCrunchはAppleにバグフィックスのスケジュールを問い合わせている。新しい情報があればアップデートする予定だ。Aloha Browserのチームによれば、Appleもこのバグを認識しているという。Alohaのチーム以外からもバグ報告が上がっているもようだ。

Appleがテキストに含まれる文字が原因でアプリがクラッシュする「テキスト・ボム」現象に悩まされるのは今年に入ってこれで2度目だ。最初は1月にソフトウェア専門家のAbraham Masriが発見したiOSのバグで、特定のURLを含むテキストメッセージを送りつけられるとすべてのiPhoneがクラッシュした。これより前、2016年には、 ユーザーがCrashSafari.comのURLをクリックするとiPhoneやSafariがクラッシュした。2015年にはUnicode of Deathと呼ばれる現象が起きている。これはUNICODEのアラビア語の文字一部がiPhoneのメモリを占有して障害を起こすバグだった。今回われわれは「死のUNICODE 2.0」に遭遇しているようだ。

今回のテキスト・ボムは主要なアプリすべてに影響するため、原因となるUNICODE文字がソーシャルメディアその他のチャンネルを通じて広く拡散されると個人や組織を狙ったメールやテキスト・メッセージによって大混乱が引き起こされる可能性がある。バグは大部分のAppleのデバイスの上で作動する大部分の主要アプリをクラッシュさせる。早急にバグフィックスが提供されないと大問題になりそうだ。

[アップデート: Appleは早急にバグフィックスを提供することを確認した。このバグは現在のバージョンに影響しているものの、iOS、tvOS、macOS、 watchOSのそれぞれベータ版ではすでに修正されている。]

画像: Bryce Durbin

[原文へ]

(翻訳:滑川海彦@Facebook Google+

Facebook Messengerのキーボードがクラッシュする――iOSアプリのバグをFacebookも確認

iPhoneでFacebook Messengerを利用するとキーボードがクラッシュするバグに悩まされているユーザーが相当いるようだ。

この不愉快な現象はiPhoneのMessengerアプリで会話をタイプしようとすると発生する。一部のiOSデバイスの場合、チャットの吹き出しに数語タイプした後アプリがフリーズする。しかし正常に動作するデバイスも多い。この問題はMessengerで会話することを非常に困難にしている。

TechCrunchのJosh Constine記者もこのバグの影響を受けた一人だ。Joshによれば「アプリを再起動しても治らない」という。アプリを削除して再インストールしたユーザーもいるが、やはり効果がなく、バグは再現した。

TechCrunchの取材に対してFacebookは「調べているところだ」と問題が起きていることを確認した。しかし今のところFacebookから¥公式な発表はなく、原因やバグフィックスが提供される時期などは不明だ。

Messengerは世界でもっともポピュラーなアプリの一つで、アクティブ・ユーザーは10億人以上いる。バグが発生するのは一部のユーザーのiOSデバイスだけのようだが、これだけメインストリームのアプリではTwitterでユーザーが強い不満を訴える騒ぎになるには十分だった。

今夜、Facebook Messengerが問題を起こしている。数語タイプするとそれ以上何もタイプできなくなる。スマートフォンを再起動したりアプリを再インストールしたりしてみたが効果がなかった

Messengerのユーザーの伸びはめざましく、すでに10億以上だが、複雑になりすぎたという批判を受けて今年はシンプル化を目指すとしている。Messenger担当のチーフ、David Marcusは今週、Messengerには機能を詰め込み過ぎたと認め、サービスから余計なものを取り除いてスリム化するためにチームを作ったと述べている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

スペクター! メルトダウン! カーネル・パニック!――今回の脆弱性はほぼ全員に影響が及ぶ

新たななコンピューター脆弱性をめぐって昨日(米国時間1/3)から発生している記事、声明、論文の雪崩に当惑している読者も多いだろう。これらには相互に矛盾する主張も多い。ほぼあらゆるコンピューターとOSに影響するMeltdownとSpectreという2つの欠陥は一体どんなどんなものなのか? 昨日の記事に引き続き、さらに詳しく現在判明している情報を紹介する。

どんな欠陥なのか?

要約:コンピューター・アーキテクチャーの本質的な欠陥により、プロセッサーのもっとも深いレベルに位置する重要情報へのアクセスが可能になる。


セキュリティー専門家は公式文書を発表して問題を確認している。 深刻な2つの脆弱性にはそれぞれ名前とロゴが与えられている(上の図で左がMeltdown、右がSpectre)。この欠陥は現在利用されているほとんどあらゆる中央演算処理装置―CPUに影響を与えている。

これらはCPUの物理的機能に関連する問題ではないし、WordやChromeにもときおり見られるようなプログラミングのミスによるソフトウェアのバグでもない。これは現代のCPUのアーキテクチャーそのものに内在する問題だ。

現代のCPUアーキテクチャーにはあらゆるデータが生で、つまり暗号化されずに処理される部分が存在する。このスペースは当然不可侵の領域でなければならない。CPUのアーキテクチャーの根本をなす部分、カーネルがそうした領域だ。またシステム・メモリー中にも他のアプリケーションからアクセスできないよう慎重に隔離された領域が存在する。これらの領域内のデータは機密であり、他のアプリケーションやプロセスからアクセスできないよう強力な保護壁が設けられている。

MeltdownとSpectreは セキュリティー専門家が発見した2つの攻撃手法。これらはデータ保護機能を回避してコンピューターが処理するほとんどあらゆるデータへのアクセスを可能にする。つまりパスワード、暗号化データ等の決定的に重要な情報もすべて他のプロセスからアクセス可能となる。

MeltdownはIntel CPUに固有の弱点で、カーネル・メモリー中のデータを保護する機能を迂回する。Intelプロセッサーではカーネル中のあるプロセスが偶然他のプロセスに干渉したり、悪意あるソフトウェアが権限のないデータにアクセスすることを防ぐため、アプリケーション領域とOS領域の間に障壁が設けられている。Meltdownはこの障壁を迂回して保護を無効化する。

SpectreはIntel、AMD、ARM各社のプロセッサーに影響する。つまりデスクトップ・コンピューターだけでなく、各種のモバイル・デバイスその他なんであれCPUが内蔵されているすべてのデバイスが対象となる。つまりスマート・サーモスタットや赤ちゃん見守り用ウェブ・カメラも含まれる。

SpectreはMeltdownとは異なり、アプリケーション間に設けられている障壁を迂回するためにある種の巧妙な罠を仕掛ける。これにより通常であれば他のプロセスからアクセスすることが不可能な領域にあるデータをアプリケーションに暴露させる。現代のコンピューターに多く見られるマルチコア・アーキテクチャーをベースにしているため実行はMeltdownより困難だが、同時にこの脆弱性を取り除くことを一層困難にもしている。

誰が影響されるのか?

要約: コンピューターのユーザーほぼ全員。


2011年に製造されたチップもテストされ、これらの脆弱性を持っていることが確認された。理論的には1995年以降に製造されたCPUすべてが影響を受けているとされる。

繰り返すがMeltdownとSpectreはCPUアーキテクチャー上の弱点であり、チップ・メーカー側の人為的ミスによるバグではない。またWindows、OS X、AndroidはじめあらゆるOSプラットフォームが等しく対象となる。

理論的にはデスクトップ、ノート、サーバー、スマートフォン、組み込みデバイスその他あらゆるデバイスが影響される。簡単にいえば、テストの結果安全だと確認されたプラットフォーム以外はすべてこれらの脆弱性を持つと考えるべきだろう。

Meltdownはまたクラウド・プラットフォームにも影響する点で深刻だ。ただしMeltdown攻撃をリモートで実行するのは非常に困難だという。これはクラウド・サービスにとってグッドニュースだ。

対策はあるのか?

要約:: 完全にではないが修正できる。ただし時間がかかる。


上述のように影響されるデバイスの数は膨大だが、だからといってこうしたデバイスが無防備だというわけではない。またIntel、AMD、ARMその他のチップ・メーカーは数か月にわたって「緩和策」(簡単にいえば絆創膏)を開発してきた。

カーネルのメモリ間の障壁を強化することがMeltdown対策となる。技術用語では「カーネル・ページ・アイソレーション」という。ただしこれには副作用もある。現代のCPUアーキテクチャーはカーネルの動作にある前提を設けている。この前提を変えることはCPUの処理効率を落とすことになる。

Meltdown脆弱性の修正策がチップのパフォーマンスに与える影響は少ない場合で5%、最大で30%に上るものとみられている。いずれにせよなにがしかのパフォーマンス低下は避けられない。しかし脆弱性を取り除くことができるのであればやむを得ない代償だろう。

これと違って、Spectreには当分の間根本的な解決策は得られそうにない。Spectre攻撃はCPUの物理的特性に極めて密接に関連するため、セキュリティー専門家もソフト的にこれを完全に避ける方策を発見することはできなかった。いくつかの回避策が提案されているものの、結論はこうだ。

前節で紹介した一時的回避策は現実の攻撃を短期間防止する役に立つはずだ。しかし今後書かれるコードについてはもちろん現に存在するコードについても、どんな構成であればCPUにとって安全であるか(それとも危険であるか)を判断する方法は知られていない。

今後どのような対策が取られるか予測することは難しいが、もっとも大きな被害をもたらしそうな攻撃を防止するためのソフトウェアのアップデートが相次ぐだろう。MicrosoftはすでにWindows OSに対してアップデートをリリースしている。ARMも一連の緩和策を用意している。Amazonはクラウド・サービスの膨大なサーバー群をアップデート中だ。【略】

ひとつはっきりしているのはデバイスのリコールはないということだ。Samsungのスマートフォンのバッテリー問題のように、問題が特定のハードウェアの特定の部品にある場合、リコールはあり得る。しかし今回の問題で影響されるのは何億ないし何十億にも上る膨大なデバイス群なのでリコールはあり得ない。

なぜ今突然報道されたのか?

要約: チップ・メーカーは来週合同で発表を予定していたがメディアに先回りされた。


実はチップメーカーは数か月前にMeltdownとSpectreという脆弱性について報告を受けていた。セキュリティー専門家は以前からこの問題に注目し研究を続けていた。脆弱性の内容自体は秘密にされていが、理由不明のアップデートが相次いだことで、外部にも少しずつ情報が漏れ始めていた。

仮にセキュリティー専門家が脆弱性を発見すると同時に、たとえばTwitterでそれを公開したとすれば、CPUメーカーよりむしろ悪意あるハッカーを利するだけに終わっただろう。セキュリティー上の問題では情報は「責任ある公開」が求められる。つまりまずそのプロダクトを提供しているメーカー、ベンダーに秘密に通知し、必要なら対応策の開発に協力するわけだ。

今回のケースではGoogleは数か月前にIntelにコンタクトを取っている。もちろん程度の差はあれ、問題の存在を知っていたメーカーは多いはずだ。Microsoftが理由を明かさずにパッチをリリースしていたのもその一例だろう。Linuxの各種ディストリビューションも、脆弱性については詳細を示さないまま、アップデートを行っていた。

セキュリティー問題ではメーカーやベンダーが対応策を得て密かにアップデートを完了して初めて脆弱性の存在が告知されるのが通例だ。今回もその方式を取ることが予定されていた。

しかしThe Registerがいくつかの情報をつなぎ合わせスクープ記事を出した。そのためIntelは来週に予定していた共同発表の前に急きょ「報道は不正確だ」という反論の声明を発表するなどの対応に追われることになったわけだ。

The Registerはセキュリティー問題に関する通例を守るべきだったという声もたしかにある。しかし一方でIntelなどの巨大企業が情報を全面的にコントロールするという状況も好ましくないだろう。もしスクープがなければこの問題に対する関心も現在のように高まることはなかったはずだ。

いずれにせよ、セキュリティー専門家はSpectreを説明した論文の結論として次のように述べている。

この論文で検討した脆弱性は、他の多くの脆弱性と同様、パフォーマンス向上を至上命令として開発を行ってきたテクノロジー業界の長い伝統に根ざすものだ。この結果、CPU、コンパイラ、ドライバー、OS、その他すべての重要な要素が最適化のために複雑にレイヤー化され、セキュリティー・リスクを生じさせることとなっている。パフォーマンス向上の代償としてセキュリティーを犠牲にするこのようなデザイン手法は見直しの時期に来ている。多くの場面でセキュリティーの最大化を目的とする実装が求められるている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

[お知らせ]12月2日の早朝からiPhoneが突然クラッシュしている人はこの記事を読んで

【抄訳】
今朝(12月2日)あなたのiOSデバイスが勝手に、ランダムっぽく、リブートしただろうか? それは、あなただけではないのだ。

今週のAppleは、ソフトウェアの面倒なバグに悩まされた。最初は、macOSのとんでもない誰もがrootでログインできるバグ、そして今度は、世界中のiOSデバイスをクラッシュさせる不具合だ。

みんなが言ってる現象はこうだ: 通知システムの異状のため、ホーム画面を管理するアプリspringboardがクラッシュする。そしてデバイスのリセットのような状態になり、その後PINの再入力を求められる。

運動とか医者通いとか、毎日のスケジュールで通知をくれるアプリがクラッシュを惹き起こしているようだが、しかもそれは、システムの時計が2017年12月2日の午前0時15分を過ぎてからしか起こらない。毎日のスケジュールで通知するアプリは全員が使ってるわけではないから、この異状も全員には起きてない。しかしそれでも、クラッシュの引き金を引くアプリを具体的にすべて特定することは難しい。多すぎるから。

回避策: デバイスを立ち上げて数分間無事なあいだに、毎日通知をくれるアプリの設定の「通知をする」のチェックを外す。

(サードパーティのアプリの通知をすべてoffにして、ひとつひとつonに戻してみる、という突き止め方もある。相当面倒だけど。)

アップデート: 上記により、デバイスがリセットしなくなったら、iOSをアップデートする。AppleはiOS 11.2を公式にリリースしているが、これには問題がないようだ。でもアップデートするためには、、まずデバイスを安定化しなければならない。11.2にアップデートしたら、すべての通知をonにしてよろしい。

誰かが言ってる、システムクロックを12月2日以前に戻すという方法は、やってはいけない。暗号や証明など、システムの重要な機能はシステムクロックに依存しているから、日付時刻を勝手に変えたら、iMessageやゲームなど、そのほかのアプリの動作も狂ってしまうだろう。

2017年12月2日の午前0時15分を過ぎてもデバイスがクラッシュしなかった人は、何もしなくてよい。そんな人は、毎日通知をするアプリを使って(動かして)いないはずだ。なお、iOS 11.2のベータを使ってるユーザーにも、この異状は起きていない。

【中略】

【後略】

[原文へ]
(翻訳:iwatani(a.k.a. hiwa