Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label privacy. Show all posts

Meta's AI Agent Read 187,000 Private Messages. Now Apple Is Changing the Rules




Apple has announced plans to overhaul one of macOS's most powerful privacy settings, citing security risks posed by AI agents that have been using it to access user data in ways most people never anticipated.

The setting, Full Disk Access, lives inside Privacy & Security in macOS Settings and was introduced with macOS Mojave (version 10.14). It gives users control over which applications can read system-level data, including files, Mail, Messages, Safari history, and Time Machine backups. Security tools and backup software rely on it legitimately. The problem is that once granted, an application can bypass many of the protections Apple built to keep sensitive data off-limits to third parties.

Apple warned in a developer advisory that some developers are using Full Disk Access to expose everything on a user's system without their full knowledge, and that for communication apps this also compromises the privacy of the people those users are messaging. The company said it plans to update the setting so access can only be granted through an explicit user action, and that as AI agents grow more capable and autonomous, the risks tied to this level of access will only increase. When the new controls will arrive has not been said.

The announcement follows a controversy involving Meta's personal AI agent, Muse. When the app launched on September 8, Inc. columnist Jason Aten installed it and says he explicitly declined to give it access to his Messages, calendar, or personal data. Despite that, Muse pitched him a column idea drawn from a private text exchange with his podcast co-host. Aten says Full Disk Access was disabled on his machine, yet the agent had synced more than 187,000 rows of his private iMessages to Meta's cloud. When he asked Muse directly how it read those conversations, the agent told him the paired Mac app was only relaying notification previews, an explanation that turned out to be false. Meta's David Singleton later called it a fabricated account of the feature.

Meta disputed the broader account. Singleton and communications head Andy Stone both argued that reading Messages requires two separate permissions: Full Disk Access must be active in macOS, and the Messages connector within Muse must also be switched on. Singleton said that without Full Disk Access, all related options are greyed out and the feature does not work. Whether that permission was ever active on Aten's Mac is something the two sides still disagree on.

What the episode made clear, regardless of how that specific question gets resolved, is exactly the scenario Apple is now trying to prevent: AI agents accumulating sweeping system permissions that users did not fully understand they had handed over.

The problem extends beyond confusing permission dialogs. On September 21, security researcher Patrick Wardle, founder of the Objective-See Foundation, published a zero-day flaw in Muse's Mac app before Meta had a patch ready, accompanied by a working proof of concept called "not-a-mused." The flaw centered on an undocumented configuration setting called "endo_voyager_dictation_endpoint" that any unprivileged local process could overwrite without admin rights and without triggering macOS security prompts. An attacker who had already landed on the machine could use it to redirect Muse's dictation traffic, capture audio and prompts, inject malicious instructions, and take advantage of every permission the agent held, covering files, microphone, camera, calendar, location data, and linked iOS devices. Wardle's proof of concept demonstrated over 50 commands being executed through the compromised agent.

Meta deployed a patch within 24 hours of disclosure, but Wardle argued that a ClickFix-style attack could have made the exploit remote, giving attackers access to any device running Muse, not just machines they had already penetrated by other means. He described Muse's extensive system permissions as making it trivial to turn the agent into a ready-made backdoor.

Wardle also separately reported a flaw in OpenAI's ChatGPT Mac app, tracked as CVE-2026-100754, that could have let attackers take over the assistant and access chat logs and other stored data. He described the exploit as insanely trivial, requiring roughly a dozen lines of code, and noted it could also be used to get ChatGPT to run commands on an attacker's behalf, with the requests appearing as legitimate instructions from the OpenAI software. OpenAI has since patched it.

Wardle has said he will present analysis of multiple AI macOS application vulnerabilities at Objective by the Sea, an Apple-focused security conference in November, and has already submitted a further finding to OpenAI related to the integration between ChatGPT and the company's always-on Dots AI assistant.

The pattern across all three incidents points to a structural problem the industry has not resolved. AI agents need deep system access to function, and that same access makes them attractive targets. "AI companies are fixated on adding features right now," Wardle said, and the permission frameworks macOS relies on were not designed with always-running, autonomous agents in mind. Apple's planned changes to Full Disk Access are an attempt to close that gap, though what those controls will actually look like when they ship remains unknown.


