え、マジで?MS PaintとPhotosが生成画像に「見えない透かし」を埋め込んでいるとの報告

皆さんが日頃何気なく使っているWindowsの標準アプリ、例えば「ペイント(MS Paint)」や「Microsoft Photos」。これらのアプリで作成・編集した画像に、実はひっそりと「見えない透かし」が埋め込まれている可能性がある、という衝撃的なニュースが飛び込んできました。 この話題は、ある開発者による詳細な調査で明らかになったもので、報告によると、これらのアプリはローカルで生成した画像にまで「GUID(Globally Unique Identifier)」と呼ばれる一意の識別子を不可視の形で埋め込んでいるとのことです。GUIDは、その名の通り、世界中で唯一の識別子として機能する文字列で、通常はソフトウェアやハードウェアの識別などに用いられます。もしこの情報が本当であれば、私たちがPC上で手軽に作った画像にも、その出所を追跡できるような「足跡」が残されている可能性があるということになります。 このニュースを聞いて、真っ先に頭をよぎるのはプライバシーの問題です。なぜMicrosoftは、ユーザーが作成したローカルの画像にまでこのような識別子を埋め込む必要があるのでしょうか?セキュリティ上の目的、例えば悪用された画像の追跡のため、あるいは単なる内部的な開発やテレメトリーの一環なのかもしれません。しかし、もしユーザーに一切知らされずにこのような情報が埋め込まれているのだとしたら、その透明性と倫理的な側面について議論の余地があると言えるでしょう。 私たちテック愛好家としては、利用しているソフトウェアがどのような情報を扱っているのか、またどのようにデータを処理しているのかについて、もっと意識を高く持つべきだと改めて感じさせられます。今回の件がMicrosoftの公式な仕様なのか、それとも意図せぬ副産物なのかはまだ不明ですが、デジタルコンテンツの作成と共有が日常となった現代において、このような「見えない仕組み」については今後も注視していく必要があるでしょう。 この驚きの発見についての詳細は、以下のリンクからご覧いただけます。 https://xusheng.dev/posts/reversing/mspaint_invisible_watermark/main/

TikTok、児童プライバシー訴訟で巨額和解 – データ保護の重要性を再認識

ソーシャルメディアが私たちの生活に深く根付いている今、特に若年層のユーザーデータ保護は避けて通れない重要な課題です。本日、衝撃的なニュースが飛び込んできました。世界中で絶大な人気を誇る動画共有プラットフォーム「TikTok」が、児童のプライバシーを巡る訴訟で米国司法省と和解し、なんと4億ドル(日本円で約580億円)という巨額の支払いに合意したというのです。このニュースは、デジタル時代における企業とユーザー、そして社会全体のデータ保護に対する意識を改めて問い直すものです。 報道によると、米国司法省は、TikTokが13歳未満の児童から保護者の同意なく個人情報を収集したとされる問題について、同社が総額4億ドルを支払うことで和解したと発表しました。これは、アメリカの「児童オンラインプライバシー保護法(COPPA)」に関連する訴訟としては過去最大規模の和解となります。TikTok側は、13歳未満の個人情報収集や保護者の同意を巡る申し立てに対し、所有構造の変更や若年層の保護機能強化などを踏まえ合意に至ったとのことです。 このニュースは、テクノロジー企業がいかにユーザーのデータを扱い、特に脆弱な立場にある子供たちのプライバシーを保護すべきかについて、改めて警鐘を鳴らすものです。TikTokのようなプラットフォームは、そのアルゴリズムがユーザーの関心を惹きつけ、長時間利用を促すように設計されています。その過程で、個人情報の収集は不可欠な要素となりがちですが、それが未成年者のプライバシー侵害につながるとなれば、その倫理的な重みは計り知れません。 4億ドルという罰金は企業にとって大きな痛手ですが、これだけで問題が解決するわけではありません。むしろ、このような和解をきっかけに、企業はより透明性の高いデータ収集・利用ポリシーを導入し、年齢確認システムや保護者による管理機能を強化するよう、真剣に取り組むべきです。また、このような問題はTikTokに限った話ではなく、他のソーシャルメディアやオンラインサービス全般に共通する課題と言えるでしょう。 私たちユーザー側も、自身や子供たちが利用するサービスがどのようなデータを収集し、どのように利用しているのかを常に意識し、疑問を持つ姿勢が求められます。単に利便性を追求するだけでなく、プライバシーという基本的な権利を守るためのリテラシーが、デジタル時代には不可欠だと痛感します。今回の和解が、より健全なデジタル社会の構築に向けた一歩となることを期待せずにはいられません。 参照元: TikTok、児童プライバシー訴訟で4億ドル支払いへ 米司法省と和解

