I was willing to believe that maybe it was just a massive NSA-scale research team up until the part with a custom hash function sbox. Apple appears to have known that the feature in question was dangerous and deliberately both hidden it, whatever it is, and then gone further and protected it with a sort of (fairly weak) digital signing feature.

As the blog post points out, there's no obvious way you could find the right magic knock to operate this feature short of doing a full silicon teardown and reverse engineering (impractical at these nodes). That leaves hacking the developers to steal their internal documentation.

The way it uses a long chain of high effort zero days only to launch an invisible Safari that then starts from scratch, loading a web page that uses a completely different chain of exploits to re-hack the device, also is indicative of a massive organization with truly abysmal levels of internal siloing.

Given that the researchers in question are Russians at Kaspersky, this pretty much has to be the work of the NSA or maybe GCHQ.

Edit: misc other interesting bits from the talk: the malware can enable ad tracking, and also can detect cloud iPhone service hosting that's often used by security researchers. The iOS/macOS malware platform seems to have been in development for over a decade and actually does ML on the device to do object recognition and OCR on photos on-device, to avoid uploading image bytes: they only upload ML generated labels. They truly went to a lot of effort, but all that was no match for a bunch of smart Russian students.

I'm not sure I agree with the speaker that security through obscurity doesn't work, however. This platform has been in the wild for ten years and nobody knows how long they've been exploiting this hidden hardware "feature". If the hardware feature was openly documented it'd have been found much, much sooner.

Well, the point of kerckhoff's principle is that it should have been openly documented and then anyone lookindg at the docs even pre-publication would have said "we can't ship it like that, that feature needs to go."

That's the problem with this sort of security through obscurity; it's only secure as long as the people who know about it can keep it secret.

So it either has to be stolen technical docs, or a feature that was put there specifically for their usage. The fact that the ranges didn't appear in the DeviceTree is indeed a bit suspicious, the fact that the description after being added is just 'DENY' is also suspicious. Why is it OK to describe every range except that one?

But the really suspicious thing is the hash. What kind of hardware interface does arbitrary DMA protected by a secret but weak hash function? Is there any legitimate usage for such a thing? I've never heard of such an interface before.

If it's a genuine backdoor and not a weird debugging feature then it should be rather difficult to add one that looks like this without other people in Apple realizing it's there. Chips are written in source code using version control, just like software. You'd have to have a way to modify the source without anyone noticing or sounding the alarm, or modifying it before synthesis is performed. That'd imply either a very deep penetration of Apple's internal network sufficient to inject backdoors into hardware, or they have one or more agents.

This really shows how dangerous it is to intel agencies when they decide to attack security professionals. Attacking Kaspersky has led directly to them burning numerous zero days including several that might have taken fairly extreme efforts to set up. It makes you wonder what is on these guy's iPhones that's considered so valuable. Presumably, they were after emails describing more zero days in other programs.

I agree. This appears to likely be an intentional backdoor injected at the hardware level during design. At such a low-level I think it could have been accomplished with only a handful of employees in on it. There would have been no need to subvert Apple from the top down with large numbers of people at many levels being privy.

In early silicon there can be a bunch of registers and functions implemented for testing which are later pulled out. Except maybe one set of registers doesn't get pulled but instead a door knock is added with a weak hash function, making the registers invisible to testers and fuzzing.

It seems a little too convenient that the door knock hash was weak. After all, strong hash functions aren't unknown or hard. The reason it had to be a weak hash function was to create "plausible deniability". If it was a strong hash then once any exploitation was discovered there would be no denying the vuln was intentionally placed. If it really was just a test DMA function that someone supposedly 'forgot' to remove before production silicon, I can't think of a reason to have it behind any kind of door knock in the first place.

I read that it was patched by adding these addresses to the "access denied" list. While I don't know anything about Apple security, I'm stunned that any such low-level access list isn't 'opt-in' instead of 'opt-out'. If it was 'opt-in' it seems like any such 'undocumented' register addresses would by denied by default. And if they were on the 'opt-in' list, yet remained undocumented, then it would be obvious to anyone looking at the security docs that something was amiss.

