ハクソク

世界を動かす技術を、日本語で。

Appleプラットフォームセキュリティ（2026年1月）[pdf]

114日前原文(help.apple.com)

概要

  • 本文は破損または不正なデータのため、内容の解析が困難
  • 文字化けや制御文字が多く、通常のテキストとして認識できない
  • 有効な情報や意味のある文章はほとんど含まれていない
  • 具体的なテーマやトピックの特定が不可能
  • 修正や再送信が必要な状態

文字化けデータの解析について

  • ファイルやテキストが破損 している場合、正しい内容の取得が困難
  • 文字コードの不一致 が原因で、意味不明な記号や制御文字が表示されるケース
  • 内容の復元 には元データや正しいエンコーディング情報が必要
  • 再送信や再取得 を推奨
  • 技術的なサポート や管理者への連絡が必要な場合もあり

文字コードのトラブルシューティング

  • 一般的な文字コード： UTF-8、Shift_JIS、EUC-JP
  • テキストエディタ で文字コードを切り替えて再表示を試行
  • ファイル名や拡張子 も確認ポイント
  • オンラインの文字化け修復ツール の活用
  • 再取得・再送信 が最も確実な解決策

正しいデータ送信のポイント

  • 元データの文字コード を確認
  • テキスト形式（.txt, .md など） で保存
  • コピーペースト時の変換エラー にも注意
  • メールやチャットツール の送信設定も確認
  • 問題が解決しない場合 はサポート窓口に相談

ご質問や再送信があれば、お気軽にお知らせください。

Hackerたちの意見

個人のセキュリティやオペレーションセキュリティを気にしてるテック企業がまだ一つでも残っててよかった。

262ページもあるのか!!! 時間が経つにつれて、いろんなSoCがセキュリティ面でどう進化してきたかを見るのは面白いね。

ウェブ版: https://support.apple.com/guide/security/welcome/web

└

それが2024年12月ね。

A19とM5プロセッサーにMIE（EMTE）が最近登場したばかりだけど、MacOSやiOSはそのハードウェア機能をどれくらい活用してるんだろう？ 効果が見えるのに数年かかるのか、それともMIEは今すぐにでもしっかりとした保護を提供してるのかな？

└

iOS 26のカーネルアロケータやほとんどのシステムプロセスにはMIEが有効になってると思うし、libpas（WebKitのアロケータ）もそうだから、かなりのことをやってるよね。

└

昨日、これに関する動画を見てたところだよ：https://www.youtube.com/watch?v=5McB6-2r-ds AppleのMTEの実装は、GrapheneOSや高度なセキュリティが有効な標準のAndroidに比べて、範囲がかなり限られてるね。ハードウェアに負担がかかるし、パフォーマンスも落ちるから。もっと速くなれば、どこでも同期MTEが使えるようになるかもしれないね。でも今のところ、Lockdown Modeみたいなものを有効にしてもMTEがどこでも強制されないのは不思議だと思う。個人的には、そうすべきだと思うけど。MTEをグローバルに有効にすることでアプリのクラッシュやパフォーマンスの低下を受け入れる人は、そういう妥協を受け入れられると思う。

でも、ソフトウェアは全部クローズドソースだし、これらのセキュリティ主張を確認する機会はほとんどないよね。暗号化キーも持ってないから、実質的にデータは自分の管理下にないってこと。もしセキュリティがちゃんとできてる（または少なくとももっと良い）ものを見たいなら、GrapheneOSプロジェクトをチェックしてみて。

└

GrapheneOSも暗号化キーはくれないんだよね。公式版を使ってると、アプリ開発者が許可した範囲以上のデータをデバイスから取り出す方法はない。つまり、自分のデバイス上のデータを所有してないってこと。バックアップはAppleのよりも効果が薄いし、改善するって言ってるけど。開発者たちは、アプリがユーザーのデバイスの信頼性を確認する権利があると考えてるみたいで、キーを信頼するアプリをサポートする提案をしてるんだよね。自分のフォークを作って自由を守ってるユーザーを締め出す形になってるのが残念。セキュリティ意識の高い人たちが「AOSPセキュリティモデル」に固執してるように見えるけど、その多くのセキュリティが実はユーザーからアプリを守るためのものであることを理解してないか、無視してるのが悲しい。アプリのサンドボックス化は素晴らしいけど、adbシェルみたいな不便な方法でも、アプリデータを見れるべきだと思う。1. https://grapheneos.org/articles/attestation-compatibility-gu...