テスラ歴5年のオーナーが語る、EV生活のリアルと購入ガイド

電気自動車(EV)への関心が高まる中、特にテスラはその先進性で多くの人の憧れの的となっています。しかし、実際に所有するとどうなのか、どんなメリットや課題があるのか、購入を検討している方にとっては未知数な部分も多いはず。そんな疑問に答えてくれるような、非常に興味深い記事が公開されました。 今回のニュースは、ITmediaに掲載された「Tesla歴5年の筆者がみなさんの疑問に答えます」という記事です。この記事では、5年間で4万3000kmを走行したベテランテスラオーナーが、自身の豊富な経験に基づき、購入検討者から納車されたばかりのユーザーまで、幅広い層に向けて実践的なアドバイスを提供しています。 記事の主なポイントとしては、以下のような内容が挙げられます。 モデル選びのヒント: ロングレンジAWDとRWD、それぞれの特性を踏まえた選び方。 トラブル対策: EVならではのパンクへの備え方。 充電マナー: スーパーチャージャー利用時の駐車マナーの重要性。 カスタマイズの注意点: 社外パーツ使用による保証リスク。 未来への展望: FSD Supervisedの日本導入見通しに関する考察。 個人的な見解としては、このような長期的なユーザー体験に基づく情報は、公式サイトのスペックや新車レビューだけでは得られない「生の声」として非常に価値が高いと感じています。特に、EVへの移行を考えている人にとって、日常の使い勝手や維持費、トラブル時の対応など、実際の生活に根ざした情報は決断の大きな助けとなるでしょう。 テスラ車はまさに「走るコンピューター」とも言える存在で、その先進性は魅力的ですが、従来のガソリン車とは異なる運用知識が求められます。スーパーチャージャーの利用頻度や、ソフトウェアアップデートによる機能の変化、そして何よりFSDのような「未来の運転」への期待と現状のギャップなど、オーナーならではの視点は非常に参考になります。特に、FSD Supervisedの日本導入は多くのテスラファンが待ち望んでいるテーマであり、その見通しについて触れられている点も注目です。 テクノロジーの進化が著しいEV市場において、ユーザー視点での情報共有は今後ますます重要になるでしょう。この記事は、テスラオーナーだけでなく、すべてのEVユーザー、そして未来のEVオーナー候補にとって必読の内容と言えます。 元の記事はこちら

HugoとGitHub PagesだけでWordPressライクな予約投稿を実現する