[1] https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

Their review processes are so incompetent even one of the most security critical components, root login, let a totally basic “fail your security 101 class” bug through. It is absolutely inexcusable to have a process that bad and is indicative of their overall approach. As they say, “one cockroach means an infestation”.

Just to list a few process failures off the top of my head.

No proofs of specification conformance. No specification conformance tests. No specification. No regression testing. No regression testing of common failure modes. No testing of common failure modes. No enhanced review for critical components. No design conforming to criticality requirements. No criticality requirements. No intention to establish criticality requirements.

In actual safety and security critical software development you do all of those except maybe the first. Doing none of them is rank incompetence and clear evidence you do not know the first thing about actual security that can protect against real professionals. And fancy that, Apple can not and never has against attackers with minimal resources like small teams with only a few million dollars.

We can talk about a reputation for “strong” security when they can protect against the standard, commonplace 10M dollar attacks we see every day.

Since then, though, they have cleaned up their act (I've never been a fan). As a silly example, I'm pretty sure they finally check into source control the configuration of their networking equipment... Plus do a lot more to counteract the sophistication of today's nation-state attacks. They've come a long way since the hacks of 2014, when they had to scramble to enable 2FA for iCloud — previously used only for account changes or purchases. As for this vulnerability, it might be a plain bug or some NSA-style backdoor with plausible deniability, but we probably won't know which for years.

But that said, overall I agree with Mike, in that Apple is clearly committed to security of their users. It's one of the main reasons I buy Apple hardware for my mobile, personal and work devices. Nobody is forcing them to put so much effort into that security, either - they do it largely by choice, and it distinguishes them from other vendors whose business models are inherently in conflict with their customers (I don't want to buy a phone from a company that derives most of its revenue from facilitating psychological warfare between advertisers and me.)

But I've always found this security to come with interesting tradeoffs. On the one hand, I'm pro-privacy and pro-user. But certain security objectives can't be achieved without reducing privacy or increasing restrictions on the user. Over the years I've come to appreciate this tradeoff, and I think Apple does a good job of balancing it. While I certainly don't feel like the device is "fully mine," I do feel like I'm getting some extra security in exchange for giving up some freedom to tinker.

[0] https://arstechnica.com/information-technology/2017/11/macos...

That'd probably depend on which team the dev worked in. If they were in the right team, then it might.

a) If a person is using those values daily for years (or even a couple of months), then it's very likely they'd have memorized them

b) Sometimes just knowing the concept exists for sure is good enough, as you can then go and brute force things until you've worked out the values

https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

Never attribute to malice that which can be attributed to incompetence. There are plenty of examples in the wild of going halfway with strong security, but halfway still leaves the barn door open.

That rule should only be applied in the normal world. The world of security where you know bad actors are out there trying to do stuff, it doesn't apply. And there are examples of spy types injecting plans to go halfway with security for their purposes - not that this proves the origin of a given plan, incompetence is still one possibility, it just returns to original point, that this stuff is mysterious.

I don’t really have any proof but considering the massive gain it shouldn’t surprise anyone. The agencies might not even need to pay large sum of $$$ if the said assets have vulnerabilities.

[1] https://social.treehouse.systems/@marcan/111655847458820583

Each of the 10 parity bits output by the function is the xor of exactly 104 of the 256 input bits.

Each of the 256 input bits contributes to (= is xor-ed into) either 3 or 5 of the 10 parity bits.

This is in line with the SEC-DED (single error correction, double error detection) ECC construction from the following paper:

https://people.eecs.berkeley.edu/~culler/cs252-s02/papers/hs...

Translating the above observations about the function into properties of the H matrix in the paper:

Each row of the matrix contains an identical number of ones (104).

Each column of the matrix contains an odd number of ones (3 or 5).

- The "hash" is probably an error correcting code fed into GPU cache debug registers which will be stored in the cacheline itself, you're expected to compute the ECC because it's so low level. That is, the goal isn't to protect the DMA interface. (but this isn't 100% certain, it's just an educated guess)

- The "sbox" is similar to but not the same as a regular ECC as commonly used in hardware.

