Apple itself leaked many mystery products that are coming out relatively soon. The leaked product identifiers proximity to others give some clues, but not many.

The release candidate for macOS Tahoe 26.7 was a trove of information for unreleased products. References to product identifiers littered the build, including for some known-about items.

For example, there was sightings of J490 and J491, believed to be versions of the Home Hub. B525 is expected to be the next-generation HomePod mini, while J229 was a potential security camera.

AirPods, iPhone, and Mac models were also sighted, as well as identifiers for what may be the OLED iPad mini and a next-generation Apple Vision Pro.

Unidentified identifiers

While that list includes quite a few product identifiers that are seemingly known about through previous rumors, there were also a bunch that were not.

A bunch of unusual codes like Device1,8241 were visible, but don’t really mean much in Apple’s established ecosystem.

But then there are other Apple product identifiers that look like they could be Apple products. However, at first glance, there doesn’t seem to be anything connected to them either.

They are, grouped:

• A3436, A3437, A3438, A3439, A3440, A3441
• A3456, A3457
• A3465
• A3529, A3530, A3531, A3532, A3533
• A3543
• A3577

These numbers alone don’t really hint at what Apple has planned for them in the future. But, looking at the rest of the catalog could provide a few more clues.

Above and Below

Apple tends to put products that are similar to each other within the same vague number range. Variants of the same model can easily be one step above or below the list, as demonstrated by that first row.

However, it doesn’t tend to include sequential generations to also be sequential numerically. You won’t find iPhone 17 numbers right after the iPhone 16, for example.

With that in mind, we looked for references to devices that are just one space above and below each of the groupings. For example, checking A3464 and A3466 around the listed A3465.

This is a numerical fishing expedition, certainly, and we did manage to find some things with some Google-Fu, retail trawling, and other more specific sources like AppleDB. Though, as expected, most were a bust.

The Apple World Travel AdapterKit came up a few times.

The most promising neighboring number was A3464, which is used for an M4 13-inch iPad Air with Wi-Fi and Cellular. This is a region-specific model just for Mainland China, and is actually confirmed by Apple as being the iPad Air.

A3442 appears to be a version of the 15-inch MacBook Air with M5, seemingly listed at JD.com.

A3466 is also for a known and sold product. Specifically the MagSafe Battery for the iPhone Air.

A3534 seems to be for a variant of the iPhone 17e in some countries.

A3455, A3458, and A3528 are for versions of the World Travel Adapter Kit. One is unspecified, but the others cover China and Australia.

The remaining few do not appear to have any real-world references to Apple as yet.

What can we deduce?

Blindly looking at numbers and for connected products doesn’t help much in this case. There’s not much to go on here, but we can make some assumptions.

First, we know that the A3456 and A3457 are bookended by World Travel Adapter Kits (A3455 and A3458). It’s not entirely a bad idea to assume Apple would put some form of accessory into that gap, or that it belongs to unreported variants of that kit.

The long ranges of identifiers also point to variants of a product, which is typical of Apple to do.

For the longer set from A3436 to A3441, one side extends to become the 15-inch MacBook Air, but the other is an unknown quantity.

What we can tell from this is that Apple doesn’t feel beholden to making identifiers work sequentially over time. Certainly per model and for variants, but not for an entire product family.

That there are two distinct banks of numbers means there will be models with multiple variants on the way. Think of the Pro and Pro Max variants of the iPhone, or screen sizes for a MacBook or iPad.

What’s certain is that Apple doesn’t make it easy for anyone to guess what’s next via its identifier list.

from the better-late-(and-minimal)-than-never dept

Flock Safety has spent a few years building a massive network of ALPR (automated license plate reader) cameras. Flock’s cameras are a step ahead of competitors. They not only grab plate/location info, but they provide searchable tags/images that cover everything from car make/model to specific vehicle features. These photos also include images of the drivers and passengers, which makes adding facial recognition tech the expected future development.

Flock has also built itself a reputation that only plays well with surveillance hawks and the worst people in law enforcement. It has made its database — something that adds around 20 billion car/plate images per month — accessible to any agency with a contract. And it has refused to add guardrails that might prevent federal agencies from utilizing local law enforcement access to perform searches they’re not legally allowed to do on their own. It has also portrayed misuse of its cameras and data as the actions of a few rogues that are not representative of its law enforcement customers.

