Bill Hates 曰く、

フロッピーディスクドライブ（FDD）を内蔵しないことで話題になったボンダイブルーの初代iMacの発売が1998年8月15日で一昨日2019年8月15日に21周年を迎えており、市販のマザーボードにはFDDもIDEもインターフェースがないのが常識になってきている。

そのような時節であるが、Windows 10ではFDDのドライバーが提供されている一方で、LinuxではFDDのドライバーの担当者がFDDの実物を所有していないなどという話があるらしい。仮装デバイスとしては需要があるものの、FDDでは生じなかった競合が生じるケースもあるという。

何かあったときのためにUSB接続のFDDは所有しているが、買ってから使った記憶がない。今でもフロッピーディスクには趣味的ではない、何らかの実務的な用途があるのだろうか。

headless 曰く、

DxOMarkは12日、DxOMark Mobile/SelfieによるSamsung Galaxy Note10+ 5Gのリアカメラ/フロントカメラ評価結果を公開した(リアカメラのレビュー記事、 フロントカメラのレビュー記事)。

Galaxy Note10+ 5Gのリアカメラは広角(12メガピクセル)+超広角(16メガピクセル)+望遠(12メガピクセル)+深度(VGA)のクアッドカメラ構成。フロントカメラは10メガピクセル。

DxOMark Mobileスコアは、これまで1位だったHuawei P30 Pro/Galaxy S10 5Gを1点上回る113点。ただし、写真のサブスコアは118点とP30 Proよりも1点低く、総合4位のOnePlus 7 Proと並んでいる。動画のサブスコアではP30 Pro/Galaxy S10 5Gを1点上回る113点を獲得し、歴代最高スコアを更新した。

各テスト項目では突出して高いものも低いものもなく、項目別1位となったのは写真のExposure & Contrast(96点)とBokeh(75点)、動画のStabilization(93点)のみ。その他のテスト項目でもP30 Proが他を寄せ付けない高スコア(95点)を獲得しているZoom(76点)を除き、項目別1位との差は1桁であり、大きな弱点はみられない。現在、DxOMark Mobileでは17機種が100点以上を獲得している。

DxOMark Selfieでは、これまで1位だったAsus Zenfone 6を1点上回る99点。写真と動画のサブスコアでもそれぞれ歴代1位だが、動画はZenfone 6と並んでいる。なお、Zenfone 6はカメラの回転機構を備えており、リアとフロントで同じカメラ(48メガピクセル+13メガピクセル)を使用する仕組みだが、現在のところDxOMark Selfieの評価しか行われていない。

各テスト項目では写真のFocus(86点)とArtifacts(85点)、Flash(91点)で歴代最高スコアを獲得しているが、他の上位機種と比べて特に高スコアというわけではない。その他のテスト項目でもTexture(63点)で項目別1位のPixel 3との差が14点となっている以外、1位との差は1桁にとどまる。メインカメラと同様、突出して高評価のものも低評価のものもないようだ。

headless 曰く、

「June Oven」というスマートオーブンが夜中に勝手に起動し、一晩中予熱し続けるというトラブルが報告されているそうだ(The Vergeの記事、 SlashGearの記事)。

June Ovenは対流式オーブンとエアフライヤー、食品乾燥機、スロークッカー、グリル、トースター、食品保温機という7種類の使い方ができるというスマートオーブンで、搭載カメラで食品を自動認識し、スマートフォンでの外出先からの操作やAlexaによるハンズフリー操作にも対応する。

The VergeによるとJune Ovenが夜中に勝手に予熱を始めるトラブルは少なくとも3件報告されているという。3件ともオーナーは朝になってから問題に気付いたといい、1件では前夜に焼いてそのまま冷ましていたジャガイモが4時間32分にわたって加熱され続け、カリカリになっていたそうだ。朝6時30分に予熱完了の通知で目覚めたという別のオーナーは、夜寝る前に電源プラグを抜くようにしているとのこと。

これらのトラブルについてJune CEOのMatt Van Horn氏は、オーブン側に問題はなく、ユーザーの操作ミスが原因だと述べている。たとえばJuneアプリでレシピを閲覧中、予熱設定を誤ってタップするというような報告が複数出ているという。また、1件はAlexaの誤動作によるもので、Alexaチームと問題解決を進めているそうだ。

ただし、ユーザーの操作ミスといっても予期せぬオーブンの予熱は火事の原因になる可能性もあり、アプリにも問題があることは否定できない。Juneでは9月のアップデートでリモートからの予熱を無効にするオプションを提供し、来年には加熱中に食品が検出されない状態が一定時間続いた場合にヒーターを切る機能を追加する計画とのことだ。

headless 曰く、

