I think “improved” also subtly implies that there was something in the code to do A, A has been improved so it no longer breaks in a specific way, and A could still be vulnerable to other unrelated attacks.

The thing I just improved is subject to future improvement. Subtly different than saying “fixed the input validation routine”, which implies some finality, or overcommitment.

Some still might interpret that as Apple using CYA language or a lack of admission, but to me it seems like a fairly pragmatic statement of what seems like reality.

It seems to me that "improved" carries the same type of uncertainty as "fixed" would. If the "improvement" didn't actually fix the security issue, then was it really an improvement?

(To be clear, it may have been, but we don't know without actually seeing what change they made to the code.)

In large organization, you'll see people move to verbiage like 'improved' because it's true without the implication that 'fixed' has which directly implies that the previous implementation was 'broken'. I am with Apple on this, they 'improved' the software.

As a user, I don't really run into problems regarding memory management. Reading this update, I don't see why I should update, really.

Clearly there's already something dealing with bad memory and Apple just made it a bit better, surely this isn't worth rebooting my phone for!

Apple's writing style is unclear. It is poor for the intentional obscurity. Granted, it is a small issue in the context of the rest of the document. But the problem remains: The writing is intentionally obscure!

This hides the severity of the problems the patch fixes. The word "fix" is nowhere on that page. Presumably, Apple are releasing these poor-quality release notes in order to protect their public brand. Those corporate objectives are coming at a cost of writing quality and clarity.

Note, at this time, these CVEs are not public, so the savvy user can not search them up themselves.

I think patch notes are important, and reasonable effort should be made to make them clear. Instead, effort was made to obscure. Clarity should be the default!

> Note, at this time, these CVEs are not public

I'm not sure what the lag is, but from what I've seen all Apple CVE's are made public at some point. The last one I got before this bunch (from [email protected]) was a month ago (relating to iOS and iPadOS 16.1.1 addressing a libxml2 integer overflow - CVE-2022-40303). If you look up that CVE at mitre.org, it's no longer marked as "RESERVED".

It matters less when the impact is clearly stated, but often you'll find an update claiming that it "improved stability" and you have to guess whether it's something you don't need if you haven't encountered stability problems, or a critical security update.