Pretending it’s not responsible for abuse of its equipment/databases hasn’t worked out well for Flock. In addition to drawing heat from US senators, the company has lost a lot of its plausible deniability because it has done nothing to deter abuse of its systems… until now.

It looks like the last six weeks of concertedly negative press about cops using Flock tech to stalk their exes, their exes’ family members, and anyone else misogynist cops might want to keep tabs on has finally forced the company to do something, rather than just pretend it’s not Flock’s fault that far too many law enforcement officers are also horrible human beings.

Flock has finally recognized its most profitable market is littered with people who simply can’t be trusted with this access to billions of license plate records.

Following a Washington Post report that police officers were accused in 46 cases of improperly using access to Flock’s license plate camera network, in some instances allegedly stalking women, Flock CEO Garrett Langley said he had listened to one woman’s interview Thursday morning.

“I apologize,” Langley said in an interview with CBS News. “It kills me that she went through that.”

Asked if he took enough responsibility soon enough when it came to the accusations of abuses, Langley said hindsight is “a brutal tool.”

Words are nice. But Flock has always talked a lot but has steadfastly resisted implementing changes that might deter abuse of its systems. Almost everything that might make cops think twice before tracking their exes is optional, rather than on by default.

Some of that appears to be changing now that Flock’s CEO has been forced to confront the inevitable side effects of mass surveillance and unfettered law enforcement access. Here’s what Flock is doing now, following a half-decade or so of not giving a fuck.

• Flock is recommending a 7-day ALPR data retention period and introducing Evidence Mode to preserve specific data for active investigations when needed.
• New offense filtering, required Audit Assistance, proactive lockouts, and required case codes will give agencies more control while strengthening oversight of system use.
• Flock is strengthening data security through mandatory multi-factor authentication, an independent security review by Bishop Fox, and a new Coordinated Vulnerability Disclosure program.
• Customers retain ownership and control of their data, while Flock is expanding transparency and reinforcing safeguards around ALPR accuracy, access, sharing, and review.

It’s better than the nothing it’s been doing. But it still leaves a lot to be desired. As you can see from the first bullet point, data retention won’t actually be changing. Flock is only “recommending” a 7-day limit on retention. The standard retention period is 30 days. Contrary to reporting elsewhere, Flock is not limiting all customers to seven day retention periods.

That being said, Flock is at least making it slightly more difficult to extend the retention period. The seven-day limit will be on by default. And default mode tends to be the preference of everyone anywhere. With a bunch of cities kicking Flock to the curb, agencies that still retain access to their systems would do well to embrace the default limit, rather than poke the (general public) bear by switching things back to “always on forever.”

What’s better is Flock’s filtering system update, which will allow law enforcement agencies to prevent others agencies with access to their plate reads to run searches that might be forbidden in their own localities. To use something that isn’t even hypothetical, law enforcement agencies around the nation can now prevent Texas cops from using their cameras to hunt down women seeking out-of-state abortions. Just as importantly, it will thwart local agencies that have decided they want to be part of ICE’s entourage.

We are also introducing Offense filtering for sharing. Now, cities can choose which type of offenses are permissible for other agencies to access their cameras. For example, City A could allow City B to search its cameras only for a stolen vehicle, missing person, or violent crime while blocking searches related to immigration enforcement. 

Going further, Flock is making it easier for agencies to recognize misuse of the system and forcing those who just don’t care to fall in line with Flock’s abuse deterrents.

16 weeks ago, we introduced Audit Assistance, which detects abnormal activity and flags it for Administrator review. In recent weeks, those reviews have been associated with arrests of several law enforcement officers who allegedly abused the system. More than one-third of our customers have voluntarily adopted Audit Assistance. 

We will now require all law enforcement customers to adopt this feature by the end of this year. In addition, we will institute proactive lockout. When a user’s activity meets defined criteria for abnormal behavior, Flock will automatically suspend access pending administrator review. The goal is to intervene before misuse becomes recurring or widespread.