- Martin argues that the existence of such registers and the code table could have been guessed or brute forced, even though a compromise or info leak from Apple seems more likely. Or possibly even from the old PowerVR days. But if it's the NSA then who knows, maybe they are literally fuzzing hidden MMIO ranges to discover these interfaces.

- This is possible because the GPU has full DMA access without an IOMMU for performance reasons, so it's fertile ground for such exploits. Probably more will be discovered.

So that's all reassuring.

Or a joint project between several organizations.

Similar for the GPU too. They may have started with HDL licensed from others (like I think their GPU might actually have been directly based on the PowerVR ones they used to use, but I believe the ARM one is basically from-scratch) but this vulnerability seems unlikely to have existed since then…

Maybe a nation state, e.g., APT?

And while Kaspersky is refusing to speculate at all about attribution, the Russian government has claimed (without giving specific evidence) that it's NSA.

“This iMessage exploit is crazy. TrueType vulnerability that has existed since the 90s, 2 kernel exploits, a browser exploit, and an undocumented hardware feature that was not used in shipped software”

https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...

(talk starts at minute 26:20)

According to him the exploit chain was likely worth in the region of a 8-digit dollar value.

¹ https://en.wikipedia.org/wiki/Felix_von_Leitner

I guess somebody is going to get fired.

Decade old Backdoors no

I really doubt it's a backdoor after reading the blog post and this thread chain from a prolific M1 MacBook hacker (macran) I think it was just an unused or very rarely used feature that was left enabled by accident.

https://social.treehouse.systems/@marcan/111655847458820583

Some choice quotes.

First, yeah, the dbgwrap stuff makes perfect sense. I knew about it for the main CPUs, makes perfect sense it'd exist for the ASCs too. Someone had a lightbulb moment. We might even be able to use some of those tricks for debugging stuff ourselves :)

Second, that "hash" is almost certainly not a hash. It's an ECC code*. I bet this is a cache RAM debug register, and it's writing directly to the raw cache memory array, including the ECC bits, so it has to manually calculate them (yes, caches in Apple SoCs have ECC, I know at least AMCC does and there's no reason to think GPU/ASC caches wouldn't too). The "sbox" is just the order of the input bits to the ECC generator, and the algorithm is a textbook ECC code. I don't know why it's somewhat interestingly shuffled like that, but I bet there's a hardware reason (I think for some of these things they'll even let the hardware synthesis shuffle the bits to whatever happens to be physically optimal, and that's why you won't find the same table anywhere else).

Why? Apple isnt exactly a small family business and this is quite the drastic "feature" to be left enabled by accident.

How would one look from your perspective?

Because 1. it helps with debugging at development time; 2. it may take unreasonable effort to disable, possibly from a hardware team's point of view with no direct security background; 3. it may be worth keeping around for future patching flexibility.

Source: [0]

> Apple isnt exactly a small family business and this is quite the drastic "feature" to be left enabled by accident.

No matter how large and hierarchical a company is, there will always be teams making hundreds of small, apparently localized decisions in their own line of work, without consulting anyone outside their team, and without seriously considering ramifications. It's humans all the way down.

> How would one look from your perspective?

A feature where you poke a seemingly random 64-bit value into an apparently arbitrary memory address, which grants you access to something you wouldn't normally have. That'd be a backdoor to me.

