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.
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…
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.
Apple should easily be able to tell when someone has done this.
Not too long ago, however, they moved to a completely randomized serial format, perhaps partly because of iMessages shenanigans.
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.
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.
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.
More proof that Remote Attestation is evil and does not exist to serve the user.
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.
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.
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).
They can; Apple (and others) have implemented Private Access Tokens (PATs) for this.
https://blog.cloudflare.com/eliminating-captchas-on-iphones-...
And no, web registrations as a must have is an extremely antiquated concept.
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.
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!
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.