このニュースは背筋が凍りました。 MetaがロシアのYandexと同じ手口でユーザーの行動を追跡していたことが判明、何百万ものウェブサイトに「スマホのアプリと通信するコード」を埋め込んで追跡しておりブラウザの履歴を削除しても無駄 通常、ウェブブラウザには「同一オリジンポリシー (Same-Origin Policy)」というセキュリティ機能があり、異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）間でリソースを共有することを厳しく制限しています。Cross-Origin Resource Sharing (CORS) はこの制限を緩和するためのメカニズムですが、明示的な許可が必要です。 Meta Pixel がこの規制をどのようにバイパスしたのか、最新の調査結果に基づいて説明します。 localhostソケットとWebRTCの悪用 Meta PixelがCross-Originの規制をバイパスした主な手口は、以下の組み合わせにありました。 localhostポートの利用: Metaが提供するAndroidアプリ（Facebook、Instagramなど）が、デバイス内の特定のローカルポート（例えば12580-12585）をサイレントにリッスンしていました。つまり、アプリがウェブサイトからの通信を受け入れる準備ができていたということです。 ウェブサイトに埋め込まれたMeta PixelのJavaScriptコードは、モバイルブラウザ上で実行される際に、localhost (127.0.0.1) のこれらのポートに対して通信を試みました。 localhostへの通信は、ブラウザの同一オリジンポリシーのスコープ外、またはその穴を突く形で行われました。ブラウザは、自身のデバイス内のローカルホストへの通信に対しては、比較的制限が緩い場合があります。 WebRTC (Web Real-Time Communication) の利用: Meta Pixelは、WebRTCというリアルタイム通信プロトコルを利用して、_fbp Cookie（ブラウザを識別するファーストパーティCookie）などの追跡データをlocalhostのアプリに送信していました。 WebRTCは、ブラウザ間の直接通信や、ブラウザとローカルネットワーク内のデバイスとの通信を可能にするための技術であり、その機能がこの追跡に悪用された形です。特に、WebRTCのSDP (Session Description Protocol) というセッション情報をやり取りする部分が利用されたと報告されています（SDP munging）。 アプリ側でのデータリンケージ: Androidアプリは、localhost経由で受け取った_fbp Cookieを、アプリにログインしているユーザーの永続的な識別子（Facebook IDなど）と紐付けました。 これにより、ユーザーがブラウザでCookieを削除したり、シークレットモードを使ったり、Facebook/Instagramにログインしていなくても、そのウェブ閲覧履歴がMetaのユーザーアカウントに紐付けられて追跡されるという、従来のプライバシー保護メカニズムを回避する仕組みが実現されました。 Metaとサイト運営者の責任 実際に、"Disclosure: Covert Web-to-App Tracking via Localhost on Android“という調査報告書をチェックすると、日本のドメインだけでも以下のリストに見られるようなウェブサイトがMeta Pixelを使用している惨状が明らかになります。これはほんの一部に過ぎません。 https://auctions.yahoo.co.jp/ https://beauty.hotpepper.jp/ https://dmarket.docomo.ne.jp/ https://grapee.jp/ https://mechacomic.jp/ https://nlab.itmedia.co.jp/ https://page.auctions.yahoo.co.jp/ https://trilltrill.jp/ https://www.boatrace.jp/ https://www.cmoa.jp/ この状況は、Metaだけでなく、サイト運営者にも重い責任 があることを示しています。 この惨状から、私は次のことを強く要求します。 まず、Metaは今まで不法に採取したデータをすべて廃棄すること。 次に、サイト運営者はMetaから受け取った全ての違法データを廃棄すること。 これらが、ユーザーのプライバシーを守るために最低限必要な措置です。 楽天ad4U 今回のMeta Pixelの手口は、かつての「楽天ad4U」を想起させます。楽天ad4Uも一種の行動ターゲティング広告で、Adobe Flashオブジェクトの中に数千個のURLへのリンクを埋め込み、それぞれのURLを訪れた形跡があるか否かをCSSの色判定で調べる手口でした。 ...