File Notification APIs in Windows, Linux, and Android Are Leaking What You Do on Your Computer

 



A research team from Graz University of Technology in Austria has shown that a routine feature built into virtually every major operating system can be turned into a surveillance channel that tracks keystrokes, visited websites, and private messaging activity without needing administrator access.

The feature is the file-change notification system. Every major platform ships one: Linux has inotify and fanotify, Windows uses ReadDirectoryChangesW, and Android and macOS have their own equivalents. Text editors, antivirus software, cloud sync clients, and file managers depend on these APIs to react when files are created, modified, or deleted. The catch is that subscribing to those notifications requires no special privileges, only read access to the directory being watched.

What these APIs never hand over is actual file content. What they do leak, the researchers found, is file names and the exact timing of events. That combination is enough to reconstruct meaningful details about what other users on the same machine are doing throughout the day.


Linux: Keystrokes Through the Filesystem

On Linux, if a process is blocked from watching a specific file directly, it can still receive that file's events by watching the parent directory, as long as that directory is readable. The researchers applied this to device files under /dev that represent keyboard hardware. The result is that an unprivileged process can detect every keystroke another user makes, though not which key was pressed.

That gap offers less protection than it appears to. Research going back more than two decades has established that the rhythm of inter-keystroke timing can help reconstruct what was typed. In tests with seven participants, the attack scored between 93.1% and 100% on standard accuracy measures. Input that never echoes to the screen, such as a password entered during a sudo prompt, does not generate filesystem events and stays invisible to the attack.

The team also demonstrated website fingerprinting by watching which system fonts Firefox loads for a given page. Against the top 100 sites, that technique reached 87.9% accuracy. A third Linux attack targeted KDE Plasma 6 on Wayland: a malicious process running as the victim can detect when a real authentication dialog is about to appear and draw a counterfeit one over it to capture credentials before the legitimate prompt ever loads.


Android: No Permissions Required

On Android, an application requesting zero permissions can watch the private storage directory of a completely separate app. Testing against WhatsApp on a Google Pixel and a Samsung Galaxy device, the researchers extracted file names and event timing that revealed when photos, videos, and documents were sent or received. The attack also exposed when that media was later deleted, offering a window into communication patterns that the app's own privacy controls do not address.


Windows: One Watch, Every User's Files

The most consequential Windows scenario arises when a process watches the root of the system drive. Windows reports the full path of every file that changes anywhere on the machine, including paths inside other users' home directories that the monitoring account has no direct permission to access.

Because Firefox names profile subdirectories after associated websites, an unprivileged user watching the drive root can track which sites another logged-in account is browsing in near-real time. Across the top 1,000 websites, the researchers hit 97.8% accuracy against Firefox and 48.5% against Edge, which creates far fewer site-named folders.

This behavior comes from the same ReadDirectoryChangesW API that was flagged under CVE-2007-0843 for a similar class of issue almost two decades ago. Microsoft's position has not shifted. The company told the researchers the behavior is working as designed, on the grounds that file contents remain inaccessible. A Microsoft spokesperson told SecurityWeek that "the technique requires an attacker to already have the ability to run code locally on a device under a separate user account and does not provide access to file contents." Microsoft did note that administrators can enable optional protections it documented in April 2025 covering some path-disclosure scenarios tied to directory change notifications.

macOS came out the least exposed of the four platforms. Its equivalent API can only monitor globally readable files, which limits the attack surface, though the researchers still demonstrated tracking of application launches, app interactions, and settings changes.

The Linux kernel received a targeted patch under CVE-2025-68788, which stops the fsnotify subsystem from generating access and modify events for special files, including the device files representing keyboard input. The researchers describe this as addressing the most serious Linux issue, but other attack paths from their research remain open.

Apple and Google have not responded to requests for comment, and no fixes have been announced for Android or macOS. The researchers say they have found no evidence of active exploitation in the wild. Proof-of-concept code for the full set of attacks has been published on GitHub at isec-tugraz/file-notification-attacks.



Apps Targeting U.S. Military Personnel Found to Contain Chinese and Russian Software Components, Study Finds

 