In the case at hand, the feature neither has a hidden MMIO address (it's discoverable in a small-ish search space), nor does it require a secret knock (but instead apparently just a somewhat convoluted checksum.)

[0]: https://social.treehouse.systems/@marcan/111656703871982875

Mistakes happen, maybe it's used in the manufacturing or fab phase to test something. Maybe it's used by the GPU firmware itself to perform some operations.

Maybe it was used by some older SoCs to do something and was just never removed.

Apple may not be a small family business but silly mistakes still happen all over the place in nearly every large system.

To quote another post by macran cause I feel like it's super relevant when trying to analyse how this kind of stuff comes about.

@nicolas17 @nil Correct. The question is, how many more of these fun bypasses are left undiscovered? The GPU is a huge amount of hardware and firmware.

Computers are so incredibly complicated now days that these kinds of hardware bugs are likely sitting around elsewhere as well, they don't come around that often because the amount of effort required to find them is likely a lot, which is likely only viable for a nation state actor.

Even though no public documentation exists, I'm sure thousands of Apple engineers have access to a modded gdb or other tooling to make use of it.

https://social.treehouse.systems/@marcan/111655847458820583

Nevertheless, this does not explain at all the astonishing fact that they were mapped by default in the accessible memory space, unless listed and explicitly denied in the system configuration files.

No amount of incompetence seems enough to explain such a default policy, so the supposition of an intentional backdoor still seems more likely.

I think you're overestimating how granular the memory mappings are (or how isolated the debug registers are). They're usually used to control access on a peripheral level, not to individual registers within a peripheral.

It's just a few lines of code to parse the memory map and deny all undefined regions. As well as being good for security, it also helps find out-of-bounds write bugs, and ensures you can't accidentally ship an out of date memory map.

  For Wi-Fi–only devices, the Messages app is hidden. 
  For devices with Wi-Fi and cellular, the Messages app is still available, but only the SMS/MMS service can be used.

Does iPad support SMS? The cellular line is usually only for data, https://www.howtogeek.com/710767/how-to-send-sms-text-messag...

  iPads can't send SMS text messages through Apple's Messages app. Even if you have an iPad with a cellular data plan for mobile internet on the go, you still can't send SMS text messages.

>In the Messages app , you can send text messages as SMS/MMS messages through your cellular service, or ...

Also my own experience is that it at least can receive SMS text messages, just it won't show you if it's not from your carrier (if it's from your carrier, it shows you via a popup window or something, can't really remember as that was several years ago).

  With Continuity, you can send and receive SMS/MMS messages on iPad using the cellular connection on your iPhone.

If it's not shown in Apple's Messages app, maybe it was a carrier-specific app?

Mere differences in timing could have indicated the address was a valid address, and then the hash could perhaps have been brute forced too since it is effectively a 20 bit hash.

The part that's less easily explained is how they were able to reconstruct a custom sbox table to execute the debug code. That's where the "insider threat" insinuations are strongest, but personally I'm not convinced that it precludes any number of other plausible explanations. For example, the attackers could have extracted the sbox from: older firmwares, OTA update patches, pre-release development devices (probably purchasable on ebay at some points), iOS beta releases, or a bunch of other leaky vectors.

The researcher basically says "I couldn't find this sbox table in any other binary where I looked for it." Well, that's not necessarily surprising since it appears to be Apple specific and thus there are a limited number of binaries where it might have appeared. And as the researcher notes, this includes now unpublished binaries that might have been mistakenly released. It's totally plausible that the attackers got lucky at some point while they were systematically sniffing for this sort of leak, and that the researcher is unlikely to have the same luck any time soon.

The fact the attackers didn't know that Boolean expression suggests they reverse engineered it rather than had documentation.

And for a single bit, the hash value is a single value from the sbox table. That means this hash algorithm could reasonably have been reverse engineered without internal documentation.

In fact, this is how I'd implement it if someone said to me it was important that bugs couldn't lead to random writes. This implementation also effectively prevents someone using this feature whilst giving a buffer address they don't know the contents of.

10 bits of security is probably enough for that as long as you reboot the system whenever the hash value is wrong. The coresight debug functionality can totally reboot the system if it wants to.

But it might also be a backdoor, intended or not.

In addition contents of the presentation, in terms of timeline...

2018 (September): First undocumented MMIO-present CPU launched, Apple A12 Bionic SOC.

2021 (December): Early exploit chain infrastructure backuprabbit.com created 2021-12-15T18:33:19Z, cloudsponcer.com created 2021-12-17T16:33:50Z.

2022 (April): Later exploit chain infrastructure snoweeanalytics.com created 2022-04-20T15:09:17Z suggesting exploit weaponized by this date.

2023 (December): Approximate date of capture (working back from "half year" quoted analysis period + mid-2023 Apple reports.

The presenters also state that signs within the code reportedly suggested the origin APT group has used the same attack codebase for "10 years" (ie. since ~2013) and also uses it to attack MacOS laptops (with antivirus circumvention). The presenters note that the very "backdoor-like" signed debug functionality may have been included in the chips without Apple's knowledge, eg. by the GPU developer.

So... in less than 3.5 years since the first vulnerable chip hit the market, a series of undocumented debug MMIOs in the Apple CoreSight GPU requiring knowledge of a lengthy secret were successfully weaponized and exploited by an established APT group with a 10+ year history. Kaspersky are "not speculating" but IMHO this is unlikely to be anything but a major state actor.

Theory: I guess since Apple was handed ample evidence of ~40 self-doxxed APT-related AppleIDs, we can judge the identity using any follow-up national security type announcements from the US. If all is quiet it's probably the NSA.

Assuming it wasn't a lucky guess, timing attacks are often used to find this stuff.

Perhaps. But it's easier to phone the technical librarian and say "Hi! I'm Bob from the password inspection department. Can you verify your current password for me?"

The later works when you are not as big as Apple. When you are as big as Apple, you are a very hot target for attackers. There is always the effort vs reward when it comes to exploiting vulnerabilities. The amount of effort that goes into all this is worth thousands of dollars even if someone is doing it just for research. If I was doing this for some random aliexpress board it would be worth nothing and probably security by obscurity would mean no one really cares and the later part works here. But I wonder what Apple is thinking when they use obscurity cause people must start working on exploiting new hardware from day 1. You literally can get one on every corner in a city these days. Hardware Security by obscurity for example would be fine for cards sold by someone like nvidia to only some cloud customers and those are then assumed obsolete in a few years so even if someone gets those on eBay the reward is very low. iPhones on the other hand are a very consumer device and people hang on to their devices for very long.

There is a photo of Mark Zuckerberg with a cut off 3.5mm jack plugged into his laptop - likely to achieve a similar outcome.

Reminder to reboot your iPhone at least weekly if you are concerned about this kind of attack.

Frequently rebooting the device can’t hurt but it likely isn’t going to prevent a threat actor from achieving their objectives.

The best mitigation we have is to enable lockdown mode.

with the Hard Reset key sequence, https://www.wikihow.com/Hard-Reset-an-iPhone

  It’s a hardware exploit, using undocumented registers. It can only be mitigated against, but not fully patched.

Fuzzing is about searching a state-space of an entity: function, method, and I suppose even a hardware-block for unexpected or undefined, or maybe even undocumented behavior.

Certainly this could have been used by the exploiters of these bugs to find undocumented but desirable effects in the hardware of iOS hardware blocks or devices.

Did the systems software developers know about these registers?

Answering more broadly to your question, the "step-change" that you're asking for is precisely the "Lockdown mode" in iOS devices. It disables most of the features in order to reduce the attack surface of the device.

This vulnerability is they key vulnerability without which all the exploit chain would be useless.

[1] https://securelist.com/operation-triangulation-the-last-hard...

> After exploiting all the vulnerabilities, the JavaScript exploit can do whatever it wants to the device and run spyware, but attackers chose to: a) launch the imagent process and inject a payload that cleans the exploitation artifacts from the device; b) run the Safari process in invisible mode and forward it to the web page with the next stage.