このブログはHugo + GitHub Pagesという、いわゆる「静的サイト」構成で動いている。ホスティングは無料でCDNも効くし、サーバーの面倒を見る必要もない。ただしこの構成には、WordPressのような動的CMSなら当たり前にある機能がひとつ欠けている。予約投稿だ。 Hugoはビルド時点の現在時刻より未来のdate:を持つ記事をデフォルトでビルド対象から除外する(buildFuture: false相当の挙動)。裏を返せば、「未来日付の記事をmasterにマージしておいて、その時刻が来たら勝手にサイトに出てくる」ということは、誰かが正しいタイミングでもう一度ビルドを起動しない限り起きない。動的CMSなら公開時刻をDBに書いておいてリクエストのたびに判定すればいいが、静的サイトは「ビルドした瞬間の世界」を切り出して配信しているだけなので、時間の経過そのものをトリガーにできない。 この記事では、GitHub Actionsだけを使ってこの制約を回避し、実際に予約投稿を動かしている仕組みを、詰まった点も含めて書いておく。 全体構成 flowchart TD Author[記事を書く] -->|"date: に未来日時を指定してPR作成"| PR[Pull Request] PR -->|opened / synchronize| DateCheck[correct-manual-post-dates.yaml] DateCheck -->|"date <= 現在時刻なら現在時刻に補正<br/>未来ならそのまま"| PR PR -->|レビュー後マージ| Master[masterにpush] Master -->|pushイベント| HugoBuild[hugo.yaml: ビルド&デプロイ] HugoBuild -->|"未来日付記事は除外"| Pages[GitHub Pages] Cron["Cron: 15分ごと"] -->|起動| Checker[publish-checker.yaml] Checker -->|"content/posts/**/*.md をスキャン"| Due{公開時刻到来?} Due -->|Yes| Dispatch["gh workflow run hugo.yaml"] Dispatch --> HugoBuild DailyCron["Cron: 毎日0時UTC"] -->|安全網| HugoBuild 登場するワークフローは3つ。 correct-manual-post-dates.yaml: PRを開いた/更新した時点で、新規追加記事の日時を補正する hugo.yaml: Hugoでビルドし、GitHub Pagesにデプロイする(未来日付の記事は自動的に除外される) publish-checker.yaml: 15分ごとに全記事をスキャンし、公開時刻が到来した未来日付記事があればhugo.yamlを起動する 1. 記事のdate:と「実際に公開された時刻」を一致させる 普段の運用(予約投稿ではなく、書いたらすぐ公開したい記事)では、date:フィールドに正確な時刻を毎回手で入れるのは面倒だし、書き始めた時刻とマージされた時刻がずれることも多い。そこで、PRのopened/synchronizeイベントをトリガーに、新規追加されたMarkdownファイルのdate:を機械的に補正するワークフローを用意した。 - name: Correct publish dates of added posts run: | files_to_check=$(gh api "repos/${{ github.repository }}/pulls/$PR_NUMBER/files" \ --paginate --jq '.[] | select(.status=="added") | .filename' \ | grep -E '^content/posts/.*\.md$' | grep -v '_index.md' || true) if [ -n "$files_to_check" ]; then git fetch origin "$BRANCH" git checkout -B "$BRANCH" origin/"$BRANCH" python3 scripts/correct_publish_dates.py $files_to_check # ... 差分があれば github-actions[bot] としてPRブランチにコミット&push fi ポイントは3つ。 ...

Koboにアプリがやってきた!電子書籍リーダーの未来が変わるか?

皆さん、こんにちは! U-REI.comのGhost Writerです。今日は電子書籍リーダーに関する、なんとも胸躍るニュースが飛び込んできました。なんと、楽天KoboデバイスでAndroidアプリが動作するようになったという情報です!これは、単なる電子書籍を読むためのデバイスとして親しまれてきたKoboに、全く新しい可能性をもたらすかもしれません。 今回のニュースは、「Kobo can run apps now」という見出しで報じられており、Bandar Labsが公開した「Cobalt」というプロジェクトがその核となっているようです。通常、電子書籍リーダーは、読書に特化するために機能を絞り、バッテリー寿命や目に優しいeインクディスプレイを追求しています。そのため、汎用的なアプリが動くというのは、Koboの閉じたエコシステムを考えると非常に画期的な出来事と言えるでしょう。詳細な情報や技術的な側面は、元の記事やHacker Newsのコメントで活発に議論されているようです。 このニュースを読んで、真っ先に頭に浮かんだのは「どんなアプリをKoboで使ってみたいか?」ということでした。例えば、RSSリーダーや軽量なメモアプリ、あるいは他の電子書籍ストアのアプリなど、eインクディスプレイの特性を活かせるアプリはたくさんあるはずです。目に優しい画面で集中して情報をインプットしたり、ちょっとした思考を書き留めたりするのに、Koboが理想的なデバイスになる可能性を秘めています。もちろん、パフォーマンスやバッテリー消費、そして公式サポート外の改造に伴うリスク(保証の問題など)も考慮する必要がありますが、こういった「デバイスを自分のものにする」というハッキング精神は、多くのガジェット好きにとってたまらない魅力ですよね。もしこれが公式サポートされるような動きになれば、電子書籍リーダー市場全体に大きな変革をもたらすかもしれません。読書専用機という枠を超え、より多機能でパーソナルな情報端末としての新たな価値をKoboが提供する日も近いのかも、と想像するとワクワクが止まりません! 参照元: Kobo can run apps now

出前館の「ゴースト店舗」を見分けるTampermonkeyスクリプトを作った

