Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

48% Positive

Analyzed from 2322 words in the discussion.

Trending Topics

#apple#macos#user#https#lot#security#languages#com#better#claude

Discussion (137 Comments)Read Original on HackerNews

tengwar21 day ago
15.7.8 is out today as well, with these security fixes: https://support.apple.com/en-us/128071.

For context, there have been issues with MacOS 26 which have led many people to defer upgrading until MacOS 27 is available, and MacOS 15 is the previous version.

jghnabout 24 hours ago
> For context, there have been issues with MacOS 26 which have led many people to defer upgrading

For me the issue is liquid glass. Which I doubt is getting fixed any time soon

illithid0about 24 hours ago
Also a liquid glass hater, but for what it's worth, 27 is supposed to make it a little bit better. I would prefer to go back to what I had before I had to upgrade into this horrible UI, but this is better than nothing.

https://www.cultofmac.com/news/liquid-glass-changes-ios-27-m...

hbnabout 23 hours ago
I've been running the 27 beta and it fixes so much of the ugliness I hated in Tahoe. Lots of places had toolbars restored, solid areas that indicate where the window can be grabbed. The shitty icon spam in menus is back to sanity. And window corner radii are consistent and less bulbous.
noname120about 22 hours ago
macOS 17 is decisively faster on my MacBook Air M1 16 GB than macOS 26/27 is on my MacBook Pro M2 Max 32 GB. And I don’t mean just the animations themselves but lag/sluggishness/responsiveness in general.
trollbridgeabout 23 hours ago
You can almost turn it off on the 27 beta, and 27 seems to perform a lot better too.
lapcatabout 24 hours ago
> this is better than nothing.

Having installed the beta, I think that's the best you can say about it.

coldpieabout 20 hours ago
I found if you turn off transparency effects and turn on high contrast in the accessibility settings, it's actually a pretty nice looking UI. Still has some dumb quirks like inconsistent corner radiuses and text appearing under UI elements (because they're assumed to be transparent, but aren't). But all software is trash in 2026 so be thankful it isn't even worse, I guess.
Melatonicabout 17 hours ago
Been doing that for years now already (performance boost). You can also do high contrast mode per app (if were talking about iOS). Must have for iMessage I think personally as it makes hard to read Green Bubbles a nice dark green that is very pleasant.
pmdrabout 21 hours ago
I bought a MBP mainly for the hardware, otherwise I'd have stuck with Linux. OS-wise, the jump from Monterey (which I'd last used) to Sequoia was smooth and still feels that way. I prefer not to notice the OS at all, something that I feel would be hard to do on Tahoe due to all that liquid glass and dumb transparency and animations.

Seriously, who the heck even asked for those?

IdiotSavageabout 22 hours ago
I hate the round corners. It's already too much on 15, but way worse on 26. It looks like "Baby's first OS", designed by Fisher-Price.
hbnabout 22 hours ago
shepherdjerredabout 19 hours ago
27 is a lot better. You can make the UI opaque again (they provide a transparency slider)
frizlababout 23 hours ago
macOS 27 does polish Liquid Glass and makes it look passable on macOS IMHO. It was very bad on 26. Comically bad.
reddaloabout 22 hours ago
That's the sad thing: Apple decided to leave all Intel macs on broken macOS 26. Very bad on Apple's part.
Hamukoabout 23 hours ago
Same. It's not the worst thing in the world, at least with Reduce Transparency enabled in the Accessibility settings, but I still don't feel any inclination to upgrade. My personal Mac Studio is macOS 15 and my work MacBook is on macOS 26, and I don't think there's a single thing that I find to be better on the work laptop than on my personal machine.

I might update to macOS 26 in September to be ready to update to macOS 27. Being two versions behind doesn't seem reasonable and I'd rather be on the "Tahoe but less shitty" version than Tahoe itself.

simlevesqueabout 22 hours ago
You can disable it in the accessibility preferences.
embedding-shapeabout 24 hours ago
Same thing happens almost every release. I've stopped updating my Mac machine until I see something in the release notes I literally have to have in order to continue doing macOS/iOS builds, otherwise I'm staying on the version I've validated to work, and I know the existing bugs with.
GeekyBearabout 17 hours ago
As we used to say in the Windows world, wait for service pack 3.
pjmlpabout 1 hour ago
That doesn't work any longer given patch tuesdays, at work wait that IT validates them and pushes the updates via managed WSU, at home, it is worthwhile wanting if something hits the news on WindowsCentral, Verge or what have you.
DavideNLabout 22 hours ago
A better strategy would probably be to stick with the previous *major* release, but, do install its ("minor") security updates...
embedding-shapeabout 22 hours ago
> do install its ("minor") security updates