不安しかない au IDや、「dアカウント」にログインしようとしたら、なぜか回線認証で詰んで先に進めない。機種変更したら、これまで使えていたサービスに紐付けられたdアカウントの再設定で地獄を見た──。そんな経験、ありませんか？ なぜなら、その背後には 「回線を持っているがゆえに、不便を強いられる」という、キャリア認証システムの根本的な問題 がちらついていたからです。 「dアカウント」にせよ、「au ID」にせよ、その 「King of ゴミ」 とも言うべき、回線認証の強要は、我々のデジタルライフを大きく阻害しています。ITmediaでも報じられたように、なぜdアカウントのUI/UXはこれほどまでに悪い評価で衆目の一致する所となっているのか。今回は、その根深い問題点、特に回線認証という 時代錯誤な仕組みが引き起こす弊害 に焦点を当て、なぜ我々がこれほどまでに不満を抱えているのかを徹底的に掘り下げていきます。 先ごろ、発表されたSBI住信の買収で不安を漏らす声が噴出しています。実際、ITmediaでも以下のような記事が書かれています。 なぜ、「dアカウント」は嫌われているのか　住信SBIネット銀行買収で、不安の声が上がるワケ 終わってるUser eXaust：キャリア認証の「糞」っぷり 私は家計簿アプリMoney Forwardでau PAYを含む複数の金融サービスを集約して管理していますが、その連携方法がユーザーに多大な「苦痛」をもたらしています。 Money Forward連携と「糞」なキャリア認証 まず、Money Forwardはau ID側からの適切なAPI提供がないため、不安定な「スクレイピング」でデータを収集せざるを得ません。これにより、au IDの認証が頻繁に切れてしまい、再認証の度に地獄を見ます。 この再認証プロセスが、まさに「User eXhaust」の極致です。 痛みしかないフロー Money Forwardでau Payからの認証切れを発見する おもむろに再認証を始める 認証しようとしたら、最初の壁、パスワード認証できないにぶつかる スマートフォンからパスワード認証を有効化しようとする スマートフォンアプリからは該当操作が見つからない wifiからは設定できない、回線認証の強制 糞そのもののキャリア認証 パスワード認証の無意味化と強制的なSMS認証: au IDのパスワード認証は、わずか15分で自動的に無効化されます。さらに、パスワードを有効にしようとすると「悪用に関する警告」が表示された上に、時代遅れのSMS認証が強制されます。安全で便利な時間ベースの二段階認証（TOTP）は選択肢にすらありません。 回線認証の強制とWi-Fi切断の強要: パスワード認証が無効化されると、次に強制されるのは「Wi-Fiを切って、VPNをオフにしろ」という「愚劣な回線認証」です。安定したWi-Fiを切り、特定のモバイル回線で接続し直すという不必要な手間は、ユーザーに計り知れないストレスを与えます。 設定変更の困難さ: これらのパスワード認証に関する設定は、My auアプリには存在せず、Webブラウザからしかアクセスできません。しかも、そのWeb設定もスマートフォンからしか行えないという多重の制約があり、スマートフォンが手元にない状況では完全に「詰み」ます。 PayPay連携も「アホすぎる」 PayPayの連携方法も同様にユーザーを疲弊させます。Money ForwardとPayPayを連携させる際、API連携ではなく、スマートフォンアプリ間で「インテント」を飛ばすという、極めて非効率で不安定な方法を強いてきます。この理解しづらい手間は、金銭管理という重要なタスクにおいて、ユーザーに「アホすぎる」苦痛を与えています。 信頼性と安定性の問題: アプリ間の連携は、アプリのバージョン、OSのバージョン、端末の設定など、様々な要因で不安定になる可能性があります。 バッテリー切れやアプリの不具合など、何らかの理由でPayPayアプリが使えない場合、連携自体ができなくなるリスクもあります。 テックジャイアントとキャリア認証の雲泥の差 GoogleやMicrosoftといった世界のテックジャイアントは、現在、パスキー、TOTP（時間ベースワンタイムパスワード）、フォールバックとしてのSMS、そして最終手段としての事前配布解除コードを組み合わせた認証基盤を標準としています。 これらの企業は、ユーザーがどのデバイス、どのネットワークからでも安全かつシームレスにサービスを利用できるよう、以下の点を重視しています。 フィッシング耐性の高いパスキーを基幹とする。 オフラインでも利用可能なTOTPを次点とする。 利便性とセキュリティを両立させる。 「回線認証」などという愚劣な認証を主要な手段として導入することはありません。 信用性が無い理由 古い技術への固執: 時代遅れで脆弱性が指摘されているSMS認証を主軸にしたり、利便性を著しく損なう回線認証に固執したりする時点で、最新のセキュリティ脅威に対する認識が甘いか、対応能力が低いと見なされます。 利便性の犠牲とユーザーへの負担: ユーザーに多大な手間やストレスを強いる認証システムは、結果的にユーザーがセキュリティ対策を回避しようとする行動を誘発しかねません。例えば、不便な設定を避けたり、パスワードを使い回したりするリスクを高めます。 「技術的腐敗」: 認証基盤が「技術的腐敗」の状態にあるということは、システム全体の整合性や信頼性が低いことを意味します。このような基盤の上で金銭取引が行われているとなると、潜在的な脆弱性や予期せぬトラブルのリスクが懸念されます。 ...