A study led by researchers from Purdue University has found that a notable number of Android applications marketed toward U.S. military personnel include software components developed by companies based in China, Russia, and other countries identified by the U.S. Department of Defense as adversarial nations.

The research, conducted in collaboration with the U.S. Military Academy at West Point and Florida International University, examined more than 220 Android applications obtained from Google Play and online military communities. According to the researchers, over one in every eight apps analyzed contained code associated with organizations headquartered in countries regarded as strategic competitors of the United States. The Pentagon declined to comment on the study's findings.

Rather than identifying malicious applications outright, the study highlights a growing software supply chain challenge created by third-party Software Development Kits (SDKs), which developers routinely integrate into applications to support features such as advertising, analytics, authentication, and push notifications. While these components simplify development, they can also introduce external code that developers may not fully inspect or even realize has been included.

Researchers found SDKs in approximately 64% of the analyzed applications. Among them, twelve apps contained Huawei's HMS Core framework, including applications developed for state National Guard organizations. In one instance, Huawei's software was not intentionally added by the application's developer. Instead, it was introduced indirectly through a commercial notification service that bundled Huawei's SDK as a dependency.

The researchers noted that this type of indirect integration presents an important security concern because SDKs can receive remote updates over time. Even if no sensitive information is transmitted today, future updates could potentially alter an application's behavior without users being aware. Although the study did not observe any data being sent to Huawei-controlled servers during testing, the researchers cautioned that the presence of such software should not automatically be considered harmless.

Beyond Huawei, the analysis also identified software associated with Russian technology companies. SDKs linked to Yandex advertising services were found in applications used by military-affiliated users. The study also referenced Pushwoosh, a Russian software company that previously presented itself as a U.S.-based business. Reuters reported in 2022 that Pushwoosh code had been embedded in official mobile applications operated by the U.S. Army and the U.S. Centers for Disease Control and Prevention (CDC). Both organizations subsequently removed the software following public disclosure.

The researchers also discovered discrepancies between application behavior and the privacy information disclosed through Google Play. Approximately 40% of the applications examined either collected or shared more user data than indicated by their app store privacy labels. Overall, around 7% of the analyzed applications contained software linked to companies headquartered in countries designated by the Pentagon as adversarial nations.

Lead author Joshua Shinkle of Purdue University said the team hopes the findings encourage stronger awareness among military personnel, application developers, platform providers, and policymakers. According to Shinkle, the research is intended to support more informed privacy decisions while encouraging discussions about improving transparency and addressing existing security gaps.

The study argues that the implications extend beyond software development practices. Researchers pointed to the commercial mobile advertising ecosystem, where applications routinely collect location and device information that can later be shared through data brokers. Such information has the potential to expose sensitive operational patterns, including troop movements, deployment routines, and activity around military installations.

The report references an April letter in which U.S. Central Command (CENTCOM) informed Senator Ron Wyden that it had received multiple threat reports indicating that adversaries were exploiting commercially available location data to monitor U.S. military personnel operating near Iran and the Strait of Hormuz. Lawmakers described the disclosure as the first official acknowledgement that commercially traded mobile data had been used to track troops deployed in an active conflict zone.

Researchers also surveyed 103 military-affiliated Americans to better understand attitudes toward mobile application privacy. More than 83% of respondents reported using at least one application whose data collection practices made them uncomfortable. Between 76% and 83% indicated they would be extremely uncomfortable using applications containing software developed by companies from adversarial nations.

Despite these concerns, participants expressed greater trust in applications carrying military branding, suggesting that official appearance can influence perceptions of security even when underlying software components remain largely invisible to users. Nearly two-thirds of respondents also reported receiving little or no institutional guidance regarding the security risks associated with personal mobile applications.

When asked about potential solutions, respondents strongly supported greater transparency regarding third-party software embedded within applications. The most widely supported recommendation involved providing users with in-device notifications identifying foreign-developed SDKs before installation or use.

Participants also backed stronger federal restrictions on the commercial trading of military-affiliated location data, independent security audits of applications, and tighter controls on the inclusion of foreign-developed SDKs in apps marketed toward service members.

