[turquoisevar]

> Not commenting about the ethics of all this, just wondering why technically Apple can only block ~5% of Beeper Mini users instead of all of them? Could this potentially be tied to the use of an email id as the iMessage handle?

Apple could block 100% of the people using Beeper and throw Hackintosh users into that as a bonus as well.

The reason they’re not doing that is because it could have unintended consequences as some are using someone else’s actual device serial number and those people would be inconvenienced.

It’s nothing that can’t be easily solved, the moment they reach out to support either in person or via phone/chat Apple can immediately verify if they’re using a legitimate Apple device, but even if it boils down to a small percentage of users you still need to prepare for the influx of support requests.

To do this, Apple uses a scoring model to determine if they can access iMessage and historically they’ve been pretty generous by allowing clearly spoofed serials if the Apple ID involved is in good standing and has a positive history, think of it as a credit score. They can tweak the threshold score and probably are testing this out as we speak to find a sweet spot they’re content with.

Apple could also push out an update tomorrow that would end this once and for all by utilizing device attestation and leveraging Secure Enclave, but this would potentially lock out older devices, something they were willing to do when they upgraded the FaceTime protocol a couple of years ago, but they might not want to do that this time around.

[dylan604]

>Apple could also push out an update tomorrow that would end this once and for all by utilizing device attestation and leveraging Secure Enclave, but this would potentially lock out older devices, something they were willing to do when they upgraded the FaceTime protocol a couple of years ago, but they might not want to do that this time around.

Just give it a couple more hardware generations to ensure the largest % of older hardware upgrades. Anything pre-secure enclave chip would need to be in the low digits I'm guessing. Then again, if they are going to block Messages, that might be the incentive to get these older device users to upgrade.

[Sunspark]

Are you talking about the iOS 6 to 7 transition where the security certificates expired and Apple wouldn't issue a new one and said you needed to switch to iOS 7 if you wanted Facetime to work again? That was my last iOS device.

[dylan604]

I don't remember that as I just upgraded the OS. Why would an OS upgrade be some thing you wouldn't do? Seems to me like you have bigger personal issues than some technical one with this situation.

[Sunspark]

I just really liked the old skeuomorphic UI which dripped gorgeousness and didn't want to switch to a bland flat white interface.

[jwells89]

> The reason they’re not doing that is because it could have unintended consequences as some are using someone else’s actual device serial number and those people would be inconvenienced.

One is supposed to try to find a plausible (follows certain rules) but invalid serial to use for hackintoshing and not use real serials, but of course in practice there’s always some number of careless users…

[turquoisevar]

Yeah, that's what they're supposed to do, and to the credit of the Hackintosh community, that’s what most tutorials suggest.

But like you said, there are always people who don’t care about others as long as they have theirs.

There is, so far anyway, no reason to go against this best practice because, even though Apple can instantly detect a bogus serial, their currently used scoring threshold still allows you to use iMessage provided you’ve got a non-fresh Apple ID in good standing.

[rezonant]

This is interesting. How do you define "invalid" and why can Apple not also detect such invalidity?

There's been some talk that blocking this for Beeper will also block this for Hackintosh, but are we just talking about iMessage?

Because I have a hard time believing that (A) Apple can't just block this for iMessage without affecting whatever other system services rely on it and (B) That Apple would care if Hackintoshes lose iMessage.

If those two are true, and assuming Beeper Mini also tries to find plausible but invalid serials to use, then Hackintoshes definitely aren't the reason they aren't blocking based on this.

[jwells89]

My understanding is that the serials represent information, including model and date/location of manufacture. It’s therefore possible to create correctly formed but impossible serials, for example one that represents a pre-touchbar 2015 MBP manufactured in Ireland in 2018.

Apple should easily be able to tell when someone has done this.

[turquoisevar]

They indeed used to have data like that encoded in it.

Not too long ago, however, they moved to a completely randomized serial format, perhaps partly because of iMessages shenanigans.

[rezonant]

Hmm, how many bits of entropy are in one of these things? Can we calculate the likelihood of collision?

[nneonneo]

iMessage seems to use quite a lot of information from the hardware aside from the serial number. See https://github.com/JJTech0130/pypush/blob/main/emulated/data... for the data that is used to calculate the "validation blob" to activate iMessage. Several of the keys (not values!) are random-looking gibberish like "kbjfrfpoJU" and "oycqAZloTNDm", while others are normal things like "product-name" and "IOPlatformUUID".

[turquoisevar]

Those random looking keys are derived from the hardware and together with the values they serve as seeds for some of the keys.

Server-side there’s a bunch more information used from the Apple ID.

Together it results in a score and the server then decides if it meets the threshold before deciding to play nice.

[turquoisevar]

Apple can detect this, but they’ve allowed it in most cases when it’s done with an Apple ID in good standing and some history.