└

そうだね、これをどうやって確認できるの？三文字の機関がアクセスできないって誰が言ったの？

たまに、これらのセキュリティ機能がパフォーマンスにどれくらいのオーバーヘッドをかけてるのか気になることがある。セキュリティ対策ありなしでベンチマークを見てみたいな。

└

シリコンに組み込まれてる機能が多いから、直接比較するのは難しいよね。

└

パフォーマンスに影響を与えたのは、割り当てられたメモリをゼロにすることと、Spectre/Meltdownの修正だったかな。新しいアプリの初回起動は署名を確認するために遅いしね。今の全ディスク暗号化はかなり速いけど、暗号化されてないものよりは少し遅いかも。元々のFileVaultはディスクイメージを使ってたから、もっと遅かったよ。

Appleのプライバシーとセキュリティへの取り組みは本当に素晴らしいよね。これって、彼らが独自に活かせる戦略的なプレイでもあるし。GoogleやMetaは広告を見せないといけないからプライバシーを守れないけど、Appleはハードウェア会社って感じがする。

└

さらにクールなのは、Appleがアメリカの連邦政府による監視のためのバックドアを隠すことにコミットしてることだよね。「https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...」AppleはArsに提供した声明で、アメリカの連邦政府が「情報を共有することを禁止した」と認めてるけど、Wydenが連邦政府を暴露したことで、Appleは透明性報告を更新して、次の報告書ではプッシュ通知に関するリクエストを詳しく説明することになるみたい。

└

Tim Cookがトランプに金の延べ棒を渡して、一緒に食事したり踊ったりしてる間に、人々がアイスに殺されてるのに、こんな企業のBSに騙される人がいるのが本当に信じられないよ。

└

modelessが今日の早い時間にこの記事にリンクしてたよ。「https://james.darpinian.com/blog/apple-imessage-encryption/」私の現在の理解はこうだね：1. Googleはメッセージの暗号化バックアップとe2e暗号化をデフォルトにしている。2. Appleはメッセージのe2eeだけをデフォルトにしていて、大きなバックドアが残っている。3. 消費者は自分のデバイスでADP（高度なデータ保護）を有効にすることでそのバックドアを閉じることができるけど、99.9%の人がそのバックドアを閉じないから、結局iMessageで送るメッセージはAppleに常にアクセスされると思っておいた方がいい。全体的に見ると、Googleの方がプライバシーに関してはAppleよりも良いとは思わないけど、Appleのこの選択は彼らのプライバシー重視の姿勢と矛盾してるよね。

└

Appleは広告を出してるよ。App Storeを見てみて、Apple Mapsも広告を展開する予定だし。

└

結局、彼らがあなたの電話に何を入れられるかをコントロールしているから、すべてが調整されているんだよね。LAで示されたように、これは市民権に大きな影響を与え始めてる。

└

でも、今やAppleは広告会社みたいなもんだよね。

└

Appleのセキュリティエンジニアリングとアーキテクチャの責任者が話している詳細を知りたいなら、https://www.youtube.com/watch?v=BLGFriOKz6U&t=1993s を全部見ることをおすすめするよ。特にタイムリンクされた部分が面白いからさ。 :)

└

消費者ユーザーにとって、iPhoneとPixelやSamsungデバイスの本当の違いは何なのか、誰か説明してくれない？ すべてのサービス、プッシュ通知、デバイスのバックアップに関して。どちらもセキュリティを約束してるし、Appleはある程度のプライバシーも約束してる。Googleは暗号化キーを保存するし、AppleもADPにオプトインしない限り同じだよね。Facebook Messenger（転送中と保管中は暗号化されてるけど、Metaが読める）とTelegram（プライベートチャットを始めない限りTelegramがキーを持ってる）に似てるのかな？ PixelにはiPhoneにはない機能もあるよ。例えば、地元の基地局があなたのIMEIを拾ったときに通知が来るとか。まあ、どれもやってることだから意味はないけど、2Gを避けるためにより高いレベルのセキュリティを有効にすることもできる。意味があるかは分からないけど、あったらいいなって感じ。

└

Appleにすべてのプライベートデータを渡すのは「プライバシーとセキュリティ」じゃないよ。 https://news.ycombinator.com/item?id=39927657

