headless 曰く、

Windows 10 バージョン 21H1 (May 2021 Update) のサービス終了を前に、Microsoft が再び注意喚起している (Windows メッセージセンターのアナウンス、 Windows IT Pro Blog の記事、 Neowin の記事、 Ghacks の記事)。

21H1 は 12 月 13 日の月例更新ですべてのエディションのサービスが終了する。Microsoft はサービス終了に関するサポートドキュメントを 9 月に公開し、10 月には間もなくサービスが終了する 21H1 へ自動更新で 22H2 を提供する計画を示していた。

なお、Windows 10 はバージョン 2004 以降すべてのバージョンでサービシングコンテンツを共有しており、使用中バージョンよりも新しいバージョンの新機能が無効化された状態で含まれている。そのため、21H1 から 22H2 へのアップグレードは新機能を有効化するイネーブルメントパッケージを実行して再起動するだけでよい。

イネーブルメントパッケージは Microsoft Update カタログで配布されておらず、Windows Update 経由で入手するしかないが、自動更新を待たなくてもオプションの更新プログラムとして 22H2 が表示されている場合は手動で更新できる。また、Windows 11対応環境ならWindows 11にアップグレードすることも可能だ。

ただし、最近のバージョンの Windows 10 は新機能が少なく、22H2 の新機能は具体的に発表されていない。そのため、定期的に新バージョンをリリースするという約束を果たすためだけの新バージョンにも見えるが、スラドの皆さんのご意見はいかがだろうか。

headless 曰く、

スイス・ジュネーブ警察がワシを使用するドローン撃退計画を中止したそうだ (The Register の記事、 Bloomberg の記事、 RTS の記事)。

国際会議がしばしば開催されるジュネーブでは、望ましくない場所を飛行するドローンを空中で取り押さえ、安全な場所に移動するワシ部隊を 2017 年に計画。2018 年の運用開始を目指し、購入したワシの卵2個を孵化させて鷹匠が訓練していたが、現場に投入されることなく計画が終了した。警察では 10 月末に計画の終了を決定しており、ドローン撃退に野生動物を使用することの不確実さや、ワシに危害が及ぶ可能性を理由として説明しているとのこと。

野生のワシによるドローンの撃墜はたびたび報じられているが、その習性を人間が利用するのは容易ではないようだ。オランダ警察もワシによるドローン捕獲を計画し、2016 年にはワシを各地に配備していたが、実際に活躍することなく 2017 年に計画を中止している。

headless 曰く、

Rocket Lab CEO のピーター・ベック氏が、ヘリコプターによるロケット第 1 段の空中キャッチは容易にできることではないとの見解を改めて示している (Rocket Lab の更新情報、 The Register の記事、 動画)。

Rocket Lab は 5 月の「There And Back Again」ミッションで空中キャッチに初めて成功。今回、日本時間 5 日の「Catch Me If You Can」ミッションで再び空中キャッチを実行すると予告していた。空中キャッチにはシコルスキー S-92 型ヘリコプターを用い、パラシュートで降下してきた Electron ロケット第 1 段のドラッグラインにフックを掛けて回収する。5 月のミッションではキャッチ後に海洋上へ落下させて回収船が製造施設へ運んでいたが、今回は直接オークランドの製造施設へ運ぶ計画も示されていた。

Electron ロケット 32 回目の打ち上げとなる「Catch Me If You Can」は、スウェーデン国立宇宙委員会 (SNSA) の MATS (中間圏大気光/エアロゾルトモグラフィーおよびスペクトロスコピー) 衛星打ち上げミッションだ。ニュージーランド・マヒア半島の Rocket Lab 打ち上げ施設で Electron ロケットが打ち上げられたのは日本時間 5 日 2 時 27 分。約 54 分後に高度 585 km の円軌道投入が確認され、打ち上げは成功した。MATS 衛星は Electron が軌道投入した 152 基目の人工衛星になるとのこと。

一方、再突入した第 1 段は順調に降下しているように見えたが、打ち上げから約 18 分後に空中キャッチ取りやめと海洋上への着水・回収が告げられた。その後、再突入時に第 1 段からのテレメトリーが一部失われたため、安全のため回収区域からヘリコプターを撤収したと説明されている。

ベック氏は「宇宙からロケットを帰ってこさせるのは困難なことであり、ヘリコプターでの空中キャッチは想像通り複雑だ」として、複雑な多数の要素が完全に揃う必要のある空中キャッチは成功する可能性が失敗する可能性と比べてはるかに低いと述べている。今回は海洋上で 5 台目のロケットが回収できたことに満足の意を示しつつ、Electron を再使用可能ロケットにするため、空中キャッチを今後も試みるとの意思を示した。