This is all… well, not exactly good news, but… better news? Flock’s systems are still a concern, given how much is collected and how often. But what’s implemented here will, at the very least, give cop shops a heads up on misuse and misconduct. And if officers know they’ll soon be subject to automatic account suspension if they can’t link searches to case numbers (which is what Audit Assistance requires), they’ll be less likely to use Flock to engage in stalking or harassment.

To be sure, the worst officers will still find some way to work around the safety checks and limitations. But police officers are like everyone else: a not-insignificant percentage are lazy and only do this sort of thing because it’s easy to do. Any minimal roadblock will shut them down because then the ex-stalking they do for fun is going to start feeling like work.

But let’s be clear here: I’m not looking to hang a “GOOD GUY TECH BRO” medal around the neck of Flock’s CEO. There’s still plenty to be concerned about here, including Flock’s apparent unwillingness to comply with cities’ requests to deactivate cameras following contract terminations or the startling prevalence of Flock cameras no government ever approved for installation.

Furthermore, there’s no real justification for these systems to exist at all. Both Flock and its law enforcement supporters claim the cameras help investigations and increase public safety. While it’s certainly true that this does happen from time to time, Flock has portrayed its systems as essential when that’s obviously not true. Crime rates have been at historical lows for most of the past 25 years. And this happened without persistent nationwide surveillance enabled by a network of souped-up ALPR cameras.

Pretending this is essential now deliberately ignores the last quarter-century of crime reduction efforts that didn’t rely on massive surveillance networks and private contractors only willing to do the right thing when it looked like blowing off the public might finally affect its bottom line.

Filed Under: acab, alpr, police misconduct, stalking, surveillance abuse

Companies: flock, flock safety

Security

Phishing, malvertising attacks could target devs to gain access to private corporate networks

CISA says attackers are exploiting a critical 2025 vulnerability in Ray, the widely used open source framework for scaling Python and machine-learning workloads. 

Tracked as CVE-2025-62593 and rated 9.4 under CVSS v4, the bug was first disclosed in November 2025. It allows an attacker to use Firefox or Safari to achieve remote code execution (RCE) on a vulnerable Ray system.

The open source distributed computing framework is used and supported by major tech companies, including Amazon, Apple, and OpenAI.

Vulnerable Ray versions try to identify and block browser requests by checking whether the User-Agent header begins with “Mozilla.” Firefox and Safari, however, allow scripts using the Fetch API to modify that header.

A developer running Ray could trigger the exploit simply by visiting a dodgy website or receiving a malicious ad in an affected browser. The attacker can then use DNS rebinding to reach the local Ray service.

“This vulnerability impacts developers running development/testing environments with Ray,” the project’s developers explained. “If they fall victim to a phishing attack, or are served a malicious ad, they can be exploited, and arbitrary shell code can be executed on their developer machine.

“This attack can also be leveraged to attack network-adjacent instances of Ray by leveraging the browser as a confused deputy intermediary to attack Ray instances running inside a private corporate network.”

Ray 2.52.0 fixes the flaw. CISA gave US federal civilian executive branch agencies three days to remediate it, rather than the standard 14.

CISA did not explain the urgency, and marked the catalog’s “known to be used in ransomware campaigns” field as “unknown.” However, Binding Operational Directive 26-04 allows the agency to impose a three-day remediation window on vulnerabilities it considers especially risky.

Ray is an open source framework that helps developers scale Python and machine-learning workloads from a local environment to a cluster with minimal code changes.

Now managed by the Linux Foundation’s PyTorch Foundation, the project started at UC Berkeley and was commercialized via Anyscale, the startup founded by Ray’s developers in 2019.

According to Anyscale’s figures as of October 2025, Ray had more than 237 million total downloads, and 7 million per week – representing a near-tenfold growth year-on-year.

Product analysis site NextSprints estimates that Ray has 1 million monthly active users and is used by 60 percent of Fortune 500 companies.

The security advisory blamed Ray’s longstanding lack of authentication on critical endpoints for making the attack possible.

Ray’s security model historically assumed that clusters would run inside a trusted, isolated network, leaving authentication and access control to the surrounding infrastructure.

Ray 2.52.0 introduced optional token-based authentication as an additional defense against unauthorized access, although it remains disabled by default. The project continues to recommend deploying clusters inside a controlled network rather than treating authentication as a substitute for isolation. ®