Appleがあなたのアカウントに関連付けているデータのダウンロード可能なコピーをリクエストできるよ。詳しくは https://privacy.apple.com を見てみて。これには、iCloudからすべての写真を指定したサイズのチャンクで取り出すことが含まれるらしい。iCloudのウェブインターフェースを使ってダウンロードするより、ずっといい選択肢だと思う。ウェブインターフェースだと、一度に1000枚までしかダウンロードできないし、速度もイマイチだからね。

AppleがiPhoneをこういう風にマネタイズすることにしたのは残念だよね。ユーザーが自分の好きなソフトウェアをインストールする能力をコントロールするなんて。これが「もっと安全になる」っていう議論は無視するとしても、Appleの許可を求めずに自分のコンピュータを使いたいパワーユーザーに対して明らかに失礼だよ。彼らのセキュリティ主張は確かに一理あるけど、プライバシーに関する議論にはあまり真剣に受け取れないな。私たちの選択肢は、(A) ユーザーのインタラクションや活動を追跡してマネタイズされたOS、または (B) デバイスにソフトウェアをインストールする基本的な行為をマネタイズするもの、どちらも最悪で、より安全かもしれない選択肢のためにオープンな選択肢を諦めるのは難しいよ。

└

「もっと安全になる」っていう議論は無視するとしても、Appleの許可を求めずに自分のコンピュータを使いたいパワーユーザーに対して明らかに失礼だよ。彼らのセキュリティ主張は確かに一理あるけど、私はそれが正当だとは思わない。まず、macOSは自分のアプリケーションをインストールする自由を提供しているし（ただし、クアランティン属性が設定されている場合は署名と公証が必要）、Macが大量のマルウェアに侵されているわけじゃない。次に、App Storeは詐欺だらけだから、App Storeが安全で外部が危険っていうのは間違った二項対立だよ。Appleはこういう議論を使うけど、実際の理由はiPhoneやiPadでの取引の30%を取り続けたいからなんだ。だから、DMAに対して悪意のあるコンプライアンスで応じて、代替ストアを運営するのがほぼ不可能になってる。アプリをApp Storeの外でインストールできないことに対する不満はあるけど、プラットフォームをより安全にするために彼らがやっていることは多くの良い仕事だと思う。

└

OPはセキュリティについての話なのに、ここで既に多くの議論がされている一般的な炎上トピックを持ち出して、セキュリティを無視しているのはどうかと思う。せめて、そういう議論は関連性が薄い記事に限るべきじゃないかな。

Cのメモリ安全性が確保されたの？これは一段落で済ませるには大きなことだね。詳しい情報を持ってる人いる？ > iOS 14およびiPadOS 14以降のデバイスでは、AppleはiBootブートローダーを構築するために使用されるCコンパイラツールチェーンを改良して、そのセキュリティを向上させた。この改良されたツールチェーンは、Cプログラムで一般的に遭遇するメモリおよび型の安全性の問題を防ぐために設計されたコードを実装している。例えば、以下のクラスのほとんどの脆弱性を防ぐのに役立つ。 > • バッファオーバーフロー：すべてのポインタがメモリにアクセスする際に検証される境界情報を持つことを保証する > • ヒープの悪用：ヒープデータをそのメタデータから分離し、ダブルフリーエラーなどのエラー条件を正確に検出する > • 型の混乱：すべてのポインタがポインタキャスト操作中に検証されるランタイム型情報を持つことを保証する > • フリー後の使用による型の混乱：すべての動的メモリアロケーションを静的型で分離する

└

まあ、そうだね。私の理解では、彼らは関数にチェックを挿入するためにclangを使ってfboundsチェックを多用しているみたい。既存のコードにそれを挿入する作業もあったと思う。新しいプロセッサのメモリタグ付けは、オーバーフローの悪用を避けるのに役立つんだ。誰かもっと詳しいことを教えてくれるといいな。

└

何年も前の話だね。それはFirebloomって呼ばれてる。理論的にはFil-Cに似てると思うよ。https://saaramar.github.io/iBoot_firebloom/

└

Cをメモリ安全にしたの？ メモリ安全なCの方言を作ったんだよ、詳しくはここを見てね： https://clang.llvm.org/docs/BoundsSafety.html#overview

└

そうなんだけど、それは方言で、Swift Embeddedのロードマップの目標の一つはそれを置き換えることなんだ。