In other words, if looking at the diagram, https://cdn.arstechnica.net/wp-content/uploads/2023/12/trian... , it's completely "game over" once you get to the skull icon in the lower left corner, and the Safari exploit is after that.

When I tried out lockdown mode out of curiousity, I found that it was aggressive about blocking PDF viewing. I quickly bailed on it because I often read research papers on the web, and it switched them from view to download.

An even bigger change: It could allow users to choose their iMessage client freely. Why not open up the protocol? I’m sure a security focused client would be popular and in the grand scheme of things easy to author.

Perhaps they could open up more of the OS and apps. Perhaps their claims about the security of users and the App Store is kind of BS.

Either a third party app would still use the same vulnerable frameworks as iMessage, or they would re-implement them potentially with more vulnerabilities, or just not implement the features, which is what Lockdown Mode gives you.

Browsers are not the only thing concerned here, there are many sectors impacted by this philosophy. Qubes-OS for Linux Distributions, replacing containers (and especially Docker) with daemon-less or even MicroVM (Firecracker, Podman, ...). I'm sure there are also heavily sandboxed clients for Matrix, SMS or Emails.

And being open source hasn’t prevented Android from being much more vulnerable to these kinds of exploits.

2-3 million dollars is pocket lint to people conducting serious business, let alone governments. It is at best okay if you are conducting minor personal business. This ignores the fact that attacks at the 2-3 million dollar range are trivially wormable. If you had actual cause to hack every phone you are only incurring marginal cents per attack. Even relatively minor attacks like targeting 10,000 people are less than one phone of cost per attack.