If you don’t actually need one, you’d be forgiven for thinking a hearing aid just makes everything louder for the wearer. Especially since there are plenty of shady products out there which will do exactly that for just four easy payments of $29.99. But the reality is considerably more complex, as a proper hearing aid needs to be capable of selectively enhancing certain frequencies while squashing down others.

The technical challenges involved in pulling that off in a device small enough to fit inside the human ear and run off of a tiny battery are considerable — and while there’s undoubtedly been some degree of artificial price inflation going on over the years, there’s a reason proper hearing aids have been so much more expensive than their “As Seen on TV” counterparts. These same challenges are also why DIY and open source hardware hearing aids have struggled to gain much traction.

But over the last few years the situation has changed. In 2022 the United States Food and Drug Administration (FDA) established the framework by which hearing aids could be sold over the counter (OTC). Although they’re generally less capable than their prescription counterparts and not suitable for individuals with profound hearing loss, the wide commercial availability of OTC hearing aids has kicked off a competition between manufacturers to deliver more affordable devices.

That competition entered a new phase earlier this month when the FDA granted approval for Samsung’s Galaxy Earbuds to fall under the same category. This follows a similar decision made about Apple’s AirPods back in 2024. The two biggest players in the smartphone market being able to offer their earbuds as OTC hearing aids represents a unique value proposition. Not only are they priced for mass market consumption, but many individuals who would be interested in purchasing an OTC hearing aid will already own them and need only to enable the feature with a software update.

Given how different the situation is today than even just five years ago it’s worth asking just what qualifies as a over-the-counter hearing aid, and how the shifting definition of these devices can inform the community’s efforts to develop open hardware solutions.

What is a Hearing Aid, Anyway?

We’ve already covered what a hearing aid isn’t, but before we go too much further it’s a good idea to clarify what exactly a hearing aid does in comparison to a simple audio amplifier, which in the industry are officially known as Personal Sound Amplification Products (PSAPs). This is a topic we’ve touched on previously here at Hackaday, but the short version is that since the 1980s or so, the frequencies that a hearing aid amplifies have been tailored to match the specific auditory deficiencies of the wearer.

Traditionally, getting a hearing aid prescribed would require going to an audiologist and getting an audiogram. This chart plots the results of a hearing test, and shows how well the patient can hear various frequencies. With this data, it’s possible to quantify the severity of a patient’s hearing loss and determine where a hearing aid could improve the situation. This information could then be programmed into a hearing aid to provide a bespoke amplification profile that takes into account the needs of the wearer.

It’s worth noting that this is only in the context of relatively modern digital hearing aids, essentially those created after the introduction of solid state electronics. Prior to that point, hearing aids were closer to what we would now consider PSAPs and amplified incoming audio indiscriminately.

Defining a Middle Ground

With this in mind, the primary difference between a prescription hearing aid and an OTC model is that the audiologist is cut out of the loop. That means there’s no audiogram, and in turn no data to program the hearing aid’s filters with. The specifics of this does vary from model to model, and both Samsung and Apple offer some basic audio testing tools that can help the user fine-tune their experience. But at this point, no OTC hearing aid product is capable of diagnosing the wearer’s hearing to the same level as a comprehensive hearing test performed by an audiologist

That being the case, it might seem like an OTC hearing aid is just a PSAP. But in their ruling, the FDA established the formal requirements for a device that falls somewhere in the middle. The full document, Medical Devices; Ear, Nose, and Throat Devices; Establishing Over-the-Counter Hearing Aids, comes in at around 200 pages if you’re looking for some light reading.

Fortunately, the agency provides a boiled-down list of what features a device must have to meet the definition of an OTC hearing aid. Some of the requirements have to do with the packaging and marketing of the product, which of course are important for a medical device, but it’s the technical parameters that we’re interested in.

The FDA specifies that all OTC hearing aids must use air-conduction, that is, operate with a speaker inserted into the ear canal. The alternative would be bone conduction, which is generally used in cases with more profound hearing loss. The devices must also allow users to adjust, at least to some degree, the output to match their specific needs.

The intention with this second requirement goes deeper than a simple volume control as you’d have in an PSAP. In lieu of the sort of tailored output a prescription hearing aid would offer, the OTC device can offer a selection of pre-defined audio filter profiles which the user could flip through. At the risk of oversimplifying things, it’s a bit like the audio presets for different genres of music that modern headphones and earbuds usually offer in that the user can cycle through different profiles to find what best matches the current environment.

