That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it.
Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?
Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
As a user, I really don't care about the supposed purity or correctness of a website's tech stack. When I click "back" I want to go back to what I think the previous page was.
A building collapsing isn’t the only way people are affected by choices in construction. But if you want to talk about worst case scenarios then I can pick out some examples in IT too:
We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.
And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.
"The other side are where all of the bad guys and crazy violent lunatics are. The side I align with is the only sensible one; we would never do anything like that."
This sort of thinking causes extremism and division. It only perpetuates more of the thing you don't want!
It's also empirically not true: there are crazy people on both sides, but most people are pretty reasonable. If you treat them as if they are, despite your differences, they won't feel so alienated and perhaps you can both have a productive conversation. Both sides views are then likely to soften, and you can maybe even start working together.
This is about propaganda regimes, as much as about whataboutisms. Both sides paint the other as violent. Which is more believable. Sad as though the answer may be.
Nope. Both sides are not equivalent. The political right, in the U.S., has been significantly more violent than the political left for quite some time. And it’s not even close. https://pmc.ncbi.nlm.nih.gov/articles/PMC9335287/
I encourage anyone reading to look at the charts. There’s a single clearly anomalous data point with significantly reduced violence for “right terrorists” and significantly high number for “left” in 2025. It is the only year in any chart where left violence exceeds (or even comes near to) right.
It’d be extremely silly to infer some trend from this one anomaly.
Does it really matter who is more violent? The fact of the matter is both sides do have a nonzero amount of crazy/violent people and both sides could treat the other with more respect instead of furthering division.
You will notice I never said that both sides have the same amount of violence (since I don't think that that's actually relevant), so you are responding to a point I never made to begin with.
Vending machines and guns both kill people, so we should expend equal effort addressing the problems with both. Do I have that right?
This obsession with just pretending the two sides are mirror images, who simply need respect each other more is just lazy thinking. Interrogate what the contemporary American right values and believes. It is deep seated resentment (urban elites!), hate (owning the libs), bigotry (mass deportations now!), all wrapped up in a victimhood (white replacement theory) / inferiority complex. It should surprise exactly no one that the statistics are what they are.
The left’s biggest problem is people find them annoying for suggesting others could be more empathetic or do better at being inclusive. These two camps are just nowhere near comparable.
To address an issue, you first must understand it. I very much believe what the right values informs why they’re violent. These values and beliefs need to be shamed into oblivion. Diversity is a strength! Expertise is valuable! People should have freedom to live their lives so long as they don’t harm others! People who believe otherwise should tremble with embarrassment to say so.
Well, I guess you'll always live in a land of division and spite, always angry yourself, and the "others" always angry back at you, squabbling forever while things slowly get worse. I hope you enjoy the bed you've made for yourself.
Is this why shop owners board their windows and doors up every time there’s an [insert left wing cause] protest in their area? I haven’t kept up but was Charlie Kirk’s assassin a left or right winger, or one of those horseshoe fellas.
I’m one of the types who can parse observable reality and notice that businesses don’t board up when democrats win elections. They do it when the other guy wins. The claim that the “right wing”, such as it exists as a cohesive entity, is uniquely responsible for political violence today is an absurd claim on its face because I could look out my window on my commute and simply notice who was doing the violence. Or, in the case of Charlie Kirk, who was doing the assassinating.
I strongly disagree on the Secure Boot front. It's necessary for FDE to have any sort of practical security, it reduces malicious/vulnerable driver abuse (making it nontrivial), bootkits are a security nightmare and would otherwise be much more common in malware typical users encounter, and ultimately the user can control their secure boot setup and enroll their own keys if they wish.
Does that mean that Microsoft doesn't also use it as a form of control? Of course not. But conflating "Secure Boot can be used for platform control" with "Secure Boot provides no security" is a non-sequitur.
Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop. Calling it useless because it doesn't match your threat model... I hate todays security people, can't threat model for shit.
> Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop.
Both of these are super easy to solve without secure boot: The device uses FDE and the key is provided over the network during boot, in the laptop case after the user provides a password. Doing it this way is significantly more secure than using a TPM because the network can stop providing the key as soon as the device is stolen and then the key was never in non-volatile storage anywhere on the device and can't be extracted from a powered off device even with physical access and specialized equipment.
> The device uses FDE and they key is provided over the network during boot, in the laptop case after the user provides a password.
Sounds nice on paper, has issues in practice:
1. no internet (e.g. something like Iran)? Your device is effectively bricked.
2. heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.
3. no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.
> no internet (e.g. something like Iran)? Your device is effectively bricked.
If your threat model is Iran and you want the device to boot with no internet then you memorize the long passphrase.
> heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.
The server doesn't have to be in their jurisdiction. It can also use FDE itself and then the key for that is stored offline in an undisclosed location.
> no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.
If your BIOS or bootloader is compromised then so is your OS.
Well... they wouldn't be the first ones to black out the Internet either. And I'm not just talking about threats specific to oneself here because that is a much different threat model, but the effects of being collateral damage as well. Say, your country's leader says something that makes the US President cry - who's to say he doesn't order SpaceX to disable Starlink for your country? Or that Russia decides to invade yet another country and disables internet satellites [1]?
And it doesn't have to be politically related either, say that a natural disaster in your area takes out everything smarter than a toaster for days if not weeks [2].
> If your BIOS or bootloader is compromised then so is your OS.
well, that's the point of the TPM design and Secure Boot: that is not true any more. The OS can verify everything being executed prior to its startup back to a trusted root. You'd need 0-day exploits - while these are available including unpatchable hardware issues (iOS checkm8 [3]), they are incredibly rare and expensive.
> Say, your country's leader says something that makes the US President cry - who's to say he doesn't order SpaceX to disable Starlink for your country?
Then you tether to your phone or visit the local library or coffee shop and use the WiFi, or call into the system using an acoustic coupler on an analog phone line or find a radio or build a telegraph or stand on a tall hill and use flag semaphore in your country that has zero cell towers or libraries, because you only have to transfer a few hundred bytes of protocol overhead and 32 bytes of actual data.
At which point you could unlock your laptop, assuming it wasn't already on when you lost internet, but it still wouldn't have internet.
> The OS can verify everything being executed prior to its startup back to a trusted root.
Code that asks for the hashes and verifies them can do that, but that part of your OS was replaced with "return true;" by the attacker's compromised firmware.
That's premised on the attacker never having write access to the encrypted partition, which is the thing storing the FDE key on a remote system or removable media does better than a TPM. If the key is in a TPM and they can extract it using a TPM vulnerability or specialized equipment. Or boot up the system and unlock the partition by running the original signed boot chain, giving the attacker the opportunity to compromise the now-running OS using DMA attacks, cold-boot attacks, etc. Or they can stick it in a drawer without network access to receive updates until someone publishes a relevant vulnerability in the version of the OS that was on it when it was stolen.
Notice that if they can modify/replace the device without you noticing then they can leave you one that displays the same unlock screen as the original but sends any credentials you enter to the attacker. Once they've had physical access to the device you can't trust it. The main advantage of FDE is that they can't read what was on a powered off device they blatantly steal, and then the last thing you want is for the FDE key to be somewhere on the device that they could potentially extract instead of on a remote system or removable media that they don't have access to.
I (the commenter you responded to) am a security engineer by trade and I'm arguing that SB is useful. I'm not sure if the parent commenter is or isn't a security person but my interactions with other people in the security field have given me the impression that most of them think it's good, too.
So I'm a little confused about the "can't threat model for shit part," I think these sorts of attacks are definitely within most security folks threat models, haha
Security professionals wanting to have security solutions they can sell to people doesn't mean that those people actually need or benefit from those solutions. Security professionals tend to vastly overestimate the relevant threat models relevant for regular people and have no concern for anything other than so-called security.
>It's necessary for FDE to have any sort of practical security
why? do you mean because evil maid attacks exist? anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.
>bootkits are a security nightmare and would otherwise be much more common in malware
why weren't they more common before?
serious question. Back in the 90s viruses were huge business, BIOS was about as unprotected as it would ever possibly be, and lots of chips came with extra unused memory. We still barely ever saw those kind of malware.
> anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.
Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run. With SB at least in theory you have a way to validate the entire boot chain.
> why weren't they more common before?
Because security of the rest of the system was not at the point where they made sense. CIH could wipe system firmware and physically brick your PC - why write a bootkit then? Malware then was also less financially motivated.
When malware moved from notoriety-driven to financially-driven in the 2000s, bootkits did become more common with things like Mebroot & TDL/Alureon. More recently, still before Secure Boot was widespread, we had things like the Classic Shell/Audacity trojan which overwrote your MBR: https://www.youtube.com/watch?v=DD9CvHVU7B4 and Petya ransomware. With SB this is an attack vector that has been largely rendered useless.
It's also a lot more difficult to write a malicious bootloader than it is to write a usermode app that runs itself at startup and pings a C2 or whatever.
> Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run.
Except that it's on the encrypted partition and the attacker doesn't have the key to unlock it since that's on the removable media with the boot loader.
They could write garbage to it, but then it's just going to crash, and if all they want is to destroy the data they could just use a hammer.
> The attacker does this when the drive is already unlocked & the OS is running.
But then you're screwed regardless. They could extract the FDE key from memory, re-encrypt the unlocked drive with a new one, disable secureboot and replace the kernel with one that doesn't care about it, copy all the data to another machine of the same model with compromised firmware, etc.
> serious question. Back in the 90s viruses were huge business,
No, they were not. They were toys written for fun and/or mischief. The virus authors did not receive any monetary reward from writing them, so they were not even a _business_. So they were the work of individuals, not large teams.
The turning point was Bitcoin. Suddenly it provided all those nice new business models that can be scaled up: mining, stealing cryptowallets, ransomware, etc.
The '90s was a bit too soon for that. Most people using the Internet then were still on dialup, to the extent they were connected at all. There weren't that many DDoSes yet. Even the Trin00 DDoS in 1999 only involved 114 machines.
DDoS for sale were not a big thing until Bitcoin. You couldn't transfer meaningful amounts anonymously.
And no, lol. There were no million machine botnets in 90-s. You could DDoS the entire countries with a few dozen computers, Slammer did that accidentally with Korea.
Secure Boot provides no useful security for an individual user on the machine they own, and as such should be disabled by default.
If you want to enable it for enterprise/business situations, thats fine, but one should be clear about that. Otherwise you get the exact Microsoft situation you mentioned and also no one knows about it.
So everyday users should be vulnerable to bootkits and kernel-mode malware...why, exactly? That is useful security. The fact that people do not pursue this type of malware very frequently is an effect of SB proliferation. If it were not the default then these attacks would be more popular.
Every day users care most about the files in their home directory (or cloud services these days). The OS kernel and ring 0 isn't any more important to them than that.
Ooh, I like this argument a lot. Right now I'm thinking a good analogy is, you live in a gated community, but the locks on your house and your ring camera are fine -- but your overly annoying gate system makes it hard for people or deliveries to get to you etc.
This is a tiresome argument that is based on a pile of unstated and rather shaky assumptions, ignores the very concept of opportunity costs and does not consider alternative solutions to the problems you seem to consider so important.
Fir starters, UEFI Secure Boot is actually rater bad at protecting users from bootkits or kernel-mode malware or anything, really. You can search this very website to get a giant list of bypasses and news about leaked vendor keys. Not to mention the fact that CrowdStrike Falcon incident had clearly demonstrated that Microsoft is more than happy to sign utterly insecure garbage.
Also, the issues with boot malware and kernel verification could be solved in many other ways, many of which are much more sensible or elegant. For example, by storing the bootloader and its keys on a physically separate read-only medium.
The issues with UEFI Secure Boot are actually the main point of the system, just like the issues with Windows executable signing are the whole point of that system.
No. The existence of actually dangerous bootkits in relation to ease of use of UEFI, ease of prevention, likelihood and magnitude of harm of said bootkits and adverse secondary problems when UEFI is used.
You're arguing for not wearing seatbelts because no evidence has been shown that anyone has ever been saved by wearing one has been presented. That's just stupid by refuting ubiquitously understood data and facts.
SecureBoot ensures a valid, signed OS is installed and that the boot process generally hasn't been completely compromised in a difficult-to-mitigate manner. It provides a specific guarantee rather than universal security. Talking about "many vectors" has nothing to do with SecureBoot or boot-time malware.
Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.
You can also use SB with your own keys (or even just hashes)...just because Microsoft is the default included with most commercially sold PCs—since most people use Windows on their PCs—doesn't mean SB is controlled by them. You can remove their signing cert entirely if you want. I have done this and used my own.
Plus they signed the shim loader for Linux anyways so they almost immediately gave up any "control" they might have had through SB.
Won't removing the Microsoft key prevent UEFI option ROMs from PCIe cards from loading when Secure Boot is enabled?
Is it even possible to install firmware containing an oprom resigned with a custom key onto, say, a modern Nvidia GPU, without the entire firmware bundle being signed by Nvidia's own key?
The OP is describing the status quo on mobile phones and tablets. On mobile Secure Boot, and systems like it, are used to lock out the user. If the boot path integrity is altered, some apps won't work or will provide degraded experiences.
What's happening the article is what has already happened on mobile: it requires vendor signing to run anything on mobile OS and the vendor locks out 3rd party drivers from their OS entirely.
It's yet another step towards desktop computing converging with mobile when it comes to software/firmware/boot/etc integrity attestation, app distribution and signing, and the ability to use your own bootloader and system drivers. When Secure Boot was first rolled out on laptops, it was used by Microsoft to lock the user out of the boot process before it was adapted to let users register their own keys, it can always be used for its original purpose, and how it's currently used on mobile, again.
You don't have the ability to revoke my keys on this machine, that's the point. Not even MS could do that, because these are _my_ keys. The alternative proposed here is no keys at all.
What's the improved security argument for terminating VeraCrypt's account though? SB does have clear benefits but what is unclear is the motivation for the account termination.
What's the likelihood that this account ban provides zero security benefit to users and was instead a requirement from the gov because Veracrypt was too hard to crack/bypass.
Are the demands that users become experts in provider their own security against more advanced actors not significantly worse? The control part is unfortunate but the defaults should make it so users can focus on sharing pictures of cats without fear or need for advanced cyber security knowledge.
Is it though? Claude's reliability is now at an all-time low of 98.7%. It's not a stretch to think that large companies will have second doubts about about adopting claude for their production environments.
> You can't stop accepting new customers unless you're fine with killing your potential future customer base. That's a ridiculous suggestion.
what? they already have, they aren't releasing mythos except to a limited pre-approved customer base who is practically begging them to take their money. they can do that for lower tier models and at this point they should.
reply