Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple restricts Pebble from being awesome with iPhones

ericmigi.com

Post reply on HN
Print view View original

971–980 of 1001 posts

Re: Apple restricts Pebble from being awesome with iPhones

#971

Post by maccard »

liquid_thyme wrote: post #959
maccard wrote: post #908

Earlier quoted context omitted.

If you want an alternative, android exists. I actively want a tightly integrated system that I know works well together. I don’t want to worry “does this device really work with this other device, even if it says it’s compatible” which was a constant source of issues I had on Android. Your desire for Apple to become an open system removes my choice to opt into a closed ecosystem, when you already have an open ecosyst…

>I actively want a tightly integrated system that I know works well together. I don’t want to worry “does this device really work with this other device, even if it says it’s compatible” which was a constant source of issues I had on Android. Yeah, I mean Linux is an abject failure, nothing ever works or runs on it. Nobody needs open data formats or open protocols for interoperability. Binary blobs for the win! /s >Y…

I don’t think this comment is in good faith. I gave you a reasonable viewpoint and you just dunked on me with snark.

>, I mean Linux is an abject failure, nothing ever works or runs on it. Nobody needs open data formats or open protocols for interoperability. Binary blobs for the win! /s

I didn’t say anything of the sort. I said I actively choose a “more closed” ecosystem. Linux has similar problems IMO - “I want to buy a GPU” shouldn’t come with trying to figure out whether the device drivers will actually work, to me. If you want that, you have that choice.

> Don't worry, it's easy to lock down any open system and we can give you that should you desire it.

Only within the constraints of what you want which is that everything should adhere to a standard and be interoperable. Which, again, as I said you can have on android. Go buy a pixel phone, and a samsung watch and see how good the experience is.

I’ll say this again - there are open ecosystem alternatives for you out there, in android. Some people, even technical people, are ok with a smaller ecosystem knowing that there is lock in. If you don’t want that, don’t use it. But if you push your choices on me, you restrict my options and remove my preferred platform to have one more platform you want

Re: Apple restricts Pebble from being awesome with iPhones

#972

Post by saagarjha »

shuckles wrote: post #915
saagarjha wrote: post #884

Earlier quoted context omitted.

I would not be surprised if more people called every day about how their AirPods aren’t working as expected.

Not sure how it’s relevant that paying customers receive customer service.

My point is that it's probably a rounding error for them.

Re: Apple restricts Pebble from being awesome with iPhones

#973

Post by hackburg »

CivBase wrote: post #705
lynx97 wrote: post #430

Earlier quoted context omitted.

As a user, I am totally fine with Apple restricting access to iMessage. In fact, now that I read this, I want them to do this, thanks Apple.

It's absolutely wild seeing comments like this on a supposed hacker community.

[dead]

Re: Apple restricts Pebble from being awesome with iPhones

#974

Post by vessenes »

mistercheph wrote: post #943
vessenes wrote: post #913

Earlier quoted context omitted.

There are maybe three tech companies in the US that have large security groups dealing with persistent threat actors. Apple is one of them. Google is another. Even with that (large) Apple security group, iMessage is difficult to lock down properly, as you note. However, I think that the cost of 0 day subscriptions for iOS vs Android tell a pretty good story: iOS zero day subscriptions sold to intelligence agencies/go…

You are just wrong about 0-day values, e.g. exploit vendor crowdfense's publicly offered rewards for mobile 0-days: SMS/MMS Full Chain Zero Click: from 7 to 9 M USD Android Zero Click Full Chain: 5 M USD iOS Zero Click Full Chain: from 5 to 7 M USD iOS (RCE + SBX): 3,5 M USD Chrome (RCE + LPE): from 2 to 3 M USDD Safari (RCE + LPE): from 2,5 to 3,5 M USD And "large" tech companies despite having "large" security team…

I’m past the edit window unfortunately: you’re completely right as far as I can tell.

NSO leaked pricing has not historically differentiated Android or iPhone. I’m not sure where I heard those numbers, but thanks for the correction.

Tiny tiny nit - paying the same for an exploit doesn’t mean you’ll charge the same, but in this case it looks like the value and price structures are what you describe. Sorry!

Slightly less small nit - securing hardware, os and cloud inside some security perimeter model is a lot harder than securing, say, the bitcoin client. So point taken - and, it’s hard at scale, not easy.

Re: Apple restricts Pebble from being awesome with iPhones