Why they allowed it is anyone’s guess, but the leading theory is that they valued not hindering established customers over locking iMessage completely down and perhaps the bad PR that comes with banning someone’s Apple ID over this.

[rezonant]

Well they could block the client itself, independent of blocking the Apple ID. It's the client that sends the serial information. Your Apple ID only gets associated with it indirectly.

[rezonant]

> The reason they’re not doing that is because it could have unintended consequences as some are using someone else’s actual device serial number and those people would be inconvenienced.

As far as I know, it's not actually known what model numbers, serial numbers, and disk UUIDs Beeper Mini is sending (and no the POC repository doesn't really tell us)-- if you have a source that talks about this I'd love to read it!

[_rs]

I’m pretty sure Apple could figure this out pretty easily by running it on an Android device themselves, considering they control the endpoints it talks to

[beeboobaa]

> Apple could also push out an update tomorrow that would end this once and for all by utilizing device attestation and leveraging Secure Enclave

More proof that Remote Attestation is evil and does not exist to serve the user.

[turquoisevar]

Like any tool, it can be used for good and for evil and the perspective of which is which depends on who you ask.

You can use device attestation to combat spam by making sure only authentic devices connect to your service.

You can use it to facilitate contact key verification together with a hardware key to ensure contacts know who they’re talking to.

I’ve used it to make sure that introductory promotions are only offered once per device.

On the other end of the spectrum you can use it as a DRM of sorts to make sure ads on your website aren’t blocked.

[mngdtt]

As a user, I am very well served by remote attestation when it is used to stop cheaters in videogames or spammers in messaging platforms.

[rezonant]

This assumes that all Beeper Mini users are spam, and that's a weird take.

More charitably, perhaps you are saying spam will increase over previous levels. From what I understand, Apple does not have any spam prevention technologies in Messages at all, neither for incoming iMessages, nor for SMS messages-- so the only thing keeping your iMessage conversations free of them is the obscurity of the protocol. Perhaps they should just add anti-spam tech like other texting clients have had for years.

[43920]

When you get an iMessage from a new contact, there's a "report junk" option; I'm assuming Apple does some kind of spam detection with that (ie if a particular Apple ID gets enough reports, it gets blocked). I've never seen any public documentation of it though.

[StressedDev]

The same technology Beeper Mini uses to get onto iCloud can also be used by spammers, crooks, etc. to get onto iCloud. You either get both or none. Frankly, as a paying Apple customer, I want them to close this because I hate SPAM. Also, the obsession of iMessage seems very strange to me.

[beeboobaa]

Nonsense. You still just receive SMS messages as normal, so any spam will be delivered to you regardless.

The solution to spam is to petition your government to crack down, or do server side filtering. Banning random phones is like playing whack a mole.

[SpaghettiCthulu]

You are incredibly selfish. Neither of those are more than a mild inconvenience. On the other hand, loss of personal freedom and privacy are major issues with real world consequences.

[beeboobaa]

Both of those are issues that can be solved server side if the company actually cared. They don't, and instead want to steal your freedom so they can push DRM.

[CaptainFever]

iMessage already has a spam problem, even with attestation.

[kmeisthax]

I know of no messaging platform using remote attestation for antispam - and, as far as those platforms continue to support web registration, they can't use remote attestation[0]. Even if they could, it wouldn't help. Remote attestation verifies that your client code is running without modification. What you care about with spam is keeping the spammers from registering large numbers of unrelated accounts, which doesn't require modifying the client at all.

I will give you that remote attestation does help anticheat. However, the current state of anticheat in games is so invasive now that you have to install special kernel drivers, and that kernel has to be on bare metal (no hypervisors allowed). This only happened because a specific genre of fast-twitch first person shooter has a lot of closet cheating going on. But it also gets blindly applied to things like rhythm games that absolutely do not need kernel-level anticheat[1]. So every game gets more invasive because of one hyper-competitive game genre triggering an anticheat arms race.

[0] Or at least, for as long as Web Environment Integrity stays dead

[1] Altering the client isn't even the most common way of cheating rhythm game records. For example, a good chunk of the rules for, say, Pump It Up's online leaderboards is "don't have other players play on your A.M.Pass" and "don't hook up a hand controller onto an online cab". Neither of which would be stopped by an anticheat system (and yes, PIU being an arcade rhythm game, there's shitton of encryption on it).

[JimDabell]

> as far as those platforms continue to support web registration, they can't use remote attestation

They can; Apple (and others) have implemented Private Access Tokens (PATs) for this.

https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

[kccqzy]

Remote attestation does more than ensuring code is not modified. It definitely can be used to prevent spammers from registering a large number of accounts.

And no, web registrations as a must have is an extremely antiquated concept.