headless 曰く、

Lenovo は 8 日、個人向けノート PC でセキュアブートを無効化可能な UEFI (BIOS) の脆弱性 3 件を公表した (セキュリティアドバイザリー、 ESET のツイート、 Neowin の記事、 Ars Technica の記事)。

発見した ESET によれば、3 件はいずれも UEFI の DXE ドライバーに存在する脆弱性で、管理者権限を持つ攻撃者が NVRAM 変数を変更することによりセキュアブート無効化などの設定変更が可能になるという。ESET が 4 月に公表した Lenovo の ノート PC の脆弱性と同様、今回の 3 件も製造プロセスでのみ使用することを目的としたドライバーを製品版に含めてしまったことが原因とのこと。

一方、Lenovo は CVE-2022-3430 を WMI Setup ドライバーの潜在的な脆弱性と説明しており、CVE-2022-3431 と CVE-2022-3432 では製造プロセスで使用するドライバーに潜在的な脆弱性が存在し、誤って無効化されなかったと説明している。

これらのうち CVE-2022-3430 または CVE-2022-3431(または両方)の影響を受けるのは国内未発売モデルを含めて計 54 製品。既に修正版ファームウェアアップデートが提供されており、適用すれば問題は解決する。CVE-2022-3432 は影響を受ける Ideapad Y700-14ISK の開発サポートが終了していることから修正版は提供されないとのことだ。

headless 曰く、

Tesla は 1 日、ファームウェア更新でパワーステアリングによる補助が低下または失われた可能性のある 2017 年 ～ 2021 年式 Model S と Model X およそ 4 万台のリコールを米運輸省道路交通安全局 (NHTSA) に報告した (リコール報告書: PDF、 The Register の記事)。

影響を受けるファームウェアバージョンは 2022.36 および 2022.36.4。Tesla は予期せぬステアリング補助のトルク検出を向上させるべく、10 月 11 日に幅広いロールアウトを開始した 2022.36 でパワーステアリングシステムのキャリブレーション値を更新。ところが 10 月 18 日には特定の Model S / Model X で更新されたキャリブレーション値に関連したアラートが増加する。道路の凹凸などを予期せぬステアリング補助のトルクとして検出することが原因で、ステアリング操作時にドライバーが力を入れる必要が出てくる。特に低速時に影響が大きく、事故のリスクが増加するという。

米国内で実際に影響を受けた可能性のある車両は 11 月 1 日時点で 314 台が特定されているが、これによる死傷者の発生は確認されていないとのこと。10 月 19 日にはキャリブレーション値を元に戻したファームウェアバージョン 2022.36.5 がリリースされており、11 月 1 日時点で対象車両の 97% に 2022.36.5 以降がインストール済み。2022.36.5 以降がインストールされた車両のオーナーは特に何もする必要はない。

headless 曰く、

COVID-19 パンデミックによるシステム管理者の仕事への影響について、ドイツのマックスプランク情報学研究所が 24 人への聞き取り調査の結果をまとめている (The Register の記事、 論文リポジトリ)。

24 人の国別内訳はオランダが 8 人と最も多く、ドイツが 3人、オーストリア・インド・ノルウェイが各 2人で続く。アジア圏はインドのみで、このほか米国とガーナを除くとすべて欧州となっている。一方、産業部門別では教育と IT が各 8 人で大半を占め、金融・研究が各 2 人で続く。勤務経験は 7 か月から 25 年まで幅広いが、10 年以上が 13 人と過半数を占め、中央値は 10 年となる。

調査の結果、システム管理者は他の人たちが仕事をできるようにするという任務から、危機下で他の業務とは異なるプレッシャーを感じていたことが判明したという。その一方で、自宅勤務では他の人が自分の仕事を待っているというプレッシャーが少ないという意見も聞かれたそうだ。

また、ロックダウン初期のシステム管理者はやってくる仕事のほとんどをただこなすだけだったが、その後は組織がロックダウン下での業務の方法を公式化していくことになる。その結果、調整は暗黙的なものから明示的なものに移り、意思疎通も自発的なものや偶然によるものから非同期なコミュニケーションや計画的なミーティングへ変わっていった。こういった変化はロックダウンにより推進されたと考えられるとのこと。

論文では調査結果を踏まえ、システム管理者の業務環境を改善するための推奨事項を 3 つ挙げている。

