Hacker News Reader

Comment by hedgehog | Hacker News Reader

Apple maintains iMessage compatibility with devices that are long out of support, if Beeper Mini is sufficiently similar to the client in for example iOS 12 then it makes an Apple decision to break Beeper fairly expensive. Even if they do the work to publish iMessage updates for the old iOS versions it just buys a little time before the new version gets reverse engineered, and that at the cost of poor user experience for the people with those devices in a form they will directly blame on Apple. Given all that I suspect he's right.

View on HN

> Even if they do the work to publish iMessage updates for the old iOS versions it just buys a little time before the new version gets reverse engineered

There's probably a cliff in complexity. Once Apple starts requesting signed attestations from the secure enclave on the devices that have one, it's game over.

They probably don't just yet, since still too many people use iMessage on first-party clients that don't have one, e.g. Intel laptops without a T1 or T2.

If Apple does start enforcing signed attestations, they will say that it's to reduce abuse. I have no doubt (being in the anti-abuse world) that spammers and phishing gangs will immediately begin using Beeper to spam iMessage users because this allows them to avoid buying an iOS device. With end-to-end encryption, Apple may also decide to roll out privacy-protecting client-side spam and phishing detection, which would IMHO be a really great thing.

Maybe Apple needs an even blue-r bubble to set apart the super attested users from the mere blue bubble peasants

they could call it "apple blue" and charge a few bucks a month for it. People love that stuff

They can desaturate the iPhone / MacBook Air users to disambiguate from the MacBook pro / iPhone pro / max users. Also device age in years will add hints of green hue. That way people know they're talking to someone who can afford to spend thousands of dollars on hardware every year.

wait is this where "green with envy" will come from?????

I’d pay for a blue Apple checkmark!

I imagine the next color being purple since that's a sign of royalty. Hail to the king baby!

The phone number registration https://blog.beeper.com/i/139416474/sending-and-receiving-me... will make it possible to enforce legal action against malicious and spammy messages.

Note that iPhones already receive SMS spam and fraud just like every other phone.

However, you are correct that the blue bubble is no longer a guarantee that the bad actor is using an iPhone.

> The phone number registration https://blog.beeper.com/i/139416474/sending-and-receiving-me... will make it possible to enforce legal action against malicious and spammy messages

Like the legal action that is currently protecting us from robocalls?

I don’t know if iMessage registration requires bidirectional SMS verification, though. If it does, that would be significantly harder to spoof than just caller IDs.

They do receive spam and fraud, but the numbers are orders of magnitude less than every one’s else BECAUSE it’s tied to hardware. I don’t know the details of how’s these guys got around it, but this is bad for the rest of us when phishing skyrockets.

I don't understand what you're talking about. I get far more SMS spam on iOS than I did on Android.

Whether the number uses iMessage or not is totally irrelevant.

How can you get more SMS spam on one platform than another? With SMS they're just blindly sending to your phone number, your SIM could be in any device. They don't know what platform you're receiving it on.

Android is much better at blocking it.

There were also differences in the platforms with how/when your phone number can leak to spammers and data aggregators, although I'm no longer deep enough into mobile OS or related CVEs to know current details.

> With end-to-end encryption, Apple may also decide to roll out privacy-protecting client-side spam and phishing detection, which would IMHO be a really great thing.

Spam protection should be on the recipient, rather than the sender.

That's a brief statement which makes me think I'm missing something obvious, but it doesn't seem obvious to me. Would you please expand on that?

I think it's a bad idea to lock out unattested clients, and as long as third-party clients are accepted, spam will always be sendable. If you're not doing end-to-end encryption, you can catch it at send time by having the server reject the client for sending spam. If you're doing end-to-end encryption, the only options are the sender or the recipient, and attempting to block it at the sender would require prohibiting interoperability.

While I love the principle of accepting third-party clients, Apple clearly doesn't which make this argument fairly non-compelling for them.