本日、スーパーレジェンド級の詐欺と思われるメールが着弾しました。 Apple Card（アップルカード）は2025年現在発行できる？現状や特徴を紹介 Appleが提供するクレジットカード「Apple Card」は、2025年4月現在、日本では利用できません。 そう、まだ、発行されていないカードです。私も、まだ、発行されていないカード で詐欺メールが来たのは初めてです。 では、メールを晒しますね。 本文としては以下の内容です。 カード情報の速やかなご確認 2025年5月26日にご登録のカードにおいて異常な使用が確認されました。現在、ご利用は一時的に制限されております。 Apple Cardのご利用を継続するため、2日以内に認証手続きを完了してください。情報は暗号化され保護されます。 残念ですが、この文面は100%、信頼不可能です。この種のメールは個人情報を詐取する目的で作られており、リンク先のサイトで情報を入力してしまうと、その情報は悪用される可能性が高いです。 まず、詐欺メールの基本技術として、緊急性を煽るなどが利用されています。これは、詐欺メールのもう、基本技術としてありふれていますね。 現在、ご利用は一時的に制限されております。 などは典型例です。 ある意味、未発行のカードを騙るという手口は盲点かもしれません。特に、Appleユーザはもしかすると騙されるかもしれません。この種のパターンは要注意かもしれません。しかし、未発行のカードという原点を忘れなければ騙されようがありません。 もし、このようなメールを受信しても、慌ててリンクをクリックしたり、情報を入力したりしないでください。まずはAppleの公式サイトにアクセスし、ご自身のApple IDでログインして状況を確認するようにしましょう。不審なメールは、Appleに報告することも可能です。この時、メール上のリンクの使用は厳禁です。アカウント情報を登用される恐れがあります。

私が、経験した中でも最低の部類の幻影に遭遇した。 言うまでもなく、2025年1月21日以降はトランプ政権である。しかし、現状、殆どのLLMは2024年前後で歴史が止まっている。しかし、Geminiはどうやら、RAGで最新化するという機能が弱い。そのため、意識的にURIが与えられないと、事実を補正することが出来ない、また、投入される情報もどうやら、Googleとの提携関係などに依存する部分が大きい。 しかし、このように、自信たっぷりに、虚偽の事象を開陳してしまう。 これは、所謂、ハルシネーションの典型的な事例です。 ハルシネーションの原因としては以下のようなものがあります。 情報の不足：モデルが学習データにない情報を推測して補完しようとする。 RAGの限界：適切な情報を取得できない場合、誤った情報がそのまま出力される。 モデルのバイアス：特定のデータソースに依存するため、偏った情報が生成される可能性がある。 今回のは状況として、まず、恐らく、RAGによる情報の最新化が動いていません。恐らく、情報の不足とモデルのバイアスに引きずられた格好です。GeminiはDeep Researchは強力ですが、現時点では、Gemini 2.5 Flashなどではまだ、ハルシネーションがきついようですね。 あと、Geminiでは唐突にロシア語化する問題を確認しています。今のところ、発生はランダムで、前世代のGemini 2.0で頻発しましたが、現行世代のGemini 2.5 Flashでも同様に発生します。この件は、幾つか報告があります。 Geminiの回答にロシア語が混ざる！原因と今すぐできる対処法 Gemini 2.0 がロシア語を混ぜて回答してくる問題 まず、分かっているところを整理すると、特に会話のコンテキストが長くなる、要は会話のキャッチボールが長くなると問題の発生が多くなる。つまり、コンテキスト周りに問題がある可能性がある。さらに、生成されたロシア語っぽい文字列をdeeeplで翻訳すると意味に関しては大きく外れていないようにも見受けられる。 従って、メモリー破壊などのバグによる生成とは考えにくく、プロセスとしては正常動作の可能性が高い。故に、エラーログなどでの調査は不首尾に終わる可能性が高い。 考えられるのはドリフトなどかと思います。あと、状況からして、専門用語などが不具合を起こしているように見受けられるので未知語などの処理、特に埋め込みベクトルの問題が強いように思いました。 まず、学習データの問題の可能性は低いと考えています。理由は、だとすれば初手から表れてもおかしくないからです。むしろ、コンテキストが深くなると発生するということはコンテキストの深化で何らかの異常が発生すると見られます。 現在、Gemma 3で同様の問題が発生するかトライを試みています。新規の更新がありましたら報告します。