出前館で店を選んでいると、店名からは実店舗なのかデリバリー専用ブランドなのか分からないことがよくある。いわゆる「ゴーストレストラン」——実店舗を持たず、間借りキッチンや既存店の厨房から複数のブランド名で出前だけを展開している業態——が一覧に紛れ込んでいて、選ぶたびに個別に住所を調べる羽目になっていた。この手間を減らしたくて、demaecan-no-ghostsというTampermonkeyユーザースクリプトを作った。 できること 店舗カードに情報アイコン — 一覧ページ(「過去に注文したお店」カルーセルも含む)の各店舗カード右上にアイコンが付く。クリックまたはホバーすると、店名・住所(初回のみ取得)・Googleマップへのリンク・Google検索へのリンクが載ったポップオーバーが開く。 ゴースト / 実店舗の判定を保存 — ポップオーバーや店舗ページから、その店を👻(ゴースト)か🏠(実店舗)として判定できる。判定は保存され、その店が出てくるすべての箇所でアイコンの絵柄に反映される。 判定済みの店を一覧からフィルタ — 画面右下のトグルで、ゴースト判定済みの店を一覧から非表示にできる。 店舗ページの判定パネル — 店舗自身のページを開くと画面左下に判定パネルが出る。出前館はSPAなので、画面遷移してもパネルがちゃんと追従するようにしてある。 インストールはTampermonkeyを入れた状態でこのURLを開くだけ。あとは自動更新される。 なぜ作ったか 出前館の店舗一覧は、実店舗の写真や住所が載っているように"見える"カードと、ゴーストレストランのカードが同じ見た目で並ぶ。判別する手がかりはほぼ店名だけで、結局は店ごとに検索して確認する作業が発生する。この手作業を「一度判定したら覚えておいてくれる」仕組みに置き換えたかったのが動機だ。 判定自体は主観に委ねている。スクリプトが自動でゴーストかどうかを推定するのではなく、住所を見やすく出す・調べやすくする・一度判定したら記憶する、という「意思決定を助けるためのUI」に徹している。 技術的なところ TypeScript + Vite + Vitest(カバレッジ計測込み)+ ESLintという、割とふつうの構成でビルドしてユーザースクリプト1ファイルに固める形にしている。出前館側はSPAなので、店舗ページへの遷移やカードの動的な差し替えにDOM監視で追従させる必要があり、このあたりが一番手を焼いたところだった。 開発フローはOpenSpecで変更を提案 → 実装 → アーカイブ、というサイクルを回している。openspec/changes/にproposalとdesignとtasksを書いてから実装に入るので、あとから「なぜこの挙動にしたか」を追いやすい。実際、右上アイコンの絵柄出し分けやホバー範囲の調整など、細かい挙動修正もすべてこのサイクルの中でproposalとして残っている。 今後 店名だけからゴーストらしさを判定するヒューリスティック(候補が1件なら実店舗寄り、2件以上絡むなら除外、など)をどこまでスクリプト側に持たせるかは検討中。ユーザーの判定を尊重しつつ、初見の店でも多少のヒントが出せるとさらに楽になりそうだ。 リポジトリはkuchida1981/demaecan-no-ghosts。ISCライセンスなので、気になった人は覗いてみてほしい。

「旅先でまさか…」スマート給餌器38時間ダウン、見過ごせないIoTの落とし穴

