Hacker News Reader

Comment by eridius | Hacker News Reader

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.

View on HN

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.

> 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.

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.")

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).

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.

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?

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.

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.

> 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

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.

> 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.

Thanks!

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

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

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.

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.

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.

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)

> 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.

Nuclear war notification.

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.

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

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.

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

Or spawn an XPC service.

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.

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.

Reply on news.ycombinator.com