“採血データを使った心不全予測"のコンペに参加したので、解法を示します。まず、基本的に、2つの分類の予測問題は元々慣れていたので基本的なフレームとしては以下の通りです。 探索的データ分析 ベースラインモデルの作成 予測モデルの作成 探索的データ分析 まず、最初にデータを一応概観してみました。 発売中の技術同人誌 “Pythonによる探索的データ分析クックブック“でも触れている、ydata-profilingを使用しています。 import os import sys import pandas as pd import polars as pl import pyarrow as pa import numpy as np import matplotlib.pyplot as plt import seaborn as sns from ydata_profiling import ProfileReport train_df = pd.read_csv("../data/train.csv") test_df = pd.read_csv("../data/test.csv") profile = ProfileReport(train_df, title="Heart Failure Report") profile.to_file("../profile/heart_failure_report.html") ベースラインモデルの作成 基本線となるベースラインモデルを作成しました。ベースラインモデルは文字通りベースラインモデルなので、複雑なものは避けるのがセオリーです。今回は二つの分類をするタイプなので、一般化線形回帰でロジスティック回帰に持ち込むのを基本としました。また、stepwiseなどの容易さから、一旦、Rでモデリングを進めました。 コードとしては以下のシンプルきわまるものです。 require(dplyr) require(readr) require(ggplot2) require(pROC) train.df <- read.csv("../data/train.csv") test.df <- read.csv("../data/test.csv") train.df <- train.df %>% mutate( anaemia = as.factor(anaemia), diabetes = as.factor(diabetes), high_blood_pressure = as.factor(high_blood_pressure), sex = as.factor(sex), smoking = as.factor(smoking), target = as.factor(target) ) require(MASS) model <- glm(formula = target ~ age + anaemia + creatinine_phosphokinase + diabetes + ejection_fraction + high_blood_pressure + platelets + serum_creatinine + serum_sodium + sex + smoking + time, data = train.df, family = binomial) model.opt <- stepAIC(model) pred.df <- predict(model.opt, train.df, type = "response") roc_curve <- roc(train.df$target, pred.df) auc_value <- auc(roc_curve) ar_value <- (auc_value - 0.5) * 2 print(paste("AR値:", ar_value)) cat("Length of Cumulative_Percentage:", length(seq(0, 1, length.out = nrow(train.df))), "\n") cat("Length of Predicted_Positive:", length(sort(pred.df, decreasing = TRUE)), "\n") cat("Length of Actual_Positive:", length(sort(as.numeric(train.df$target), decreasing = TRUE)), "\n") sorted_predictions <- sort(pred.df, decreasing = TRUE) # 予測確率を降順に sorted_targets <- sort(as.numeric(as.character(train.df$target)), decreasing = TRUE) # 実ターゲットを降順に n <- min(length(sorted_predictions), length(sorted_targets)) cumulative_data <- data.frame( Cumulative_Percentage = seq(0, 1, length.out = n), Predicted_Positive = cumsum(sorted_predictions[1:n]), Actual_Positive = cumsum(sorted_targets[1:n]) ) ggplot(cumulative_data, aes(x = Cumulative_Percentage)) + geom_line(aes(y = Predicted_Positive, color = "モデル予測")) + geom_line(aes(y = Actual_Positive, color = "実データ")) + scale_y_continuous(name = "累積正例率", limits = c(0, max(cumulative_data$Predicted_Positive, cumulative_data$Actual_Positive))) + scale_x_continuous(name = "累積パーセンテージ", limits = c(0, 1)) + labs(title = "CAP図") + theme_minimal() 最終的には以下のCAP図になりました、 ...