Yeah, I thought so too, but surprise surprise; some months ago one of the "minor" updates "broke" ("upgraded") something that made my CI/CD setup stop working, that's when I dropped the idea that Apple even do "minor" updates anymore.

boukeabout 23 hours ago
The question now is, is 27 sufficient enough of an improvement over 15 to upgrade and tolerate Liquid Glass?
reddaloabout 22 hours ago
>have led many people to defer upgrading until MacOS 27 is available

Then there's me, crying in MacBook Pro 2019 stuck on MacOS 15 because 27 won't be available for my machine.

ExoticPearTreeabout 24 hours ago
26.0 had a very annoying video jitter issue, but that was the first things that I noticed to be fixed in the next 26 release. Other than that, it worked just fine.
andreasleyabout 24 hours ago
The bug that led to network connection issues after 49 days of uninterrupted uptime was a bit of a showstopper for me.
carraabout 23 hours ago
Are there no versions between MacOS 15 and 26???
kylemaxwellabout 23 hours ago
They changed the numbering scheme, so... no, there aren't. Version numbers are now year-based, but previously they were not.
hbnabout 23 hours ago
Last year they unified all their OS version numbers to just match upcoming year.

macOS went from 15 to 26

iOS went from 18 to 26

watchOS went from 11 to 26

and so on

classifiedabout 22 hours ago
No, 26 is the successor of 15. They changed the numbering to year-based.
crossroadsguyabout 23 hours ago
Did they un-hardcode the corner radius? I mean were they able to? I mean not that that anyone at this point needs convincing how utterly disgusting incompetent they’re at software.
gedyabout 22 hours ago
They reduced the radius back to older, smaller size and now all apps use a single radius, vs the weird 3 different radii in Tahoe. Looks better.
hbnabout 22 hours ago
I was shocked to find out the inconsistent corner radii in Tahoe was an intentional design decision. I figured it's so obviously bad that it was just sloppy work. But one of the WWDC session videos bafflingly clarified that it depends on whether the app has a toolbar or not.

https://youtu.be/VqTn9NgiE1s?t=439

I can't imagine how the people who signed off on that were put in charge of design at Apple.

pjmlp1 day ago
Map the amount of fixes with "... improved bounds checking...", "...improved memory handling...", "...improved memory management..." into the amount of developer, QA and release management teams salaries per hour, versus other stuff they could be working on, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers are always exposed to the world network.
bluecalm1 day ago
>>, and that gives an approximate value of how using specific languages maps into monetary loss, and why companies are starting to care nowadays, given computers are always exposed to the world network.

You need also factor development time and ease of finding developers willing to work in a specific language. There are other factors like readability of the code (very verbose languages are likely to be worse) and cost of maintenance - languages forcing a lot of abstractions are likely much worse.

acdhaabout 24 hours ago
> You need also factor development time and ease of finding developers willing to work in a specific language

This even more strongly favors Rust or Swift. Nobody is writing C or even Objective-C in 2026 as a growth language.

zbentleyabout 23 hours ago
If you just meant apple-targeting developers, then yeah; you're right that those languages are in decline. But if you meant developers in general, I think you'd be surprised how many growth sectors are hiring C programmers. They're often not SaaS tech companies, but they are massive and many are growing. Hardware, industrial control systems, defense/aerospace ... there's a ton there, the spaces in which they hire just don't overlap a ton with the spaces frequented by hacker news. Also, a lot of them aren't US based companies.

I hope that changes over time, since I definitely agree that the downsides of C-family languages massively outweigh the downsides of competitor languages.

zbentleyabout 23 hours ago
> very verbose languages are likely to be worse

Citation needed. I don't think there's a correlation there. Over-architected Java spaghetti is verbose and unmaintainable. Under-architected Perl code golf that metastisized is terse and unmaintainable.

> languages forcing a lot of abstractions are likely much worse

