Many comments deep now but I think my original point was that this would change the security boundary, which I still believe, and that changing the security boundary is net negative for Apple users which I also still believe.
You’re saying there a logical gap between opening up a radio based endpoint on an iPhone and allowing more spam in the system, or at least there’s no reason to think that it would be a different order of magnitude than blue bubbles.
I want badly to agree with you, at least enough to stop bike shedding about it. So let me try: Some possible implementations of opening up sms probably don’t add easier volume and programmatic sms options for developers. If you’re happy with that then we’re in agreement.
I think the main ‘easiest path’ implementation would increase spam though - turning on an iOS app’s ability to directly programmatically interact with messages on device and send and receive them over a radio would allow for simpler automates message parsing, creation and distribution; Apple is clearly not interested in this being a feature available to App Store developers. And Apple would then be in the position of having to do some sort of bound to fail static analysis to prove the messages aren’t being sent out to an IP endpoint at some point, or including requests from some endpoint. And this is both because of the extension of the hardware security circle and because of the necessary feature of having a human out of the loop in iMessage actions.
I propose that this would increase spam on iMessage in that case. It would allow an app maker to use sms without human in the loop, essentially, extending notification to sms without humans opting in.
Either way I think that’s probably what I need as imagining, admittedly a bit vaguely in my initial reference. Appreciate the back and forth.
You’re saying there a logical gap between opening up a radio based endpoint on an iPhone and allowing more spam in the system, or at least there’s no reason to think that it would be a different order of magnitude than blue bubbles.
I want badly to agree with you, at least enough to stop bike shedding about it. So let me try: Some possible implementations of opening up sms probably don’t add easier volume and programmatic sms options for developers. If you’re happy with that then we’re in agreement.
I think the main ‘easiest path’ implementation would increase spam though - turning on an iOS app’s ability to directly programmatically interact with messages on device and send and receive them over a radio would allow for simpler automates message parsing, creation and distribution; Apple is clearly not interested in this being a feature available to App Store developers. And Apple would then be in the position of having to do some sort of bound to fail static analysis to prove the messages aren’t being sent out to an IP endpoint at some point, or including requests from some endpoint. And this is both because of the extension of the hardware security circle and because of the necessary feature of having a human out of the loop in iMessage actions.
I propose that this would increase spam on iMessage in that case. It would allow an app maker to use sms without human in the loop, essentially, extending notification to sms without humans opting in.
Either way I think that’s probably what I need as imagining, admittedly a bit vaguely in my initial reference. Appreciate the back and forth.