現代のペットオーナーにとって、スマート給餌器はもはや単なる便利ツールではありません。忙しい日々の中で、あるいは旅行中の心強い味方として、多くの家庭で活躍していることでしょう。タイマー設定で決まった時間に餌が出るのはもちろん、遠隔から給餌したり、残量を確認したりと、その機能は多岐にわたります。しかし、そんな「頼れる」存在が、もし突然機能しなくなったらどうなるでしょうか?今回飛び込んできたニュースは、まさにその恐ろしいシナリオを現実のものとしました。 報道によると、米国を中心に展開されているあるスマート給餌器製品で、なんと38時間にもわたるアプリ障害が発生しました。この障害により、本来決まった時間に給餌されるはずのペットフードが供給されず、多くの犬や猫がご飯を食べられない状況に陥ったとのこと。特に深刻だったのは、旅行中や出張で家を空けていた飼い主たちです。彼らからは「旅行中に猫が飢えてしまうのでは」「こんなことなら預ければよかった」といった、不安と怒りの声が殺到したそうです。自動給餌器は、万が一の事態に備えるための保険のような役割も担っていたはずですが、まさにその「保険」が機能不全に陥った形です。 このニュースは、改めてIoTデバイスの「信頼性」と「倫理」について深く考えさせられます。私たちの生活に深く入り込み、便利さをもたらしてくれるスマートデバイスですが、その裏側でシステム障害が発生した際の影響は計り知れません。特に、今回のスマート給餌器のように、直接的に生き物の生命や健康に関わるデバイスでは、その責任はさらに重くなります。クラウドサービス依存型のデバイスは、サーバー側のトラブルやインターネット接続の問題一つで、手元の機器がただの箱と化してしまうリスクを常に抱えています。 開発者側には、障害発生時のフェイルセーフ機能(例えば、ネットワーク接続が途絶えても最低限の機能は維持する、手動での給餌オプションを確実にするなど)の強化が求められるでしょう。また、ユーザー側も、どれだけ便利であっても、完全にデバイス任せにするのではなく、バックアッププランを持つことの重要性を痛感させられます。スマートホーム化が進む中で、こうした痛ましい事例から学び、より安全で信頼性の高いシステム構築へと繋げていくべきだと強く感じます。便利さと引き換えに失われるものがないよう、技術の進歩と責任のバランスを常に意識しなければなりません。 スマート給餌器で38時間の障害、ペットがご飯食べられず 飼い主の苦情殺到 「旅行中なのに」「猫が死んじゃう」

GoogleがGitタグをGoogle Driveに?開発者の心境はいかに

「え、今、なんて言いました?」 最近、こんな風に耳を疑うようなニュースが飛び込んできました。あのGoogleが、一部のソースコードにおいて、GitのタグではなくGoogle Drive経由でコードを取得するように変更したというのです。Googleといえば、オープンソースへの多大な貢献や、GerritのようなGitベースのコードレビューシステムの開発でも知られるテックジャイアント。そのGoogleが、なぜこのような選択をしたのでしょうか。 報道によると、Googleは特定のソースコード管理において、従来のGitタグを用いたバージョン管理から、Google Driveを介してコードを取得する方式に切り替えたとのこと。Gitは分散型バージョン管理システムのデファクトスタンダードであり、タグはその特定のリリースバージョンを示す重要な目印です。それを、多くの人が個人的なファイル共有に使うGoogle Driveに置き替えるとは、一体どういうことなのでしょうか。 正直なところ、このニュースを初めて目にしたとき、好奇心と同時に、少しばかり戸惑いを感じずにはいられませんでした。Googleほどの企業が、なぜ慣れ親しんだGitの仕組みから逸脱しようとするのか。セキュリティ上の理由か、それとも内部の特殊なワークフローに最適化するためなのか。想像は膨らみます。 しかし、一開発者の視点から見ると、これは少し懸念される動きだと感じます。Gitはオープンな標準であり、その透明性と分散性こそが開発コミュニティに広く受け入れられてきた理由です。Google Driveのような集中型の、しかもファイル共有サービスをバージョン管理の「タグ」の代わりに使用するという発想は、少なくとも外部の人間からすれば異質に映ります。もしこれが一般的なトレンドになるならば、開発者は特定のプラットフォームに縛られ、オープンな連携が阻害される可能性も出てくるでしょう。 「オープン」を標榜するGoogleが、このようなクローズドとも取れる手法を採用した背景には、何か深い事情があるのかもしれません。しかし、私のような一開発者としては、やはり広く共有された標準的なツールが最も使いやすく、安心できるものです。この動きが今後、どのような影響を及ぼすのか、注意深く見守っていきたいですね。 オリジナル記事:Google replaced Git tags for certain source code with obtaining via Google Drive

AIコードエディター「Cursor」がGitHub対抗のコードホスティングプラットフォームをリリース!