オーディオストリーミング等に用いられるBluetooth BR/EDR接続で暗号鍵の長さをネゴシエーション(Key Negotiation Of Bluetooth: KNOB)する際、通信範囲内にいる攻撃者が鍵長を短くできる脆弱性CVE-2019-9506が公表された(Bluetooth SIGのセキュリティ情報、 CERT: VU#918987、 The Vergeの記事、 Softpediaの記事)。

鍵長は接続する2台のデバイス間でネゴシエーションして決められるが、Bluetooth BR/EDR Core v5.1までの仕様では最短の鍵長が定められていないため、攻撃者がメッセージをインターセプトして偽のメッセージを送ることで、最短1オクテットの暗号鍵を使わせることが可能になる。

この脆弱性を悪用する攻撃はKNOB Attackと名付けられており、短い暗号鍵を総当たりで解析することで、情報開示や特権昇格が可能になる。脆弱性を発見した研究チームではBroadcom・Qualcomm・Apple・Intel・Chicony製のBluetoothチップ17モデルを搭載する24種類のデバイスでKNOB Attackが可能なことを確認したという。脆弱性の存在は2018年後半にCERTやBluetooth SIGに報告されており、以降の更新が行われていないデバイスは未修正とみられる。

これを受けてBluetooth SIGではBluetooth Core Specificationを更新し、BR/EDR接続時の鍵長を最短7オクテットにすることを推奨している。Appleは7月公開のiOS 12.4やmacOS Mojave 10.14.6などで脆弱性を修正しており、MicrosoftもサポートされるバージョンのWindowsを8月の月例更新で修正している。なお、接続する2台のデバイスの一方で脆弱性が修正されていれば攻撃は成功しないとのことだ。

情報元へのリンク

headless 曰く、

YouTubeは15日、「Content IDの手動申し立てに関するポリシー」を改訂し、動画のごく一部に含まれる音声コンテンツや意図的でない使用とみなされる音声コンテンツについて、コンテンツ所有者が手動申し立てをしても収益化ポリシーが適用されない可能性があることを明記した(YouTube Creator Blogの記事、 The Vergeの記事、 TorrentFreakの記事、 9to5Googleの記事)。

手動申し立てはコンテンツ所有者がContent IDシステムで自動認識されないコンテンツの権利を申し立てることができるようにするためのものだ。しかし、動画のごく一部に含まれる音声コンテンツや偶然に録音されたとみられる音声コンテンツなどに対し、動画クリエイターから収益を奪う目的で手動申し立てを行う例があるという。YouTubeでは7月、手動申し立ての際にタイムスタンプによる対象コンテンツの位置指定を必須とするポリシー改訂を実施してクリエイターによる該当部分の削除を容易にしており、今回の改訂でクリエイターに対する公平さをさらに高める狙いだ。収益化ポリシーが適用されない場合もコンテンツ所有者はコンテンツをブロックすることができるが、YouTubeでは収益化につながらない申し立てが減ることを期待しているようだ。

あるAnonymous Coward 曰く、

https://this.kiji.is/535035621765465185
https://www3.nhk.or.jp/news/html/20190816/k10012038551000.html
https://www.sankei.com/politics/news/181213/plt1812130001-n1.html
https://mainichi.jp/articles/20190817/ddm/005/010/085000c
https://www.jiji.com/jc/article?k=2019081600936&g=pol

一応、「政府は昨年末、F-35を将来的に計147機保有し、うち42機についてはF-35Bを念頭に短距離離陸・垂直着陸型とすることを閣議了解。その後、正式に機種の選定を進めていた。」という話だから、日本の国防の最強最大の敵＝財務省主計局が機数削減を求める事は無いと思いたい。

情報元へのリンク

headless 曰く、

WebKitは14日、ユーザー追跡防止に関する新ポリシー「WebKit Tracking Prevention Policy」を発表した(WebKitのアナウンス、 The Registerの記事、 BetaNewsの記事)。

新ポリシーはMozillaの「Security/Anti tracking policy」に触発されたもので、サードパーティーWebサイトによるユーザー追跡をすべて禁止する。cookieなどデバイスのストレージを使用するユーザー追跡や、URLパラメーターなどを使用するナビゲーション時のユーザー追跡、フィンガープリンティングなどを防止する技術について、未実装のものは今後実装する計画だという。現在知られていないユーザー追跡技法についても、判明した時点で対象に加えていくとのこと。

WebKitのユーザー追跡防止技術は例外なく適用される。ある技術がユーザー追跡に転用可能な場合、WebKitでは正規の使用かどうか識別できないケースも多いが、その技術の使用禁止がユーザーに悪影響を与える場合は使用制限で対応することもある。使用制限でも悪影響がある場合は追跡の可能性があることをユーザーに告知するという。ユーザー追跡防止技術を迂回する行為は脆弱性を悪用する行為と同様に扱い、迂回しようとする者に対して事前に通知することなくさらなる制限を行なう可能性もあるとのことだ。