When combined with the acknowledgement that OTC hearing aids can utilize wireless technology to communicate with another device, it’s not hard to see how the smartphone fits into the equation. While a stand-alone device is capable of meeting the requirements necessary for OTC hearing aid classification, being able to connect to the user’s phone to easily switch between audio profiles on the fly makes for a greatly improved user experience. Additionally, by playing tones through the earbuds, software on the phone can perform a hearing test on the user — the results of which can be used to fine-tune the output beyond what’s possible with simple presets.

Hackers, Take Note

Of course, anyone looking to build an open source hearing aid probably isn’t looking for FDA approval. The goal is likely to make the technology cheaper and more accessible, especially in areas where getting a commercially produced hearing aid may be difficult. As such, the new over-the-counter classification may not seem terribly important for folks like us.

But that doesn’t mean we can’t pick up some tips from what companies like Samsung, Apple, and Jabra are doing. By bringing the user’s smartphone into the mix, they have made hearing aids more accessible and easier to operate. Instead of trying to pack all of the functionality directly into the wearable, using a smartphone to do some of that heavy lifting opens up a lot of new possibilities. There are naturally trade-offs when switching a hardware problem for a software one, especially when dealing with mobile operating systems, but it may be a compromise worth making if it means getting this sort of assistive tech to more people that need it.

from the taking-my-ball-and-going-home dept

Paramount bosses Larry and David Ellison aren’t having much fun in the wake of a 12 state antitrust lawsuit that risks derailing their $111 billion attempt to dominate what’s left of U.S. corporate media.

There’s been a certain creeping desperation apparent the last month or two; whether it’s the company’s top lawyer claiming that critics of the deal are somehow antisemitic, or the continued threats that the company will leave California if states don’t back off their lawsuit. The company has also been funding no limit of shitty editorials trying to pretend further consolidation is just what Hollywood needs.

This report (paywalled) from Puck indicates that David Ellison is laying the groundwork to move Paramount to Tennessee, Texas, Georgia, or another state if California AG Rob Bonta doesn’t settle the antitrust case. It’s kind of an irrelevant threat in some contexts given that most U.S. film and TV production was already leaving California, and may occur whether or not the deal is approved.

Unfortunately for Ellison and his nepobaby kid, the old “I’m taking my ball and going home” threat doesn’t appear to be working on Bonta, and the antitrust lawsuit case is slated to begin next March — much later than the Ellisons were hoping. From Vulture:

“It’s possible Ellison and his team were hoping all of this would scare Rob Bonta, the state’s attorney general, into backing down. But so far, Bonta doesn’t seem cowed and has accused Paramount of “blackmail” in trying to get its way. And outside observers seem to agree: “Paramount’s PR campaign appears to be strengthening Bonta’s hand rather than weakening it,” the analysts at Lightshed wrote in a note to clients this week.”

Amusingly, a bunch of Paramount employees told Business Insider they were mostly just happy the merger was paused so they could focus on their work:

“It’s nice to be able to focus on what we do without the impending disruption that a merger in 2026 would have brought,” a high-level advertising employee said of the merger delay.”

Ellison is also trying to apply pressure on more corporate-cozy Democrats to push Bonta to support a deal (see: California Gubernatorial candidate Xavier Becerra, and off-the record comments by Gavin Newsom), but that doesn’t seem to be working either. In part because the U.S. cultural animosity toward billionaires and shitty giant companies is bubbling over, but also because time is simply on Bonta’s side.

Starting in October the company has to start paying a $7 million per day ticking fee to investors, which clearly has the Ellisons panicking. Larry’s over-extension in AI, should a bubble pop, could also complicate the financing for what’s already a very debt-heavy deal.

And again, it’s more than possible that Ellison follows through and moves Paramount out of California regardless of whether the deal is or isn’t approved simply to grab some tax breaks, putting a stake in the heart of an already reeling Hollywood that’s steadily watched most film and TV production migrate overseas.