As we’ve learned very clearly over the last 20 years of commercialization of spam, that never works. The only tractable way to fight fraud and abuse is to impose cost.

The massive prevalence of physical junk mail would refute your argument that even a significant per message cost would dissuade abuse.

Scope and scale is important here, the amount of junk mail from business interests outside of my immediate region is not very high. If physical mail were free and you could send it from anywhere in the world, junk mail would be so much worse than it is. You couldn't run a lot of internet scams at the costs of physical mail and be profitable.

Probably not because even if the postage is free the paper, printing, envelopes, etc. are not.

How many pieces of physical junk mail do you get per day? Now how many spam emails do you get per day? Include the stuff that lands in your spam folder, because we're talking about cost to send junk mail here.

I'm willing to bet the latter is much, much higher. It certainly is for me.

I disagree. Email has SPF and DKIM an what have you exactly because client side filtering doesn't work right. Mail gets dropped beforr the clients even get a chance to run filters.

That's not to say that requiring remote attestation or blocking third party clients entirely is proportional, but Apple should (and does) play a role in spam prevention.

SPF and DKIM are ways of signing a message, but it's still typically up to the recipient or the recipient's mail server to decide what to do with that signature. And they're only checkable on the recipient's mail server because email isn't properly end-to-end encrypted, and exposes metadata.

SPF and DKIM can be checked client side no problem, assuming your mail server doesn't mangle the received-from headers. We just generally only use them as server-side filtering.

Apple can break Beeper without relying on the secure enclave: If Apple devices just send their serial number (IMEI for their GSM products), their servers can refuse to talk to hardware they didn't manufacture.

How does this address iMessages sent from non-iPhone devices?

If in the data sent across (via Apple servers) the IMEI and serial no of the device are also transmitted, then Apple can in that millisecond query on their various lists/inventories that this device is legit (activated device + IMEI + serial) and if all lights are green, proceed to deliver, otherwise drop it.

(perhaps different sets of data can be used, but it must be something that Apple already has, and the user has already provided (i.e. the iMessage email or the iMessage phone number, from the iPhone's enabled Settings)

you already have to do this to get certain apple services (including imessage) working on hackintoshes. turns out there's a really easy work-around: guess-and-check serial numbers on apple's web site until one works. they rate limit it a bit but you can usually find a working one without a terrible amount of hassle.

As someone who once bought fake airpods on ebay, I can tell you that Apple can't do this.

I spent a number of days with them where they were trying to work out if they were fake. The serial number was real but they were fairly sure the number had been taken from a real product and reused, but were unable to say for sure.

I ended up just returning them (because of the ebay return window) but found it interesting that Apple couldn't easily check this, and was very aware of the issue.

Do you mean that I now have a nice party trick - DoSing friends iPhone from sending iMessage? :)

If you have a FlipperZero, DoSing iPhone users with Bluetooth is a bit of fun!

Non-Apple devices could just lie

Beeper will know only a small number of valid serial numbers

If it ever becomes popular, there will be a lot of duplicate serial numbers. That's easy to detect and ban.

Not if they require a certificate containing the serial number/imei/... + a nonce provided by Apple, signed with a private key/certificate stored in the secured enclave, loaded into the device when it's manufactured.

The GP comment was:

> Apple can break Beeper without relying on the secure enclave: If Apple devices just send their serial number

You have come full circle with the comment 4 posts up.

I believe you can bruteforce/generate IMEIs somewhat easily. https://github.com/bstein/py-imei-generator

There’s also the registration process that could be locked down and/or hardened. There may or may not be additional metadata (including out of band) that could identify first-party clients.

I would think that’s the biggest issue right now. If spammers can register “real” iMessage accounts at scale without Apple hardware, Messages becomes less pleasant, very quickly.

Looks like Apple figured out a way to identify Beeper clients: https://techcrunch.com/2023/12/08/apple-cuts-off-beeper-mini...

Reply on news.ycombinator.com