[Someone1234]

To me the key question is: Why is iMessage not a normal iOS app?

We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailbreak), soft bricking (endless restarts due to corrupt notifications/requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation/code execution.

None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they're context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic.

But they've designed iMessage to act like a part of the underlying OS for no real reason. You could very easily hand off the most hazardous parts of iMessage's inner workings into the app's context, or even another user space/context confined service, and just let them crash like normal apps do.

Ten years ago it was common for font processing to happen in the kernel. This was problematic because front processing is hard, and bugs occur. Since then we've seen many migrate fonts into userland. Why is iMessage's security model so far behind the times, it is a lot less critical/performance impacted than fonts, but yet has worse security than most font systems in 2019?

[csande17]

I suspect it's because historically, iOS didn't have a way to embed views from one app into another app. When Apple wanted to let you view iMessages from the lock screen, or expose iMessage via Share buttons in third-party apps, they accomplished that by shoving most of iMessage into the operating system itself.

These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.

[ksahin]

> These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.

You made my day thanks !

[saagarjha]

FWIW, the iMessage shortlook on the lock screen and share sheet are both run out-of-process and embedded in their hosting applications as remote views. I believe the latter has actually been separate all the way back to iOS 6.

[devin]

>small indie company that does not have the resources.

Can we be friends? This is incredible.

[ludamad]

"small indie company" is a frequent meme by disgruntled gamers

[zapzupnz]

Especially fans of Pokémon who aren't fans of Game Freak, lately.

[heed]

Honestly it would probably be easier to do a refactor like this if they were a small company. There are a lot barriers and things move slowly at large companies.

[notyourwork]

Yes a few product managers debating adding new whimsical features.

[WrtCdEvrydy]

The hardest part of refactoring is selling people on the upsides of creating something that does the same thing the previous thing did...

[zuppy]

it actually will do less, though, as it will most probably introduce new bugs

[saagarjha]

iMessage is a normal iOS app, at least mostly. It has access to a couple of entitlements that normal apps don't get, since it needs to do things like access Apple Pay and launch iMessage apps, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where iMessage's (buggy) frameworks are being loaded into the SpringBoard process (which is essentially the UI shell for iOS) and this is what is crashing, causing the phone to be unusable. So the solution here would be to stop allowing for message parsing to happen in contexts like these. (Also, as far as I am aware, there have not been any jailbreaks in iMessage that rely on the app being special in any particular way because it's really not.)

[JBiserkov]

Internet Explorer is a normal Windows application, at least mostly. It has access to a couple of entitlements that normal applications don't get, since it needs to do things like access MSN Passport and launch ActiveX components, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where Internet Explorer's (buggy) frameworks are being loaded into the Explorer.exe process (which is essentially the UI shell for Windows) and this is what is crashing, causing the computer to be unusable.

2002 called.

[saagarjha]

The difference being that with iMessage people can trigger the bug remotely and there's little you can do about it except turn it off completely (as someone I know did end up doing). Hey, I didn't say that what they were doing was a good idea :)

[sambe]

Internet Explorer bugs could not be triggered remotely?

[noisem4ker]

You can't send messages to Internet Explorer. You can just hope the user will fall into your trap website.

[tialaramex]

Right. For example, no huge global companies run services where you pay them money and they paste your arbitrary content into other web sites...

No wait, I was describing a sane world, but this is a world where we decided to fund everything with advertising ("This drug rehabilitation clinic sponsored by OxyContin") and so actually you can do exactly that.

[rasz]

Sure you could, guess what Outlook 2000-2003 used for email internally.

[airstrike]

Damn.... between this reply and csande17's[1], this thread is pure gold. I hope iOS folks are reading this

https://news.ycombinator.com/item?id=20773002

[tinus_hn]

What entitlements does Internet Explorer have? On Windows any app can do anything.

[eridius]

Ultimately I think the question is "why does iMessages have special integration in SpringBoard"? Because that's the cause of most of this. Messages doesn't have to be a "normal iOS app", it just has to be reasonably sandboxed. Running code using adversarial input inside SpringBoard is a serious problem.

[derefr]

A key thing to know is that SMSes do other things than just hand text to a program to display it. There is, for example, Flash (Class 0) SMS, which has the semantics that it both:

1. must display over whatever the user is doing (sort of like a Windows elevation prompt) and

2. must not be handed to userland in a way that it could be automatically recorded or persisted, other than by the user's explicit action.

Giving SpringBoard the ability to render SMSes is really the only way to implement Flash SMS in a way that adheres to its semantics.

There are other types of SMSes as well—WAP Push messages, for example, or WMI (voicemail indicator) Activation messages. Heck, your carrier can even use SMSes to directly write data to your SIM card. These aren't so clearly a layering violation as Flash SMS, as they are just pure OS-layer concerns; but if you're already implementing a kernel library for "SMSes triggering OS-level functionality" for Flash SMS and the like, you may as well put the code to handle these cases in there as well.

[akersten]

> Flash (Class 0) [that] display over whatever the user is doing [and] must not be able to be automatically recorded

I don't think I've ever received such a message, and I'm surprised Apple bothers to support such a thing. What in the world is the use case? That sounds extremely user-hostile, and if it were me I would throw it out. Especially once I realized my app needed special security just to handle this bonkers SMS type.

[derefr]

If you think that's user-hostile, there are also "Silent" (Type0) SMS messages—messages that don't trigger any event on the phone, but do return an ACK to the carrier with IMSI metadata attached (as all SMS messages do upon receipt, so that the carrier can de-queue them.)

This message type literally has only one use on modern phones: to allow police to trace your location.

But boy, imagine the argument that'd get started if Apple decided to let you turn acknowledgements for SMS-Type0 off... (really, I imagine police would just lean on carriers to refuse to activate devices that have this capability, citing "network incompatibility.")

[akersten]

I would love to see that standoff happen - both from a consumer privacy perspective and to put carriers in their place. It would be interesting to find out if the carriers think that Apple needs them more, or if they need Apple more (I strongly suspect it's the latter).

[lotsofpulp]

If all 4 carriers in the US have the same stance, then Apple would need them more. And I suspect they would if the government leaned on the carriers.

[Nextgrid]

Isn’t that info leaked anyway as part of transmitting data packets, given iOS maintains persistent connections to Apple anyway so it would cause keep-alives to be sent regularly?

[derefr]

Only if you have data as part of your phone plan! Many people don’t. Especially people who are just using a burner phone/SIM.

[kccqzy]

Then you should be grateful that your carrier doesn't impose this kind of thing on you. There are parts of the world where carriers are known to use this kind of features for their own transactional messages. A prepaid Singtel card for example, displays your remaining balance in such a way.

[airstrike]

> I don't think I've ever received such a message, and I'm surprised Apple bothers to support such a thing.

I'm just a layman guessing, but I'm thinking Amber alerts and Flash Flood warnings... or the Hawaiian nuclear strike

[morpheuskafka]

I thought the Wireless Emergency Alerts protocol was completely separate from SMS though, since it is based solely on geographic location of the cell tower and not your phone number.

[jsjohnst]

> I thought the Wireless Emergency Alerts protocol was completely separate from SMS though

They are entirely separate from SMS, you are correct. WEA messages are sent inside System Information Blocks (SIB12 specifically). Other SIB blocks are how your phone learns of authorization to use the tower, what frequency channels to use, neighbors of the tower, and other control related info.

[akersten]

At least on Andriod, I've got an "Emergency Alerts History" where I can view those. Does that count as being saved automatically?

[saagarjha]

I was traveling in India and got one after every call I made to tell me how much I had spent.

[akersten]

Why can't that just be a "normal" or whatever SMS from the carrier? I've got a contact named "Sprint" in my phone with their automated stuff, I assume those are not Flash type messages. I actually turn notifications off for that contact because I don't care to see them.

[derefr]

Probably legacy reasons. Flash SMS was designed in a world where phones had teeny-tiny amounts of storage. So there were regular SMSes—that were only supposed to be ACKed once they were persisted to disk (or to the SIM card!); and then there were flash messages, for realtime, ephemeral, if-you-miss-it-it-doesn't-matter messages. Sort of the textual equivalent of RTP packets.

[morpheuskafka]

It probably made more sense in the days when carriers closely controlled the phone's UI and there weren't other apps that could be interrupted by such a popup.

[yoz-y]

Since many banks use phones as a second factor these had an advantage at some point. For example they did not show up on other devices where you have SMS integration (such as your laptop). Also since you seen them immediately it was faster to re-type the code, they also did not pollute message history.

At some point my bank stopped sending these (I don't know why) and it was worse for a while.

Now, with the automatic code extractions into clipboard things are again as they should be because I don't need to care about this at all anymore (90% of the time, as most clipboard features in iOS/macOS this one is flaky too)

[jfim]

> What in the world is the use case?

Alerting. The system used for amber alerts and similar is US-specific, while the SMS stack works worldwide on every carrier and mobile phone.

[wbl]

Nuclear war notification.

[morpheuskafka]

Are there any screenshots/user documentation actually demonstrating what this looks like on iOS (or Android, for that matter)?

I'm not surprised there are some many obscure features in the spec, but I am surprised they are actually implemented/used these days.

[saagarjha]

Here's what it looks like: https://www.google.com/search?tbm=isch&q=ios%20sms%20flash&t...

[eridius]

Ok, but that just means SpringBoard (or some other system component) has to parse SMS messages. It doesn't mean SpringBoard has to be involved in the display of texts, and it also doesn't mean it has to be involved in iMessages. The moment SpringBoard determines that an SMS doesn't fall into the class of things that must be handled by the OS, it should stop and hand it over to the Messages app to do the rest of the parsing.

[eridius]

Can someone please explain why this comment is getting downvoted? It seems like common sense.

[saagarjha]

Or spawn an XPC service.

[tinus_hn]

It’s bullshit. Springboard has a facility to show notification bubbles showing Unicode text. There have been a lot of issues in Apples libraries where it turns out that if you render certain strings, the process crashes or hangs. If such a string is in a notification bubble Springboard crashes or hangs. If Springboard hangs or crashes repeatedly you have a problem. That’s bad but has nothing to do with iMessage or SMS, that’s just used to pop up a notification with invalid text.

[eridius]

Is it Springboard that actually renders that notification, though? Seems like it should maybe be a separate process. Even if it is Springboard, rendering a notification that crashes the process shouldn't brick your phone, because it shouldn't re-render once Springboard relaunches.

[colejohnson66]

Maybe because they want to integrate it with the Messages app so it’s used without having to worry about it? Could they still keep it integrated and put it in userland?

[lowdose]

You are spot on "practice what you preach".