But at the same time this exact sort of consolidation is just foundationally deadly. These deals always (and 50 years of data is not subtle on this point) result in mass layoffs, higher prices, less competition, and broad enshittification as the remaining company struggles to manage debt.

So for the few remaining regulators we have concerned about the public interest and labor, the best tack continues to be to simply block this and any other “growth for growth’s sake” consolidation. Though Ellison’s megamerger is extra shitty for numerous additional reasons, ranging from the dodgy financial support from overseas autocrats, to the Bari Weiss extraction class agitprop degradation of whatever’s left of journalistic institutions like CBS and CNN.

It’s very possible that Larry Ellison likely loses either way this goes. Either the state wins its antitrust lawsuit derailing his dreams of media domination, or he succeeds with his acquisition and is overloaded with debt while a bizarre assortment of nepobabies and brunchlords (who appear to have no idea what they’re doing) struggle to remain relevant as traditional broadcast TV heads toward extinction.

Filed Under: agitprop, bari weiss, california, consolidation, david ellison, journalism, lerry ellison, media, mergers, rob bonta

Companies: paramount, warner bros.

It started with avocados and ended with sensitive information being leaked.

Onstage at the Black Hat cybersecurity conference in Las Vegas, researchers Netanel Rubin and Dan Avraham pulled up an AI shopping assistant — the kind that’s available inside most major retail apps to answer questions, compare products and help shoppers navigate a store’s enormous catalog.

But the conversation didn’t stay on groceries for long.

By the end of the demonstration, the researchers had bypassed the assistant’s safeguards and forced code to run inside the computer environment behind it. The bot returned directory listings, environment variables and other information that an ordinary shopper should never be able to see.

In the wrong hands, that kind of information could give an attacker clues about the retailer’s systems and potentially expose secrets or access that could be used in further attacks, putting both the company and, depending on what the AI can reach, its customers at risk.

The retailer wasn’t a small online shop experimenting with a hastily assembled chatbot, either.

According to Rubin and Avraham’s company Rein Security, it was one of the three largest retailers in the US, and the assistant was available through the same public mobile app used by everyday customers. 

A few important notes: Rein Security sells technology designed to monitor AI agents and provide visibility into what those agents are doing. Rein also didn’t identify the retailer, citing legal concerns. That means the findings cannot be independently verified with the retailer, and shoppers can’t know whether they’ve used the affected assistant.

How the shopping assistant was tricked

The attack started with one of the assistant’s most useful abilities: comparing products.

To answer certain questions, the AI can retrieve information from websites outside the retailer’s control. That helps it gather more information for shoppers, but it also means the assistant can encounter material created by virtually anyone, including an attacker.

The researchers placed instructions in content they controlled and got the shopping assistant to retrieve them. Instead of treating that material only as information to summarize, the AI was manipulated into treating some of it as new directions to follow.

This is known as an indirect prompt injection. The malicious code can be hidden within a website, document, product listing or other material the AI encounters while trying to complete a legitimate task.

That alone wasn’t enough to reach the system behind the assistant, but it gave the researchers a starting point.

The retailer had installed a security layer that examines conversations and attempts to keep the assistant focused on shopping. If you ask it something outside its approved role, the request could be rejected.

The researchers found that those protections weren’t applied evenly. The main chat interface had safeguards in place, but the app’s regular search field didn’t have the same level of protection.

Through that less-protected input, Rubin and Avraham said they persuaded the assistant to reveal information about its internal setup, including the names of tools it could use and the syntax for calling them.

They then created another set of instructions that caused the assistant to run code inside its own computing environment — essentially the computer system where the AI was running. The assistant returned lists of files and other information about that system, showing that the prompt injection had worked and the researchers’ commands had actually been executed.

Rein’s public account doesn’t establish what else the assistant’s isolated environment could potentially access or whether an attacker could move from there into systems containing customer, payment or inventory data.

But getting code to run at all means the researchers were able to cross an important security boundary.

The researchers said they reported the vulnerabilities on March 13. As of July 16, more than 90 days later, Rein said they had not been fixed. The company has not publicly provided a newer update on whether the problems remain.

The researchers also stressed that they didn’t access real customer information, alter anyone’s orders or attempt to disrupt the retailer’s systems. Their work was performed in a controlled environment using their own session.

The AI wasn’t just talking