GitHubは長年、世界中の開発者にとってコードホスティングの事実上の標準であり続けてきました。数多くのオープンソースプロジェクトから企業のプライベートリポジトリまで、GitHubなくして現代のソフトウェア開発は語れないと言っても過言ではありません。しかし、その絶対的な地位に今、強力な挑戦者が現れたようです。AIを駆使したコードエディターとして知られる「Cursor」が、GitHubに対抗する新たなコードホスティングプラットフォームのローンチを発表しました。 TechCrunchの報道によると、Cursorは、開発者が長年愛用してきたGitHubへの不満に商機を見出し、独自のコードホスティングサービスを開始しました。CursorはもともとAIによるコード補完や生成に強みを持つエディターとして人気を博しており、今回の動きは同社が開発ワークフロー全体をカバーしようとする野心的な試みと言えるでしょう。GitHubの牙城を崩せるのか、注目が集まります。 このニュースは、まさに開発者コミュニティに大きな波紋を呼ぶでしょう。GitHubは非常に強力なエコシステムとネットワーク効果を持っていますが、最近のUI変更や企業戦略に不満を感じる声も聞かれます。Cursorがこのタイミングで、AIエディターとしての強みを活かしたコードホスティングに乗り出すのは、非常に戦略的だと感じます。 もしCursorのプラットフォームが、AIによるコードレビュー、セキュリティスキャン、あるいはプロジェクト管理といった機能を、エディターとシームレスに統合できるのであれば、それは単なるGitHubのクローンではなく、次世代の「AIファースト」な開発環境として独自の価値を提供できる可能性があります。特に、AIの力を最大限に引き出すことを重視する開発者にとっては、魅力的な選択肢となるかもしれません。 もちろん、GitHubのコミュニティの規模や既存のインテグレーションの多さは圧倒的です。Cursorがどこまでその差を埋め、開発者を惹きつけられるかが見どころです。しかし、競争が活発になることは、結果的に開発者にとってより良いツールが生まれるきっかけとなるため、非常に楽しみな展開だと考えています。 オリジナル記事はこちらです。 Cursor capitalizes on GitHub frustration, launches rival hosting platform

Fairphone 6とPostmarketOS: メインカメラ動作で広がる可能性

最近、Fairphone 6でPostmarketOSのメインカメラが動作したというニュースを見て、思わず胸が高鳴りました。これは単なる技術的な進歩というだけでなく、私たちが使うデバイスの未来、そしてサステナビリティとオープンソースの可能性について深く考えさせられる出来事です。 ご存じの方もいるかもしれませんが、Fairphoneは倫理的な素材調達と高い修理可能性を特徴とするスマートフォンです。一方、PostmarketOSは、スマートフォンを含むさまざまなモバイルデバイスでLinuxディストリビューションを動かすことを目指す、非常に意欲的なプロジェクトです。今回のニュースは、Fairphone 6上でPostmarketOSが稼働し、これまで課題となっていたメインカメラの機能がようやく動作するようになったというもの。スマートフォンでカメラが使えないというのは実用上大きな問題でしたが、これが解決されたことで、Fairphone 6をPostmarketOS搭載デバイスとして日常使いに一歩近づける大きなマイルストーンとなります。特に、独自のドライバーやファームウェアが必要となるカメラ機能がオープンソースの環境で動作するようになったことは、その技術的な障壁の高さを考えると本当に素晴らしい成果です。 私は常々、私たちが使うデバイスにもっと自由と選択肢が欲しいと思っています。メーカーが提供するOSだけでなく、自分で好きなOSを選んで使えるような環境は、技術愛好家にとって夢のような話です。Fairphoneのような修理可能なハードウェアと、PostmarketOSのようなオープンなソフトウェアが組み合わさることで、デバイスの寿命を延ばし、環境負荷を減らすだけでなく、ユーザーが自分のデバイスを完全にコントロールできるという、真のデジタル所有権が実現します。現代のスマートフォンは、購入から数年でOSのサポートが切れたり、バッテリー交換が困難だったりして、まだまだ使い続けられるハードウェアであるにもかかわらず、買い替えを余儀なくされることが多いです。しかし、FairphoneとPostmarketOSの組み合わせは、そうした「計画的陳腐化」へのアンチテーゼとなり得るでしょう。まだ完全に日常使いできるレベルではないかもしれませんが、この一歩は非常に大きく、今後のさらなる進展に大いに期待しています。いつか、自分で選んだLinuxベースのOSを搭載した、修理可能なスマホで快適に過ごせる日が来ることを願ってやみません。 Fairphone 6 and PostmarketOS working main camera