Citation needed. C++ has had some very high-level abstractions on top of a low-level runtime for awhile, and plenty of people have decided to use it and hire for it regardless. What counts as an "abstraction" or "forced abstraction" is a very very subjective topic.

pjmlpabout 21 hours ago
Even C can be super abstracted, see early 1980-90's business software written in C, with nice stuff like Yourdon Structured Method, leading to over-architected C spaghetti with macros, a decade before Java came to be.

The problem is the lack of interest since Morris worm came to be, to provide better mechanisms in said languages, until governments and key big tech names decided it was time to change existing practices.

snvzzabout 24 hours ago
If anything, there's a strong argument to switch to seL4.
yjftsjthsd-habout 20 hours ago
It was my vague understanding that by the time you implemented all the apis needed to run normal software on top of that, you either have enough apis that different tasks can still compromise each other, or you have shoved everything into a single task with very little isolation between normal user processes. In either case, it doesn't seem like you actually gained so much. What am I missing?
pjmlpabout 20 hours ago
Indeed, however without some regulatory help it Will take its time for such kind of improvements across the industry.
UqWBcuFx6NV4r1 day ago
“nah bro, all those other developers are just garbage, I am the one person that can write memory safe C”
embedding-shape1 day ago
Lots of "in collaboration with Claude and Anthropic Research" mentions, no mentions of other labs. I'd assume Apple already had access to whatever the most powerful model is at the various US-based labs, but perhaps not?
woadwarrior011 day ago
Those were voluntary disclosures by two Anthropic researchers and the security firm Calif. I know one more CVE on the list that was discovered using an AI agent and wasn't disclosed as such. I suspect there are many more.
tombot1 day ago
Apple isn’t friends with OpenAI anymore
muterad_murilax1 day ago
What happened?
mrtksn1 day ago
The gist is, OpenAI hired a high ranking Apple employee who helped other Apple employees get hired by OpenAI and exfiltrate Apple trade secrets in the process.

Allegedly of course.

lapcatabout 23 hours ago
> Lots of "in collaboration with Claude and Anthropic Research" mentions

I wouldn't say 4 is lots. The entire list is massive. I haven't counted myself, but someone claimed that macOS 26.6 has the all-time record with 155 CVEs.