Chatbots have been manipulated into saying strange, offensive or unrelated things for years. But AI assistants can do more than generate answers; they can retrieve information, call outside services and use software tools to complete tasks.

Retailers want these assistants to eventually build shopping lists, check inventory, manage orders and even complete purchases. But each new ability creates another potential risk if the AI can be tricked into following the wrong instructions.

In this case, the retailer’s security system monitored what shoppers said to the AI and what it said back. According to Rein, it couldn’t see everything happening in between, including information the assistant retrieved and tools it used.

That created a blind spot in which the security system could see the conversation, but not everything the AI was doing behind it.

During their examination of the app, the researchers also found Google Maps API keys visible in traffic they decrypted from the mobile app. If those keys weren’t properly restricted, an attacker could potentially use them to make unauthorized requests to Google Maps services on the retailer’s account, running up charges or exhausting its usage limits. 

The researchers did not report accessing customer information with the keys, but an attacker could potentially use them to make unauthorized Google Maps requests at the retailer’s expense.

What it all means

There isn’t much an ordinary shopper can do to prevent this kind of vulnerability. The attack targeted the retailer’s design, not a weak password or a customer mistake.

The responsibility belongs to companies giving AI assistants access to internal tools and information. Those systems have to assume that anything pulled from the open internet could contain instructions intended to mislead the AI — and put appropriate safeguards in place.

It’s still wise to avoid sharing unnecessary personal information with shopping assistants, particularly if the bot can access previous orders or other account details. Keeping retail apps updated can also ensure you receive security fixes when they become available.

And that also leaves one enormous unanswered question: Which shopping assistant was it?

For now, the researchers aren’t saying. But the demonstration shows what can happen as AI shopping assistants are given more control. If they can be tricked into following the wrong instructions, their most useful features can also become security risks.

With more than a decade of experience, Nelson covers Apple and Google and writes about iPhone and Android features, privacy and security settings, and more.

See full bio

Advertisement

Companies are still grappling with exactly how software development should work in the AI area, but one early answer is the so-called software factory. Essentially an agent loop that’s built around the traditional stages of software development, the software factory approach has become a popular way for companies to remake their engineering organizations for the AI era.

Now, a system from Warp could make that transition a lot easier. On Tuesday, the AI coding company introduced Warp Factories, a new system designed to make building and operating AI software factories as easy as possible.

Operating as an infrastructure layer, Warp Factories gives companies a simple environment for deploying agents and a roadmap for how to use them.

To be clear, many companies are already having success with the factory model without any help from Warp. Stripe has been particularly public about its technical progress, developing a “minions” system to automate development within its own codebase. Ramp has made similar progress, developing a background agent that can monitor its own code after it is deployed.

As Warp CEO Zack Lloyd sees it, the target market for Warp Factories will be smaller companies without the resources to develop a system from the ground up.

“[If you look at] things like running your agents in the cloud and steering those agents as they run, or bringing the work that they’re doing into your local environment, or setting up memory that goes across those agents, or setting up evals that go across those agents — it’s actually a huge infrastructure undertaking to do this right,” Lloyd told TechCrunch.

In Warp Factories, the architecture is already built out of the box, with many of the most difficult decisions already made. Warp’s system is based on the standard phases of software development (triage, specification, implementation, review, and verification) but the agentic approach means any of those steps can be automated.

Users can choose their own coding model and harnesses as necessary; the system works as well with Codex as Claude Code. It also integrates with ticketing systems like Linear and Jira, and messaging systems like Slack and Teams, in an effort to plug in seamlessly to existing workflows.

Beyond just shipping code, Warp Factories will also give managers the tools to track how well the factory is performing. With all the agents running in the same environment, it’s easy to compare performance metrics for different configurations, and to keep an eye on the overall token spend. Warp Factory also allows for self-improvement loops to optimize the overall system, automating management of the process itself.

Even so, Warp Factories is not built to completely replace software engineers — just give them an easier way to collaborate with the new agentic workforce. In Lloyd’s own experience, there are still a lot of tasks that require a human at the wheel.

“We automate like 30% of our tasks, 30 to 35% on a weekly basis,” Lloyd told TechCrunch, “and as models improve, as the context improves, as the harness improves, I think that that number is going to go up over time.”