1. システム管理者の仕事を増やすだけの公式な仕事の形式を最小限にする
2. リモートワーク時の公式な調整の必要性を減らしつつ、システム管理者との共同作業を容易にするツールの導入
3. システム管理者にその仕事と責任に対する十分な権限を与える

スラドの皆さんのご意見はいかがだろうか。

あるAnonymous Coward 曰く、

日本のマスコミでは、バンクシー自身がインスタグラムに「ウクライナのボロディアンカ」と写真を投稿した、倒壊しそうなビルの壁に描いた逆立ちする体操選手の絵の方が、確度が高いと写真報道されているが、メッセージ性は「柔道家を投げる子どもの絵」の方が上だろう。

情報元へのリンク

あるAnonymous Coward 曰く、

https://mainichi.jp/articles/20221112/ddl/k13/040/008000c
https://www3.nhk.or.jp/shutoken-news/20221111/1000086661.html
https://www.sankei.com/article/20221111-LKGNYWKWUBN7JHYEG5QN44G6OU/
車検が継続して通過していたなら、登録当時のクラシックカーにシートベルト・ヘッドレストが無くてもそのままで許されるんじゃ？
あと赤色灯方向指示器（や腕木式方向指示器或いは無し）なんかも。

情報元へのリンク

あるAnonymous Coward 曰く、

iPhoneのプライバシー設定で個人情報のトラッキングを止めてもApple純正アプリの追跡は止められないようだ。
アプリ開発に従事するTommy MyskさんとTalal Haj Bakryさん、ソフトウェア会社Myskのセキュリティ研究班がApple純正アプリ（App Store、Apple Music、Apple TV、Books、Stocks）による情報収集を調べてみたところ、解析やプライバシー設定をいじってもAppleによるデータ収集にはなんの変化も起こらなかったとのこと。

たとえばApp Storeアプリでは、ユーザーが何をタップして、どのアプリを検索してどの広告を見てどれくらいの時間アプリを眺めて、そのアプリをどう見つけたのか、といった情報まで一挙手一投足がリアルタイムで追跡されていた。
Myskさんは｢オプトアウトしても、カスタマイズのオプションをOFFにしても、当該アプリが送信する情報量が減ることはなかった｣と述べている。
つまりサードパーティアプリのトラッキングはユーザーの裁量で可否の設定が可能だが、Apple純正アプリはすべてAppleに捧げることということだろう。

これについてAppleに何度もコメントを求めたが返答はないとのこと。

情報元へのリンク

あるAnonymous Coward 曰く、

https://www.mofa.go.jp/mofaj/p_pd/pds/page22_003885.html
https://mainichi.jp/articles/20221109/k00/00m/010/002000c
毎日ならそういう取り上げ方するだろうよ。

情報元へのリンク

headless 曰く、

Android の 2022-11-01 セキュリティパッチレベルでは、PIN ロックした SIM を使用してスクリーンロックをバイパス可能な脆弱性 CVE-2022-20465 が修正されている (9to5Google の記事、 Android Police の記事、 発見者のブログ記事、 Google Git)。

この脆弱性は PIN ロックされた SIM の PUK を入力して PIN を再設定し、端末のロックを解除するとスクリーンロックも解除されてしまうというものだ。攻撃者は PIN ロックした SIM を用意し、スクリーンロック解除失敗によりロックされた端末の SIM と交換する。端末再起動後、SIM の PIN を入力を 3 回間違えると PUK による PIN 変更が可能になるので、PUK を入力して新しい PIN を設定する。脆弱性のある状態ではこの段階でスクリーンロックが解除されるのだという。

発見者は Pixel 6 で脆弱性を確認しているが、AOSP では Android 13 ブランチのほか Android 10 ～ 12L ブランチにも修正がバックポートされており、他の機種やフォークした OS にも影響する可能性がある。Android Police によれば Lineage OS で脆弱性が報告されている一方、GrapheneOS では既に修正済みだという。また、Samsung の端末は影響を受けないという報告もみられるとのこと。手元のシャープ製端末 (Android 12、パッチレベルは 10 月) で試してみたが、PUK を入力して SIM の PIN を再設定するとスクリーンロック画面になった。操作を間違ったのでなければ影響を受けないようだ。

あるAnonymous Coward 曰く、

twitter blueユーザーを見分けるブラウザ拡張機能も出現 https://github.com/wseagar/eight-dollars

情報元へのリンク

情報元へのリンク

rachelvenya 曰く、

Ferbena fashion blog

情報元へのリンク