I'm not debating the amount of spam but rather GP's claim that iMessage is hard to automate.
I showed that iMessage is trivial to automate and since you both claim that the amount of spam on the platform is very low, we can conclude that ease of automation isn't an important factor when it comes to iMessage spam.
Unless someone decides to move the goalposts we should therefore be in full agreement that Pebble being allowed to integrate with iMessage wouldn't have any appreciable effect on the amount of spam in the network.
It is definitely harder to automate than SMS. Very large companies exist only to provide API-backed support for automated SMS.
In contrast you need to hook into Apple APIs / scripting / sqlite databases on trusted apple hardware in order to automate iMessage.
You imagine "Pebble" as one company and say "how hard can it be to turn this on?" As I said in the original comment, it's not that it's hard, it's that it can only be turned on for everyone and that will create a security issue that WILL have a substantial impact on the ecosystem. I didn't say, but believe it to be true that the alternative -- a vendor security assessment program covering software, hardware, architecture and cloud security is not worth Apple's time or money to do. I don't think they have any business reason to do so.
Can you stop moving the goalposts? There's a ready-to-go open source solution for MacOS [1] that exposes a REST API [2] for interacting with iMessage which allows automation and the sky hasn't fallen like you predicted it would. Professional spammers would no doubt be way ahead in capabilities.
Relying on clients to stop spam would break just about every security design principle so that could never be the primary spam filtering mechanism. Indeed, if you search Github, you'll find evidence of this [3].
Allowing a third party gadget to talk to an iPhone to send messages isn't going to open the floodgates to spam any more than they already are, for what I think are pretty obvious reasons. Anyone who could exploit those integrations can already exploit current APIs with exactly the same limitations.
> In contrast you need to hook into Apple APIs / scripting / sqlite databases on trusted apple hardware in order to automate iMessage.
And that wouldn't change, you would still need to pair a real iPhone to your fake "spammer edition" Pebble, and then your Apple ID and iPhone would quickly get banned. Presumably just like it does now if you abuse [1][2], otherwise that's just bad design.
It's frankly ridiculous that this is even being suggested on a "hacker" forum with nothing but wishy-washy qualifiers about how easy or "hard" it would be.
Bluebubbles requires running Mac hardware, or a Mac virtual machine, which if run on non-Apple hardware violates Apples ToS. You may not care about that but enterprises certainly do.
This is worlds away from twilio which will provide you with orders of magnitude more throughout and deliver it with SLAs.
And unless you imagine Apple will hardware certify pebbles, how does Apple determine the BLE endpoint is actually a Pebble? If you have a way to ensure that without a key registry and TEE controlled by Apple, congratulations — Turing award is incoming.
Upshot: You’re a hacker on a hacker forum - cool. Sending one to ten programmatic iMessages in a hack is easy for you. But you may not have all the experience necessary to opine on how that compares to accessing an enterprise grade hyperscale sms messaging solution: building those is challenging, the companies that do a good job are worth billions of dollars and they exist solely to allow bulk SMS. To think blue bubbles somehow dunks on the idea that these economies of scale don’t matter isn’t correct in my opinion.
We're not discussing whether spamming SMS is easier - of course it is and I don't know why you keep returning to this relative comparison.
We're discussing whether authorizing third party smart watches to send messages via your iPhone would make it easy for spammers to send iMessage spam. Not just easy, but easier than it is right now using Bluebubbles' approach. Both require physical hardware, an Apple ID, and both are subject to the same server-side spam protection.
That's a very specific claim which you made and you haven't provided any supporting evidence for it, nor a coherent explanation.
> Sending one to ten programmatic iMessages in a hack is easy for you. But you may not have all the experience necessary to opine on how that compares to accessing an enterprise grade hyperscale sms messaging solution
I think if you dig deeper into this train of thought you'll get to the point that I'm making. Having relatively restricted API access to send a handful of iMessages from a 3rd party watch via your own physical iPhone will not enable mass-spam like you claimed it would.
Scaling an iMessage spam operation would be hard not because the client side is completely locked down (which it can never be, see the concept of "analog hole" [1]), but because server-side rate limits and user spam reports are the primary mechanism that keeps spam under control.
[1] This could be an ESP32 pretending to be a keyboard/mouse device that automatically navigates through iMessage UI on an iPhone to send messages just like a user would.
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.
I showed that iMessage is trivial to automate and since you both claim that the amount of spam on the platform is very low, we can conclude that ease of automation isn't an important factor when it comes to iMessage spam.
Unless someone decides to move the goalposts we should therefore be in full agreement that Pebble being allowed to integrate with iMessage wouldn't have any appreciable effect on the amount of spam in the network.