AI Weekly Malaysia

MyDigital ID's Android app now supports the next-gen MyKad, letting new cardholders complete identity registration online after updating via the Google Play Store; iOS and Huawei users still have no timeline and must use a physical kiosk if urgent. The new MyKad launched on 16 September with 53 security elements including contact and contactless NFC and an enforcement QR code, but its redesign (chip left, no photo on the right) broke eKYC matching — the new card was rejected when signing up for TNG eWallet, Ryt Bank, AEON Bank and GXBank because the MyDigital ID app still rendered the old card template.

Why: If you run or integrate Malaysian onboarding, the new MyKad has been failing eKYC since mid-September at four named institutions (TNG eWallet, Ryt Bank, AEON Bank, GXBank) purely because of a card template mismatch — that is a fixable image/template assumption in your pipeline, not a chip or NFC problem. Anyone shipping a mobile app that touches identity should note this rollout is Android-first with no iOS or Huawei date given, so you cannot assume all users can self-register; plan a kiosk or JPN pre-registration fallback and ask your eKYC vendor whether their template library already covers the 16 September card.

Google announced that Android 17, when Advanced Protection is enabled, will restrict AccessibilityService access exclusively to verified apps categorized as Accessibility Tools. The AccessibilityService API runs in the background, intercepts UI events and acts on other apps; Google says banking trojans and spyware have abused it to read sensitive data, draw fake login screens over legitimate apps, log keystrokes and initiate fraudulent transfers without root. The post also lists earlier countermeasures: blocking sideloaded apps from enabling accessibility services, in-call protections against disabling Play Protect or granting accessibility permissions, and the accessibilityDataSensitive flag developers can set on sensitive views or composables.

Why: If your Android app uses AccessibilityService for anything other than assistive technology — automation, screen reading, UI scripting, task bots — it will stop working for any user with Advanced Protection on, so check whether your app can be verified and categorized as an Accessibility Tool before your next release. Separately, the accessibilityDataSensitive flag mentioned here is something you can set today on views/composables that show balances, OTPs or personal data, which is a concrete hardening step you can ship without waiting for Android 17.

StreetComplete's long-running iOS tracking issue (#5421, opened Dec 20, 2023) has reached 11/11 completed tasks and is now in public beta on iOS. The port keeps the app's 100% Kotlin codebase and uses Kotlin Multiplatform with Compose Multiplatform for the UI, rather than rewriting everything in Dart as Flutter would require (the approach Every Door took). The plan explicitly includes incrementally migrating the existing Android XML layouts to Jetpack Compose and separating platform-specific code from application logic; the repo has 4.9k stars and 457 forks, and the HN thread drew 309 points and 63 comments.

Why: If you maintain a Kotlin Android app and have deferred iOS, this is a concrete worked example of the KMP path: one codebase retained, but the entire UI still has to be re-created in Compose Multiplatform — so the real cost is a UI migration, not a free second platform. The decision point it sharpens is KMP vs Flutter: StreetComplete chose KMP specifically to avoid rewriting its Kotlin logic in Dart. There is no Malaysian or SEA angle in this text; the impact is limited to teams doing cross-platform mobile work.

Cleafy traced nearly 100 deployments since April 2026 of the RatHat Android banking-trojan console, run as malware-as-a-service where each customer operates a separate copy. The latest console versions — following an earlier one called Fisher and newer builds named BlackCat Remote Control Management and Panda Workshop V5/V6 — feed captured text messages and credentials from fake banking-app overlays to Google's Gemini to estimate each victim's bank balance and sort phones into high-value and mid-value groups; Cleafy found no use of the model to move money, only to decide 'which victims are worth an operator's time.' The console doubles as a build tool: it signs the malicious app, publishes it to Amazon S3 or a web server, and can rebuild it hourly to change the file hash, while the on-device malware abuses Accessibility access to enable wireless debugging, read the ADB pairing code off the screen, and open a shell through Android Debug Bridge.

Why: Two concrete things to act on. First, the on-device chain is Accessibility access → enable wireless debugging → read the pairing code → ADB shell, so if you ship an Android app, that sequence — not generic 'mobile malware' — is what you should test against and consider detecting. Second, hourly rebuilds from the same malware source mean any pipeline relying on file-hash matching to spot known bad apps will miss these; if you use hash-based scanning for sideloaded builds, that gap is now demonstrated at ~100 console deployments. For anyone adding an LLM to a product, the Gemini use here is purely ranking/triage with no write access, which is the low-risk adoption pattern.

Northeastern University researchers, working with Consumer Reports, ran what they describe as the first large-scale measurement study of the connected-vehicle ecosystem, testing 21 late-model vehicles across 19 brands plus 30 companion mobile apps. They found 19 of 21 vehicles contacted at least one third party over Wi-Fi, 7 of 30 apps transmitted PII to trackers, and 5 of 30 sent VIN plus other PII to trackers. Consumer Reports supplied the vehicle fleet, which the team says would have cost over $1.2M to assemble independently; the peer-reviewed paper lands at IMC '26, and the Hacker News thread drew 233 points and 195 comments.