#975

Post by dns_snek »

vessenes wrote: post #968
dns_snek wrote: post #921

Earlier quoted context omitted.

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 sp…

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…

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.

Re: Apple restricts Pebble from being awesome with iPhones

#976

Post by wizzwizz4 »

msh wrote: post #811
pyrale wrote: post #790

Earlier quoted context omitted.

Spammers sending spam through ble ?! They might just as well beat you up and take your wallet.

No, they would on their own phones automate sending spam to the iMessage network using ble at the interface.

They can already use USB rubber ducks to automate the iMessage user interface, even if they don't have a Mac.

Re: Apple restricts Pebble from being awesome with iPhones

#977

Post by dns_snek »

fiddlerwoaroof wrote: post #963
dns_snek wrote: post #316

Earlier quoted context omitted.

What are you proposing exactly? What can be simpler than a single Yes/No prompt?

I think I was pretty clear. You setup your pebble watch via openid connect/oauth like any other API client. No nag popups, manual Bluetooth pairing, etc.

That's way more steps, making it more annoying to set up, not less.

Re: Apple restricts Pebble from being awesome with iPhones

#978

Post by DirkH »

ryandrake wrote: post #924
threeseed wrote: post #287

Earlier quoted context omitted.

We have decades of experience that users will blindly click whatever prompts they need to make the app work.

You're getting dumped on here but you're absolutely right. Anyone who has been in software for any amount of time knows this, too. HN is full of software developers--downvoters should know better. You can put a button in your app that says "Tapping this will drain your bank account and give you cancer" but if it also enables functionality that the user wants, they will tap it.

Sounds like a "make better warning messages" issue.

Most users are not able to root their device due to the number of steps needed and will give up on an app that needs root access. Make it so that you have to do something other than just clicking a warning message to enable using your Pebble then.

Warning messages can be made idiot proof with some thought.

Re: Apple restricts Pebble from being awesome with iPhones

#979

Post by DirkH »

vessenes wrote: post #653
stemlord wrote: post #204

Earlier quoted context omitted.

And I'll be the contra to your take: the iMessage ecosystem is so closed that everyone without iphones can barely even interact via sms with iphone users. This is overall such a huge problem that it makes the closed ecosystem security solution not a practical solution

Nope, SMS works. Just fine. Apple rightly warns you that you are in a lower security environment by adding a bit of visual friction. This is true EVEN IF you are using RCS, because European laws require termination and inspection when RCS messages “interoperate” and are sent to other providers.

This is something I agree with. The world would be more secure if we made SMS obsolete and Apple making a push away from it is arguably net positive.

Re: Apple restricts Pebble from being awesome with iPhones

#980

Post by modeless »

dwaite wrote: post #970
modeless wrote: post #270

Earlier quoted context omitted.

Apple makes a mockery of their own "security promises" for iMessage by not end-to-end encrypting iMessages in iCloud by default. Ridiculous to use that as a justification to prevent users from choosing to send their messages to watches that happen to be made by someone other than Apple.

I don't understand, there is no option for iMessages to not be end to end encrypted. Are you speaking to the security of the recipient's backups?

If the sender or recipient has iCloud backup enabled then by default (i.e. without ADP) Apple can read the entire iMessage conversation. And they routinely do, at the request of law enforcement. Since Apple does not allow default-secure alternative cloud backup solutions to exist, it is almost certain that a large majority of iMessage conversations are compromised in this way (with no notification to sender or recipient).

Apple deliberately makes this non-obvious, but it is disclosed here: https://support.apple.com/en-us/102651

> Messages in iCloud is end-to-end encrypted when iCloud Backup is disabled. When iCloud Backup is enabled, your backup includes a copy of the Messages in iCloud encryption key to help you recover your data. If you turn off iCloud Backup, a new key is generated on your device to protect future Messages in iCloud. This key is end-to-end encrypted between your devices and isnʼt stored by Apple

And is the backup end-to-end encrypted? No, not by default, as disclosed on the same page. It is encrypted "In transit & on server" with keys stored by Apple, which means Apple can decrypt it. And they do, as mentioned earlier, for purposes other than "to help you recover your data". The non-default Advanced Data Protection feature is required to get end-to-end encryption of the backup.

Note that Google's equivalent Android backup feature has been end-to-end encrypted by default for many, many years. Plus, alternative backup solutions are allowed to exist on Android.

Post reply on HN