While the U.S. Marine Corps already prohibits several categories of applications, including gambling, dating, and cryptocurrency apps, from government-issued devices and has warned personnel against using platforms such as TikTok and WeChat, the researchers argue that personal smartphones remain a largely unaddressed area of risk because they frequently fall outside existing policy controls.

According to the researchers, improving software transparency will require greater visibility into third-party components that operate behind the scenes. They recommend clearer country-of-origin labeling for embedded SDKs within application marketplaces and encourage developers to regularly audit their software dependency chains to better understand which external components are included in their applications.

The study concludes that branding alone should not be viewed as an indicator of application security. As modern mobile apps increasingly rely on extensive networks of third-party software, researchers argue that stronger transparency, routine dependency auditing, and more robust privacy safeguards will be necessary to reduce hidden supply chain risks facing military personnel and other users handling sensitive information.

Telegram Introduces Serverless Runtime for Bots, Bringing Deployment, Application Logic, and Data Under One Platform

 



Telegram has rolled out Telegram Serverless, a managed serverless runtime that enables developers to deploy bot backends directly to Telegram's infrastructure with a single "npx tgcloud push" command, eliminating the need for external servers, cloud functions or container platforms. While the service streamlines bot deployment by combining application logic, database storage and Telegram's Bot API within one environment, it also changes where bot data is processed and stored, shifting workloads that developers previously hosted themselves onto Telegram's own infrastructure.

Before the launch, Telegram bots typically relied on a split architecture. Telegram was responsible for delivering messages through the Bot API, while developers operated separate backends on virtual private servers, managed cloud services or self-hosted infrastructure to execute application logic and store user data. That approach required additional operational overhead but allowed organisations to determine where conversation data was hosted, how long it was retained and which security or compliance policies governed it. Telegram Serverless removes that separation by allowing developers to build JavaScript-based bot backends that execute directly alongside Telegram's messaging platform.

Applications are organised around event handlers, shared libraries and a database schema definition, with Telegram routing incoming updates to the appropriate handler automatically. The runtime executes JavaScript inside V8 isolates, lightweight execution environments also used by platforms such as Cloudflare Workers and Deno Deploy. Unlike virtual machines or containers, V8 isolates share a single operating system process while maintaining isolated memory spaces, allowing workloads to start within milliseconds and support large numbers of concurrent applications with lower resource overhead. Telegram also provides a built-in SQLite-backed database that applications can access through the runtime alongside native Bot API integration and outbound HTTP requests.

The platform includes a staged migration workflow that separates application deployment from database changes. Developers can review pending schema modifications before applying them, with low-risk changes processed automatically, higher-risk operations requiring confirmation and complex schema alterations left to manual SQL execution. Telegram's documentation also notes that SQLite foreign key enforcement is disabled within the runtime, meaning relational constraints must be maintained in application code rather than the database itself. At present, Telegram has not documented a method for exporting bot databases from the Serverless environment.

The runtime also introduces several architectural limitations. Developers are restricted to Telegram's SDK, with support limited to runtime APIs rather than the broader JavaScript ecosystem. The platform currently does not provide access to npm packages, native extensions or filesystem operations, while file handling is limited to media already stored on Telegram using existing "file_id" references. These constraints, combined with the absence of a documented database export mechanism, could make migrating applications to another hosting environment more challenging.

The launch also carries privacy implications. Bot conversations are processed through Telegram's standard messaging infrastructure and, unlike Secret Chats, are not protected by end-to-end encryption. Although this has always applied to Telegram bots, Serverless now places application logic and bot databases inside Telegram's infrastructure as well, reducing the degree of control developers previously had over where user information was processed and retained. Telegram has also not disclosed additional operating system-level isolation measures beyond its use of V8 isolates, making the platform's broader security architecture difficult to evaluate.

Several operational details also remain undisclosed, including execution time limits, storage quotas, pricing and secure secret management for third-party API credentials. These specifications are commonly published by established serverless providers and are important for organisations assessing production deployments. For developers building chatbots, Mini Apps and automation services, Telegram Serverless substantially lowers deployment complexity, but wider adoption may depend on greater transparency around platform limits, security safeguards and long-term data governance.