Why: The number to act on is 7 of 30: roughly a quarter of the tested companion apps leaked personal data to third-party trackers without it being an obvious product feature, and 5 leaked the VIN itself. If you ship a mobile app with analytics, attribution, or ad SDKs, this is a concrete reason to capture your app's outbound traffic and check what identifiers those SDKs attach — a VIN or device identifier leaving your app is a compliance problem you inherit, not one the SDK vendor absorbs. There is no Malaysia-specific finding in the text, so local relevance is indirect: anyone building insurtech, fleet, or vehicle-adjacent apps should treat third-party SDK data flows as part of their own privacy surface.

Researchers at Northeastern University, working with Consumer Reports, tested 21 late-model vehicles from 17 automakers (including Cadillac, Chevrolet, Ford, Lucid, Rivian, Tesla and Toyota) plus 30 companion mobile apps. Nineteen of the 21 vehicles sent traffic to at least one third party — including Adobe, ContentSquare, Google, Microsoft, Meta, Snap and Yahoo — and 7 of the 30 apps handed over sensitive data such as VIN, email, phone number and precise location to tracking and advertising companies. Pairing the app to the car roughly doubled the exposure to advertising and tracking, per the peer-reviewed study.

Why: If you ship a mobile app that embeds third-party analytics or ad SDKs, this is a concrete measurement of what 'linking an account' does: the study found app-to-vehicle pairing roughly doubled tracking exposure, and 7 of 30 apps leaked VIN, email, phone and precise location. Check whether your own SDKs collect precise location and device identifiers, and whether logging a user in with a stable ID merges an anonymous device profile into an advertising profile. Note the study covers US-market vehicles and apps, and names no Malaysian automaker, telco or app, so this is a privacy-engineering lesson for local builders, not a local policy or regulatory finding.

A Hacker News submission titled "A Privacy Analysis of Web and Mobile Conversational AI Agents" (subtitle: "Prompt like a butterfly, sting like a tracker"), hosted on jorgegarciaherrero.com, drew 378 points and 121 comments. The submitted file is a PDF whose extracted text is raw PDF object/stream data, so no findings, methodology, sample sizes, tracker names, or measurements could be read from the text provided here. Only the title, the tracker-focused subtitle, the source domain, and the discussion activity are verifiable.

Why: You cannot act on this one yet: the PDF text did not decode, so there is no list of trackers, no count of apps or sites tested, and no finding to verify. The one concrete thing you can act on is the community signal — 378 points and 121 comments means a meaningful slice of this audience cared enough to read and argue about conversational-agent privacy. If you ship an embedded chat widget or a conversational agent on web or mobile, the actionable step is to check it yourself before quoting this paper: open your own agent's network tab and confirm which third-party analytics or ad domains load on first message.

Apple Pay launched in India on Tuesday, September 29, 2026, with Axis Bank as its first and only banking partner, supporting eligible Axis Bank Visa and Mastercard cards — but not the homegrown RuPay network — and only at merchants and terminals enabled for the service. Apple is asking roughly 20 basis points per transaction, which sources describe as a significant bite out of the 40–50 basis points of margin in the payments layer; HDFC Bank, ICICI Bank and SBI Card are not supporting Apple Pay at launch while commercial terms are still being negotiated. Unlike India's UPI system, Apple Pay is card-based, so each issuer and infrastructure provider has to integrate separately, which the report says makes a broad rollout harder.

Why: For anyone building payments or checkout in Malaysia, the number that matters here is Apple's ~20 bps ask against a 40–50 bps payments-layer margin — roughly half the spread — which is the same commercial question local acquirers and issuers would face if Apple Pay arrives in a market where DuitNow QR already handles instant bank-to-bank transfers at near-zero cost to the merchant. If you're choosing which rails to support in a Malaysian product roadmap, treat card-wallet support as a margin decision, not a checkbox, and note that India's launch excludes RuPay and three of its largest issuers — a domestic-network exclusion pattern worth watching locally.

404 Media reports that Magnet Forensics, the company behind the GrayKey iPhone unlocking tool sold to law enforcement, claims in a leaked promotional video to have defeated Apple's iOS 'inactivity reboot' — the feature Apple quietly added around November 2024 that reboots an iPhone after 72 hours without an unlock. The claimed workaround is a new device called GrayKey Preserve plus an 'Evidence Preservation Mode' feature for existing GrayKey units, which reportedly freezes iPhones in a state that keeps them accessible to forensic extraction. The claims come from a vendor marketing video obtained by 404 Media, not independent technical verification, and the article itself sits behind a paid membership wall.

Why: For most builders this changes nothing you can act on: it is a vendor claim in a leaked promo video about a physical-access forensic tool, not a CVE, an API change, or a remote attack. The one decision worth making is whether any part of your threat model rests on 'the phone is locked, therefore the data is out of reach' — if your team issues iPhones to field staff, handles seized-device evidence, or writes privacy copy implying locked devices are safe, that assumption is now explicitly contested by the vendor's own marketing. If you store user secrets only in app-sandbox storage on iOS, this is not a reason to re-architect; the text gives no mechanism, no iOS version, no device list, and no independent test result.