

Why the iPhone's Messages App Refuses Audio Messages That Mention 'Dave & Buster's' (rambo.codes) 94
Earlier this month app developer Guilherme Rambo had a warning for iPhone users:
If you try to send an audio message using the Messages app to someone who's also using the Messages app, and that message happens to include the name "Dave and Buster's", the message will never be received.
In case you're wondering, "Dave and Buster's" is the name of a sports bar and restaurant in the United States... [T]he recipient will only see the "dot dot dot" animation for several seconds, and it will then eventually disappear. They will never get the audio message.
"The issue was first spotted on the podcast Search Engine..." according to an article in Fortune: Rambo's explanation of the curiosity goes like this.
"When you send an audio message using the Messages app, the message includes a transcription of the audio. If you happen to pronounce the name 'Dave and Buster's' as someone would normally pronounce it, almost like it's a single word, the transcription engine on iOS will recognize the brand name and correctly write it as 'Dave & Buster's' (with an ampersand)," he begins. So far, so good." [But ampersands have special meaning in HTML/XHTML...] And, as MacRumors puts it: "The parsing error triggers Apple's BlastDoor Messages feature that protects users from malicious messages that might rely on problematic parsing, so ultimately, the audio message fails to send."
To solve the mystery, Rambo "plugged the recipient device into my Mac and captured the logs right after the device received the problematic message." Their final thoughts... Since BlastDoor was designed to thwart hacking attempts, which frequently rely on faulty data parsing, it immediately stops what it's doing and just fails. That's what causes the message to get stuck in the "dot dot dot" state, which eventually times out, and the message just disappears. On the surface, this does sound like it could be used to "hack" someone's iPhone via a bad audio message transcription, but in reality what this bug demonstrates is that Apple's BlastDoor mechanism is working as designed.
Many bad parsers would probably accept the incorrectly-formatted XHTML, but that sort of leniency when parsing data formats is often what ends up causing security issues. By being pedantic about the formatting, BlastDoor is protecting the recipient from an exploit that would abuse that type of issue.
In case you're wondering, "Dave and Buster's" is the name of a sports bar and restaurant in the United States... [T]he recipient will only see the "dot dot dot" animation for several seconds, and it will then eventually disappear. They will never get the audio message.
"The issue was first spotted on the podcast Search Engine..." according to an article in Fortune: Rambo's explanation of the curiosity goes like this.
"When you send an audio message using the Messages app, the message includes a transcription of the audio. If you happen to pronounce the name 'Dave and Buster's' as someone would normally pronounce it, almost like it's a single word, the transcription engine on iOS will recognize the brand name and correctly write it as 'Dave & Buster's' (with an ampersand)," he begins. So far, so good." [But ampersands have special meaning in HTML/XHTML...] And, as MacRumors puts it: "The parsing error triggers Apple's BlastDoor Messages feature that protects users from malicious messages that might rely on problematic parsing, so ultimately, the audio message fails to send."
To solve the mystery, Rambo "plugged the recipient device into my Mac and captured the logs right after the device received the problematic message." Their final thoughts... Since BlastDoor was designed to thwart hacking attempts, which frequently rely on faulty data parsing, it immediately stops what it's doing and just fails. That's what causes the message to get stuck in the "dot dot dot" state, which eventually times out, and the message just disappears. On the surface, this does sound like it could be used to "hack" someone's iPhone via a bad audio message transcription, but in reality what this bug demonstrates is that Apple's BlastDoor mechanism is working as designed.
Many bad parsers would probably accept the incorrectly-formatted XHTML, but that sort of leniency when parsing data formats is often what ends up causing security issues. By being pedantic about the formatting, BlastDoor is protecting the recipient from an exploit that would abuse that type of issue.
For all the people (Score:1)
Re: (Score:2)
that say only the government can censor....
...best look somewhere else, since the summary makes clear that this is not that.
Re: (Score:2)
that say only the government can censor....
...best look somewhere else, since the summary makes clear that this is not that.
Which was supposed to be the point of the FP and which you seem to be deliberately interpreting in the worst possible way? Pretty sure he was going for "funny", but you don't see much of that on Slashdot these days. That's been a long slide downhill. Slashdot seems to be down to its last surviving editor now? (And I don't see how a unified editorial viewpoint is going to make anything better... Different form of censorship? Albeit often unintentional even with the best intentions? (But I've noticed that th
Well, that's shit coding (Score:2)
Eol
Re:Well, that's shit coding (Score:5, Interesting)
XML is long past... (Score:2)
... its use by date. Json is superior in every measure (parsability, flexibility, human readability etc) and while XML was useful back in the 2000s for webdevs familiar with HTML who felt more comfortable with it, it's really time for it to head to the computer museum.
Re: XML is long past... (Score:2)
Except JSON doesn't have a schema.
(Yes, I know of JSON Schema, but it was built and designed after the fact, while XML schema is part of the standard.)
Besides, wrong syntax will fuck up every format - JSON too.
Re: (Score:2)
The fact that XML requires a schema shows how ancient it is. Json doesn't need a schema any more than javascript does. It has a fixed syntax which must be used appropriately.
XML and JSON schemas are for semantics (Score:3)
Both XML and JSON have a syntax, which describes what makes a document using those languages well-formed. However, not all well-formed markup is valid in a particular application. For example, you don't want "-567" or "butt" as the value of the "width" attribute in an "img" element in HTML. For this reason, applications of XML and applications of JSON have semantics, which further refine what is considered "valid" for that application. An XML or JSON schema can be used to quickly reject documents that are w
Re: XML and JSON schemas are for semantics (Score:2)
Like i said, not required. Any program parsing json is quite capable of validating ithe fields itself, a 2 step process is inefficient and unnecessary.
Re: (Score:2)
This might work if there is only a small handful of programs needing to interpret the data. If you want to interchange data such that multiple programs can read and write files, you start needing to be stricter. The file format needs to be well-defined for people to write programs to read and write it correctly. Schemas are useful there as they can communicate what data is expected to be in the file/data stream.
I would say it is inefficient to write the same code in multiple different programs. A schema all
Re: (Score:2)
That might have been a reasonable approach 20 years ago, but the proliferation of easy to use json libraries for python, c++ etc render it an utterly futile endeavour in 2025. Parsing field types is a trivial exercise a teenager could do.
Re: (Score:2)
You could say the same about binary files. They don't need a schema either. Just interpret the bytes correctly.
Re: (Score:2)
Since when did binary files have a schema? Wtf are you gibbering about? Different binaries have different formats which the appropriate program will know how to interpret.
Re: (Score:2)
Re: (Score:2)
JSON is still a plain text interface and all plain text interfaces will have injection exploits.
Escaping is an antipattern, humans will keep fucking it up.
Re: (Score:2)
JSON is still a plain text interface and all plain text interfaces will have injection exploits.
JSON is very simple. Not parsing it correctly into arrays, dictionaries, strings, numbers, true/false/null is absolutely inexcusable.
Re: (Score:2)
If you can't recognize the pattern that programmers screw up escaping and input sanitation at terrifying rates, you won't get it right for json either.
Re: (Score:2)
Or better, just take it behind the barn and do the right thing.
Re: (Score:2)
Must admit the root cause came surprising to me. I had expected that two pieces of software couldn't agree whether that name was _one_ name or _two_ names, and that caused
Re:Well, that's shit coding (Score:5, Informative)
Eh. it's a bug. overall it was an alright failure mode and i'm sure they'll fix it soon.
After all this time in tech i'm not going to get too high horse about it. I've had bugs get to production, so has NASA, "the military", "the banks", openSSH, Boeing, Airbus, everyone.
Fortunately we haven't had any nuclear accidents or grey goo cases, but even there it's increasingly about setting up defense in depth knowing that you can't count on any given thing (other than physics) to never fail.
Re: Well, that's shit coding (Score:2)
Re: (Score:2)
&
Re: (Score:2)
This is sanitised in multiple levels. Normal text messages won't trigger this bug because how they are formatted, and instead a backup system caught something that bypassed the sanitation check (the speech to text conversion).
Re: (Score:2)
The coders need to sanitize, not the typist. TTS shouldn't do it, as the user will be like "Dave && Busters? WTF, Apple shitheads?"
Re: (Score:2)
The coders need to sanitize, not the typist. TTS shouldn't do it, as the user will be like "Dave && Busters? WTF, Apple shitheads?"
Maybe they could also try, "Dave ampersand amp semicolon busters."
Re: (Score:1)
Government complicit in private censorship (Score:2)
Even if you define "censor" to refer only to public sector acts, the government can censor on behalf of a private person by enforcing exclusive rights asserted by said private person. In the case of iMessage and other closed platforms, the exclusive rights in question are often those granted under anti-circumvention statutes implementing the 1996 WIPO Copyright Treaty, such as 17 USC 1201 and foreign counterparts.
Working as designed? Lol (Score:5, Insightful)
People always seem to apologize for the deficiencies in Apple products. This case is no exception. Within the company, Apple takes a full-stack view and says components must work together to give a functional result. Outside the company, it's "you're holding your phone wrong" or "just don't send that restaurant name in a voice message".
Re: (Score:2)
It's a bug not a feature!
Re: (Score:2)
It's a bug not a feature!
Rejecting invalid html is an excellent feature. Producing invalid html is a bug. So someone wrote the bug, and someone else made sure that it had no security consequences.
Re:Working as designed? Lol (Score:5, Interesting)
Apple has a long history of failing to properly sanitize input. There was that bug that would crash Finder if you entered "file:///" or something similar. Multiple examples of SMS messages that could brick the phone. It's been going on for years, like the numerous times that alarms failed to go off.
Re: (Score:1)
Re: (Score:2)
Apple has so many old bugs like in macOS. They just don't care. Even when others and I reported the same bugs via its bug reporter. :(
Re: (Score:2)
This is one of the most ironic behaviors of Apple fans. Holding companies accountable is one of the best (and sometimes only) ways to ensure that they improve their products. Instead, Apple fans often make excuses for the company and thereby perpetuate their degraded experience. That was one of the most frustrating experiences back when I cared to use Apple products.
Re: Working as designed? Lol (Score:2)
Apple: Yhe only remaining company where text parsing bugs can still lead to rootkits.
Re: (Score:2)
You better check all applications which accept data from iMessage and see if these invalid messages are correctly rejected.
Re: Working as designed? Lol (Score:2)
It is a text parsing bug, plain and simple, unless you want to argue that an ampersand isn't valid text and should never be used in text messages, which is incredibly stupid if so. Only an idiot would call this a feature.
The whole reason they block that kind of thing to begin with is basically to work around the fact that the software that underlies apple products is dogshit. There are right ways and wrong ways to things. Blocking a commonly used symbol in everyday text because you're infamously bad at pars
It's not the only iMessage problem (Score:5, Interesting)
Earlier this evening my partner sent me a text over RCS asking if I knew of an iMessage outage. It seemed at some point earlier in the day he'd lost the ability to send (but could still receive) iMessages. After going through the usual troubleshooting steps, I asked him to try contacting Apple to see what they said. Turns out, he'd been blocked for spamming. They unblocked him as a "one time exception", which from what I've read on Reddit, is something Apple truly is not kidding about when it comes to the one time part.
Now, I know he doesn't send spam texts and this was utterly perplexing to me. Then he mentioned to me that when he gets texts from spammers, he sometimes likes to insult or argue with them out of boredom. My guess at that point was that these spammers were retaliating by reporting his replies, and that's what earned him a ban.
This strikes me as more than a little draconian from Apple. If you want to tell spammers to fuck off, you should be able to. Apple should have some means to determine who is a genuine user that has spent considerable money on products in their ecosystem, versus someone who is most likely churning out tons of junk messages from a copy of macOS running in a VM. The posts I've seen on Reddit of other users who have experienced the same issue are a real eye-opener. You can literally spend thousands on Apple equipment, then end up banned from iMessage through no fault of your own, and the only fix is getting your wireless carrier to change your phone number.
I'm genuinely shocked that an HTML parsing error is big news, but Apple's absolutely atrocious handling of false spam reports that can cause you to lose access to iMessage entirely, flies under the radar.
Re: It's not the only iMessage problem (Score:2)
There are associated risks when you've willingly locked yourself in someone else's walled garden, and even paid $$$$ for that luxury.
Re:It's not the only iMessage problem (Score:5, Insightful)
I'm genuinely shocked that an HTML parsing error is big news
This isn't the news. The news is that while a system was designed to successfully sanitise one input, a feature creates another input (a transcript text) that itself doesn't get properly sanitised and triggers a failsafe.
It's quite interesting from a technical perspective, and worthy reminder to programmers: you don't just need to santise your user's inputs, you also need to sanitise your own.
Re: (Score:3)
The bug here actually seems to be an output sanitization problem.
Actually I would call this TWO bugs. 1. Failure to encode the amphersand correctly.
And 2. Failure to respond to the error condition appropriately. Silently losing a voice message you thought you sent fucking sucks. The app should have some mechanism of explicitly notifying the sender of the fact that the Message failed to send; instead of allowing them to believe the message was sent normally.
Re: (Score:2)
Well both. A system should be designed to handle an input with grace. If that works on one input and not another then it is an input sanitisation problem. I can't really fault the output of the other system. It likely has nothing to do specifically with messaging and is very likely a system that isn't designed in any way to understand that the ampersand isn't valid. And why wouldn't it be, it is perfectly valid when typed on a keyboard.
I do agree though that silent fail isn't the correct error handling mech
Re: (Score:2)
Apple missing the irony. They could have reviewed the count of sent messages by the involved parties, but chose not to.
Re: (Score:2)
Apple. If you want to tell spammers to fuck off, you should be able to. Apple should have some means to determine who is a genuine user
I don't believe Apple ever said you could do that in their Terms of Service. Unwanted or Abusive messages can be taken and reported to Apple as harassment regardless of the context. Anything the sender knows is unwanted or anything that can be taken as deliberaetely wanting to annoy or harm the recipient is harassment.
In short. Just like on most social media websites the
Re: (Score:2)
Here's Apple's iMessage TOS [apple.com]
iMessages are only supposed to be reportable if they're spam or unsolicited, otherwise the option to report doesn't display. If another party contacts you first (in this case, the spammers), any responses are solicited by definition. The issue is that, as near as I can tell, Apple does this solicitedness test client-side, by checking if the sender is in your contacts. Obviously, spammers aren't using the contact list built into the OS.
Yes, I concur with you that the "fix" is to
We need a better Unicode (Score:1)
Re: (Score:3)
This bug has zero to do with Unicode. The issue seems to be that the software generating the "&" doesn't realise that its output is being parsed and that it should instead be generating "&". Notice that all of the characters involved here are plain, 7-bit ASCII. We know this is true because ... this is Slashdot and Unicode is impossible. The fact that the ampersand is special in this context is nothing to do with Unicode, in which it has the category "other punctuation".
Re: (Score:2)
To expand upon what jaa101 said...
The problem isn't the encoding of characters, it is the encoding of documents to be "human readable" (i.e. possible to open in a text editor without weird stuff showing up) and machine parseable at the same time. These two are conflicting goals and compromise must be made (& isn't really human readable unless you're trained in html).
Unicode has no formatting built-in (nor should it!), so people invent ways of encoding the formatting. People want "text" files with ri
Re: (Score:2)
Oops. Replying to myself before anyone corrects me. & is not an allowed XML character. (I should have double-checked that...). At any rate, I am not sure whether XML is involved in this bug in the first place.
Re: (Score:2)
Why did it encode to "Dave & Buster's" instead of "dave and busters" in the first place?
Re: (Score:2)
And why doesn't AT&.;T have the same issue?
Re: (Score:2)
Re: (Score:2)
YES. THIS. FFS they didn't say ampersand, it wasn't a hacking attempt, this is ALL a bug.
Lessons not learned... XSS auditor v.bis (Score:2)
These defensive naive schemes have a history of themselves being vehicles for exploitation. Reduced availability = security failure.
Why other phrases with an ampersand not trigger it (Score:1)
Why do other phrases with an ampersand not trigger this bug ??
Re: (Score:2)
Why do other phrases with an ampersand not trigger this bug ??
The exact phrase recognition probably bypasses the escaping/encoding logic and is put in the buffer verbatim. The resulting buffer is then invalid.
Re: (Score:2)
This has been a problem since the 70s (Score:2)
The worst example is ASN1. The legacy parsers are te
Re:This has been a problem since the 70s (Score:4, Informative)
ASN1 is the encoding method for X509 certificates.
No, it is not.
ASN1 is an interface/state machine definition language used to define message protocols.
It is a very high level programming language.
https://en.wikipedia.org/wiki/... [wikipedia.org]
It looks a bit like a mixture of Pascal with EBNF.
It usually gets compiled into C or C++
ASN1 is not a programming language (Score:2)
ASN1 is the encoding method for X509 certificates. No, it is not. It is a very high level programming language. https://en.wikipedia.org/wiki/... [wikipedia.org]
It looks a bit like a mixture of Pascal with EBNF.
It usually gets compiled into C or C++
Read the wiki you linked. It is a way to serialize data structures. It defines how the data is moved between machines and it is terrible for parsing. It is {type, length, value} triples on steroids where your values can be be a series of further {type, length, value} triples. Now think of how you would write a parser. You are going to recursively parse the triples. Now what happens when the outer length doesn't match the sum of the inner triples lengths? Depending on how you wrote your parser you wil
Re: (Score:2)
ASN.1
Is the definition language that defines how the data is parsed.
It has absolutely nothing to do how the data is parsed in the end by Java, Javascript, C, C#, C++ r what fucking ever.
I do not need to "read" my link. I was part of the team that wrote the first ASN.1 compiler in Germany.
{type, length, value} triples. Now think of how you would write a parser. You are going to recursively parse the triples. Now what happens when the outer length doesn't match the sum of the inner triples lengths? Depending
What is the point ... (Score:2)
What is the point in encoding a transcript into HTML?
I guess the ordinary text is already XML/HTML?
Or is this app a "single developer project" and HTML is the only thing he knows?
Re: (Score:2)
"Plain Text" on Slashdot is never plain text.
For example, URLs get converted to links.
My favorite is having to type < when giving examples of how to do HTML. You can type the >s normally ofc.
seriously? (Score:2)
[But ampersands have special meaning in HTML/XHTML...]
The 90s called, they want their parsing problems back, and they were incredily surprised that in 2025 we still haven't solved them.
(especially in HTML, where it's so trivial: & + known list of characters + ; - I mean, the moment you encounter a space you can stop parsing, for example.
Whelp (Score:2)
Guess people can't voice message about "M&M's" or "Mr. & Mrs. Smith" ... either. So dumb Apple.
A system eating its own tail (Score:3)
The article is technically detailed but misleading: it praises Apple’s BlastDoor for "working as designed," which is true, but misses the point. The real issue is that Apple’s own transcription system injects invalid XHTML into a security-critical pipeline. The ampersand isn’t escaped, breaking XML compliance, so BlastDoor (correctly) discards the message. This isn’t a security topic it’s Apple breaking its own rules, then silently failing. A system eating its own tail.
Re: (Score:2)
The real issue is that Apple’s own transcription system injects invalid XHTML into a security-critical pipeline.
I bet you the transcription system isn't injecting any XHTML at all, but rather its duty is to create raw text. That's the problem with relying on one system to do multiple things. It's a catch 22. Use one common system and it introduces bugs interacting with other systems. Use a bespoke system each time and there's a chance you introduce a new bug each time.
Nobody ever used Smith & Wesson? (Score:2)
Hardly believable.
God bless Apple fans (Score:3)
"... and so that's why the bug is actually a sign of how good Apple is."
Re: (Score:2)
Apple take care of us and keeps us safe by ... :checks notes: ... not escaping special characters in their commerce filter with in-band signaling.
Hey, kudos to the backend guy who yeets invalid messages, though.
Too bad the yeets don't file bugs when the client is identified as an Apple product. I have a feeling Woz would have wired up an old school firebell to alert on such cases.
wat (Score:2)
in reality what this bug demonstrates is that Apple's BlastDoor mechanism is working as designed.
It was designed to stop you from talking about a place where you can eat and play video games? Who asked for that?
Um, it's a bug (Score:2)
maybe if the D&B Rewards app gave apple 30% th (Score:2)
maybe if the D&B Rewards app gave apple 30% this can be fixed very fast!
Transcribed audio is searchable (Score:2)
Your private encrypted messages are being transcribed into text... automatically.
Then blocked.
No outrage ?
Censorship ? Anyone ?
When Apple does it, it's ok?
Re: (Score:2)
> Censorship ? Anyone ?
Censorship is typically when someone intentionally blocks access to certain content to prevent the reader from being informed, not when a program has a bug. And if you're complaining about voice transcription, no, voice transcription is great. I wish it was done locally on the phone for privacy reasons, but it's incredibly useful and is one of the reasons Google Voice is so popular.
Re: (Score:2)
How wrong am I though that your private and encrypted audio files are being transcribed into text?
So how private is that? Your audio is sent to Apple's mothership of a server where they transcribe your audio into text. Is that all done in an encrypted environment protected from Apple's probing eye? that's a side channel, you aren't paying attention to.
In my humble and informed opinion, the w
Posting on Slashdot about bad parsing. (Score:2)
but who (Score:2)
But who is responsible for an incorrectly generated html? Surely not Apple.
This is huge! (Score:2)
Not encoding data before sending it? Is this the 1990s?
This is how you get all kinds of problems.
Didn't they learn from Bobby Tables?
https://xkcd.com/327/ [xkcd.com]
absolutely worst programming ever. AI??? (Score:2)
The problem is they transcribe 'and' as '&' and then they reject it. The word "and" should never ever ever be transcribed as &. Not in a brand name, not ever.
THAT should be hard coded into every single transcription software.
I strongly suspect the transcription is being done by AI and the error catching is also being done by AI.
Human coded transcription software would know to do it the other way around - transcribe "&" as 'and". A human coded error catcher should replace all '&' with 'an
More of an arcade than a restaurant (Score:2)
Yeah, they have a restaurant, but like most arcades, you probably don't go there for the food.
Alternate Headline (Score:2)
Working as designed... (Score:1)
iMessage spoofs it's user agent (Score:2)