Snazzy Labs did an overview video [1] about this implementation. According to them, reusing a specific hardware token is such s common practice that Apple would need to "redesign their entire authentication and delivery strategy" to mitigate this problem.
I guess we'll see how this statement holds up in the coming weeks/months.
This didn’t really say much. Apple definitely knows about Hackintosh users, they mostly just don’t care. The question is whether they will actually do something if made to care.
They 'don't care' because they know that the M series processors were coming and now there is a built in death counter coming for Hackintoshes...the day they drop Intel support.
June 5, 2028: Intel hardware will reach "vintage" status after having been discontinued five years prior, ending most of Apple's service and parts support for Intel hardware.
June 5, 2030: Intel hardware will reach "obsolete" status after having been discontinued seven years prior, ending all of Apple's service and parts support for Intel hardware.
> They 'don't care' because they know that the M series processors were coming and now there is a built in death counter coming for Hackintoshes
No, they don't care because they don't think about it at all. Hackintosh's numbers never mattered, it's always been too onerous to maintain even when it was at its easiest.
This is too high profile. Apple is absolutely, 100% going to kill this and it’s gonna screw this over for those of us who leverage iMessage in Hackintosh environments.
We're talking about a company that changes CPU architectures for their ecosystem every few years, completely seamlessly. If redesigning their entire authentication and delivery strategy is what it will take to mitigate this problem, Apple will do it.
From Apple's perspective, yes. Social pressure to buy Apple devices to use Apple's messaging app is part of Apple's marketing strategy.
Apple also claims that blocking devices by serial number or similar unique hardware identifiers is a key part of its anti-spam strategy. If true, an end-run around that will likely create problems for users as well.
The creator of this is screwing things up for everyone. If it was an obscure, open source project Apple would probably let it slide and we’d be able to enjoy this indefinitely. This has been the case for Hackintosh stuff and the like.
But no, the author had to make a dumb, flashy looking website that looks like they’re advertising a product built around reverse engineered Apple tech. I bet they get a Cease and Desist by the end of the week and the hole is patched shortly after.
The current state of affairs re encryption is an accident of history that I would bet doesn’t last much longer once Apple gets formally involved.
“Apple says it won't be supporting any proprietary extensions that seek to add encryption on top of RCS and hopes, instead, to work with the GSM Association to add encryption to the standard.”
The KEP (Kubernetes Enhancement Proposal) is linked to in the PR [1]. From the summary:
> Sidecar containers are a new type of containers that start among the Init containers, run through the lifecycle of the Pod and don’t block pod termination. Kubelet makes a best effort to keep them alive and running while other containers are running.
One option is RapidAPI [1], where you can provide your API and monetize it. They charge a somewhat hefty fee of 20% though. I'm curious if there are other services like this.
That is not my experience at all. By following the `install`-instructions on http://1.1.1.1, all available DNS addresses are listed for both ipv4 and ipv6.
