3 ms·

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 c

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.

vessenes 2y ago
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.
- dns_snek 2y ago
  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. [1] https://bluebubbles.app/ https://bluebubbles.app/ [2] https://documenter.getpostman.com/view/765844/UV5RnfwM#0d8e0e67-fa3b-4446-aa2c-062dca2ce4cd https://documenter.getpostman.com/view/765844/UV5RnfwM#0d8e0... [3] https://github.com/ZekeSnider/Jared/issues/65 https://github.com/ZekeSnider/Jared/issues/65
  - vessenes 2y ago
    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.
    - dns_snek 2y ago
      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.

vessenes 2y ago

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.

dns_snek 2y ago
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. [1] https://bluebubbles.app/ https://bluebubbles.app/ [2] https://documenter.getpostman.com/view/765844/UV5RnfwM#0d8e0e67-fa3b-4446-aa2c-062dca2ce4cd https://documenter.getpostman.com/view/765844/UV5RnfwM#0d8e0... [3] https://github.com/ZekeSnider/Jared/issues/65 https://github.com/ZekeSnider/Jared/issues/65
- vessenes 2y ago
  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.
  - dns_snek 2y ago
    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.