I don't know. $2-3m for reading code in Ghidra and throwing stuff at a wall until something sticks? Maybe some fuzzing, etc.

I get that you theoretically could find an exploit that for example, you send to 100 known wealthy people, and with it you steal saved cookies + device IDs from financial apps and then try to transfer their funds/assets to an account you control but...

Could you really pull that off 100 times before Apple catches on?

I guess you could... easily... now that I think about it.

Quite the cost in my eyes...

----

Force restart iPhone

If iPhone isn’t responding, and you can’t turn it off then on, try forcing it to restart.

    Press and quickly release the volume up button.


    Press and quickly release the volume down button.


    Press and hold the side button.


    When the Apple logo appears, release the side button.

Modern software sits on a foundation that was thought for a different era. They didn't have in mind the current challenges in terms of security and scale.

They’re even working on an embedded subset for embedded devices so things like microcontrollers like battery management, the Secure Enclave etc. can run it.

1. https://m.youtube.com/watch?v=lgivCGdmFrw

From https://securelist.com/triangulation-validators-modules/1108...

https://securelist.com/trng-2023/

From the articles at the above link...

C&C domains

Using the forensic artifacts, it was possible to identify the set of domain name used by the exploits and further malicious stages. They can be used to check the DNS logs for historical information, and to identify the devices currently running the malware: addatamarket[.]net backuprabbit[.]com businessvideonews[.]com cloudsponcer[.]com datamarketplace[.]net mobilegamerstats[.]com snoweeanalytics[.]com tagclick-cdn[.]com topographyupdates[.]com unlimitedteacup[.]com virtuallaughing[.]com web-trackers[.]com growthtransport[.]com anstv[.]net ans7tv[.]net

Since they're supposed to be disabled in production, what would be their point?

I'm no electronic engineer, but isn't it best for them to be fast and simple, to reduce the chance that they cause interference themselves..?

And isn't it strongly unlikely that an attacker in the supply chain (TSMC??) would be able to reliably plant this in all Apple chips from the A12 to the A16 and the M1 ??

4-year campaign backdoored iPhones using advanced exploit - https://news.ycombinator.com/item?id=38784073

(We moved the comments hither, but the article might still be of interest)

https://streaming.media.ccc.de/37c3/relive/11859

The evidence clearly indicates otherwise…

If they cooperate that's good and convenient, but that does not mean the intelligence service will not set in place contingencies for if the other side suddenly decides not to play ball anymore.

"We already know Apple cooperated with the spy agencies behind the publics back"?

Particularly considering how in the past Apple has been very willing to be on the receiving end of negative headlines for not giving US agencies decrypted access to iCloud accounts of terrorist suspects, with Google I don't remember it ever having been the target of such controversy, meaning they willingly oblige with all incoming requests.

[0] https://qz.com/1145669/googles-true-origin-partly-lies-in-ci...

The most noticeable difference is that SVG elements (?) are replaced with emojis. I'm not sure how that fallback works but it's funny to see buttons have seemingly random emojis embedded in them. (Does anyone know the details of how this replacement is done? Is it actually glyph fonts being replaced, not SVG?)

Told you so.

edit: The fact that this obvious statement gets upvoted above the apple backdoor on 22:40 of the talk also says alot.

edit1: https://imgur.com/a/82JV7I9