embedding-shapeabout 22 hours ago
Considering that in Feb 2026 (https://support.apple.com/en-us/126348) Claude wasn't mentioned even once, 4 sure sounds like "lots" compared to nothing :) But you're right, it's subjective ultimately.
senadir1 day ago
Apple also hosts a copy of Claude internally in their servers.
cromka1 day ago
Do they? As in Claude but on premises? Wonder if this is gonna be the solution that e.g. banks will require, exactly like they do now for cloud services (e.g. Azure on premises).
Cider99861 day ago
Banks are all about security theatre so probably not.
pbronez1 day ago
Pretty extreme solution… you can get Claude models from AWS Bedrock and Google Model Zoo. These are both very helpful for compliance and security, but do require you to have a cloud strategy.
bel8about 23 hours ago
source?

edit: it seems asking for a source it frowned uppon in this site. And it seems there's no source.

mholmabout 23 hours ago
I don't believe it's published anywhere, but it's common knowledge to Apple engineers. I can second the poster's assertion that they run Claude internally.
MBCookabout 23 hours ago
I don’t know about hosting it internally but a an Apple focused podcast I listen to (Accidental Tech Podcast) has mentioned numerous times in the last few months they’re using Claude heavily. And they know Apple insiders.
claiirabout 22 hours ago
also “ Using GLM From Z.AI”
AJRF1 day ago
Weird thing to see at number 3 on HN - is there some subtle context I am missing here?

Are we wink winking that it's a lot of fixes?

microtonal1 day ago
It is a lot of fixes and the Android Security Bulletins of June and Android 17 also had a lot of fixes [1], despite ASBs only containing high/critical vulnerabilities (other vulnerabilities are only fixed in major releases and QPRs, which most Android vendors respectively roll out late or never at all).

I think the story here is that vulnerability discovery has accelerated a lot with LLMs, but since are adversaries are doing the same, it is more important than ever to update quickly (and not let some Android vendors get away with their lazy update schedules).

[1] https://source.android.com/docs/security/bulletin/2026/2026-... https://source.android.com/docs/security/bulletin/android-17

cubefoxabout 24 hours ago
So using newish phones that don't get updated anymore could be a lot more dangerous now than it was just a year ago.
acdhaabout 23 hours ago
Right - it was always dangerous but people who figured they weren’t important enough to be attacked might find out that LLMs have shifted that cost in the wrong direction.
grahamlee1 day ago
And it's not actually that much information "about the security content". For example: "Impact: An app may be able to access sensitive user data. Description: An access issue was addressed with additional sandbox restrictions." This references CVE-2026-43819, which doesn't have any more information. Compare this with the nearly decade-old https://support.apple.com/en-gb/103680, and you see much more specific information about problems and their remedies (except in situations where Apple's action was to update a vendor component).
Gigachadabout 22 hours ago
The vagueness could be intentional. There’s been a big issue with linux where proof of concept exploit code gets posted before the bug is announced because people reverse engineer it from the fix commits.

Apple has the advantage that they can keep everything secret for long enough for the patches to roll out. And realistically there is no reason the user needs to know the details of an exploit that was patched before it was ever used.

eviksabout 6 hours ago
> before it was ever used.

But since this is never known, does the user need to know?

DStiego1 day ago
Relevant context might be for example that there are 4 mentions each of Claude by Anthropic and XGPT by ThreatBook, both based on LLMs.

AI attribution might be one reason people are particularly curious.

AJRF1 day ago
I missed that, thanks for pointing out
cromka1 day ago
I think it's because it's the first big batch of fixes found at Apple by Mythos.
nozzlegearabout 22 hours ago
Is this speculation? Where does it say Mythos was responsible for any of this?
cromkaabout 21 hours ago
It is speculation, which is what I think the upvote count reflects.
Tepix1 day ago
croemer1 day ago
I think that's it?
TheJoeManabout 22 hours ago
This may be a naive take, so if anyone has insight please feel free to share, but across Windows, Mac, and Linux OS's I see many cases of path parsing vulnerabilities resulting in sandbox escapes, code execution, or data access issues. When presenting the user with a file picker or command-line input, is it really needed that the software can handle the full POSIX spec?

I do not see a "typical" user needing to access a path with say a network storage but multiple ../.. and hard and soft symlinks simultaneously. I think "be liberal in what you accept" might need to be revisited for path parsing with some sort of OS-wide single-implementation as an optional feature.

acuozzoabout 21 hours ago
> I do not see a "typical" user needing to access a path with say...

Typical users run software written by atypical users.

> some sort of OS-wide single-implementation

How do you propose handling migration? What if someone tries to expand an old archive file containing a now-forbidden path?

TheJoeManabout 21 hours ago
What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed chars?
SoftTalkerabout 20 hours ago
If the OS is working properly, the havoc should just result in "permission denied."

If there's a path on the system that the user should not be able to read, that's the job of the OS to handle, not the individual applications.

catlifeonmarsabout 21 hours ago
How would you enforce a single implementation of path parsing?
nizbit1 day ago
Collision counts are absurd. CVE-2026-43739 has roughly twenty credited researchers; CVE-2026-43816 has nearly as many. And ai attribution getting credit.
croemer1 day ago
One CVE even lists the same person twice!

CVE-2026-64691: Ruslan Dautov, Ruslan Dautov

Someone1 day ago
> One CVE even lists the same person twice!

Not necessarily. Could be two persons sharing that name. See https://revstat.ine.pt/index.php/REVSTAT/article/view/382

ayewoabout 16 hours ago
How did you unearth such a remarkable find of 2 different faculty individuals named "Philipp Otto" collaborating on the same paper :) ?
proactivesvcs1 day ago
One of them lists an anonymous person!

CVE-2026-43744: Mathis Mansière, an anonymous researcher

nkrisc1 day ago
It reads as if "an anonymous researcher" is describing Mathis Mansière, which is quite humorous.
conradfr1 day ago
It's Ted Danson.
FabHKabout 20 hours ago
Apropos, anyone else saw "fast user switching" in Tahoe turn into "excruciatingly slow user switching which after a minute of switching without success rebooted the whole damn machine"?
BoardsOfCanadaabout 19 hours ago
It would be so nice to see how many zero-days are going away for bad players right now.