This is getting ridiculous. How many iMessage exploits have there now been via attachments? Why aren't Apple locking down the available codecs? Why isn't BlastDoor doing its job?

This is really disappointing to see time and time again. If a simple app to send and receive messages is this hard to get right, I have very little hope left for software.

Apple really needs a paranoid mode

I'd like to meet the person who suggested even sending .watchface files as iMessage attachments in the first place. What were you thinking? Did you not have a large enough attack surface already?

And even better, there are plenty of old Android phones out which will be vulnerable to various exploits because of weak OTA update support policies.

[1] https://en.wikipedia.org/wiki/Stagefright_(bug)

Also, there are plenty of old iPhones that do not receive updates anymore and are just as vulnerable so I’m not sure why you needed to get that in.

It can be disabled via Apple Configurator, https://news.ycombinator.com/item?id=38785311

Disabling iMessage would fall back to SMS, allowing messages to be snooped / modified in transit.

Hopefully they’ll also have a way to disable RCS, since it allows attackers to modify messages, and also has a larger implementation attack surface than SMS.

"Most message attachments are blocked and some features are unavailable."

iMessage with blue bubbles still works in Lockdown Mode. I think GIFs don't display properly and certain other attachments, but I can share photos, audio clips and video so I otherwise don't really notice that Lockdown Mode is enabled.

But browser exploits require the user to visit an infected website, which is much tougher. If I recieve an email or sms with "visit applesupport.info" I'm not going to click it.

> the unknown attackers kept their campaign alive simply by sending devices a new malicious iMessage text shortly after devices were restarted.

Rate limiting phishing attacks is certainly a useful security feature, but it does nothing to protect against targeted attacks.

Apple has had so many zero-click exploits in iMessage, yet they insist that you have to use Lockdown mode to do anything about it, and then proceed to bundle Lockdown mode with lots of potentially unwanted behavior.

I don't think there's any way to claim that Apple is just doing whats in the customer's best security interest.

Me deciding to ride the subway to work for free is a user's choice, but that doesn't mean it's right. Using infrastructure for free because I feel like it is certainly my choice but I can't justify anger when someone makes me pay to use it since I should have paid in the first place. Currently Apple doesn't run iMessage as an open standard so it runs in "authorized riders only" mode.

>I don't think there's any way to claim that Apple is just doing whats in the customer's best security interest.

This isn't what I claimed. I claimed Apple treated unauthorized 3rd party access to their infrastructure as a security risk and worked to shore up that risk. As you pointed out, there have been plenty of zero-click exploits in iMessage. Limiting the devices sending iMessages increases security. I believe Apple doesn't allow iOS VMs in general for the same reason.

If apple is forced to shut down iMessage being the exclusive option and have some pure SMS application they might see a sudden noticeable drop in market share.

Nvidia has a very similar green man bad syndrome going on too. As the amount of time a HN discussion on Nvidia increases, the probability of mentioning that Linus said “fuck you nvidia” approaches 1, even though it’s irrelevant to a topic, or that he's a mercurial asshole who's said a whole lot of things.

The casual fanboyism disrupts all discourse on these topics because there’s a large minority of users who have adopted what PG describes as “hater-ism” and allowed it to dominate their thinking on a topic. Negative parasocial attachment is the same process as positive parasocial attachment and just as problematic, but largely never called out.

http://www.paulgraham.com/fh.html

In short: lotta fanboys on these topics who don't even realize they're fanboys/adopting fanboy frames, because they don't realize that anti-fanboys are still parasocially attached too. And we've casually accepted the low level of discourse on these topics, and it pollutes the whole discussion of a lot of interesting topics because of who's doing them.

"Okay well, now that we're launching an alternative to SMS, how will we distinguish iMessage messages from regular SMS messages?"

"Hm, well, SMS messages are green, so what if we picked another color?"

"Yeah okay, blue? ¯\_(ツ)_/¯"

"Sounds good, mock it up and send it to the engineers"

edit: The reason for picking green originally was probably because all the "communication"-related apps had a green color scheme, including Messages. This persists today — the app icons for Phone, Messages, and FaceTime are all green.