> Forcing their customers to install government-affiliated alternative CAs, in turn allowing the government to spy on its citizens more easily via mis-issued certs?
How's the support for X.509 "Name Constraints" these days:
One possible alternative might be to add the ability for user configuration to substitute one certificate for another one (both will need the same public key and subject name, but the substitute will not be self-signed (since you do not have the private key)), and to use the data in the substitute certificate instead of the original. If the name constraints extension is implemented, then it would make this and other things possible. Since the substitute certificate will be considered trusted, it is not necessary for the substitute certificate to have a signature (if it does (e.g. because you got it from somewhere else instead of making it yourself), then the signature can be ignored), nor is it necessary for the substitute certificate to be issued by anyone (this applies even if it is the end certificate being substituted).
I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.
It would be simple today to abolish the use of CAs but it just a big cargo biz that makes money on nothing as usual based on peoples incompetence. For 99% of all sites today security would be handled better without CAs. People simply don't understand how it works.
All that was true until fairly recently. Today, you can get certificates for free and there’s more transparency than ever thanks to CT.
What would you suggest as an alternative? TOFU?
I could see that for local applications (e.g. making mDNS/.local and private IP certs TOFU capable by default would be amazing, and maybe even for some explicit hobbyist public TLDs?), but I don’t think I’d love it for my bank or email provider.
> It would be simple today to abolish the use of CAs […]
The main technical way I know of doing this would be by putting TLS public keys in DNS (DANE, RFC 6698), but then you have to make sure that DNS packets are not fiddled with, so you need to bring in DNSSEC.
That's a false concern, because the names the CAs are certifying are still DNS names. If your TLD reasssigns your DNS name out from under you, or even if your TLD starts returning false data on only selected queries, the CAs will be happy to issue a cert to the new holder.
It would be great to have a widely-recognizable pseudodomain out there where the names were key hashes. It would actually graft really easily into DNSSEC. The zone format doesn't have to change at all; you just declare that if the KSK hash matches the domain label under this specific TLD, you don't need to check upstream of that. Then you add a P2P protocol for getting the actual data, and start slowly pushing that protocol down the resolver tree to incrementally decentralize everything.
No disrespect to you for posting this, but those iOS/iPadOS/MacOS are almost identical launch pages. Feels like a waste of time even having them be separate.
I was at WWDC for the Vision Pro launch and asked someone a technical question about tvOS. He said, 'ah, [Jim] could answer that, but he isn't here today'. When I asked if anyone else from tvOS was here the reply was, '[Jim] is the only person on tvOS' and I am pretty sure he was serious.
I’ve heard this kind of thing about Apple fairly regularly (the iTunes Remote app comes to mind). While there are issues to large teams, I feel like there is a middle ground that doesn’t result in a single point of failure. What happens when Jim wins the lottery?
It seems like Apple could very easily turn the AppleTV into a proper game console, but not with only one person on it. I guess it’s still just a “hobby” for them.
> It seems like Apple could very easily turn the AppleTV into a proper game console
Apple could turn the Mac, iPad or Vision Pro into a proper gaming console, too. It's just not something they are willing to do, no matter how well-positioned they are for it.
Apple wants you to buy your games through the App Store, so they can take the 30%, which means competing with Steam. Which means getting licensed games on the App Store.
Apple already fought one such license war over music and won. They're currently doing Apple TV as well.
However, for the gaming industry they're complete strangers. Unlike music (which is mostly made on Mac) and TV/Movies (which are often made on Mac, at least partly), gamedev is very much Windows focused.
Pushing for ports and licenses is an uphill battle, and probably not one Apple wants to take on. They have plenty of other profitable ventures.
Especially in the last few years, preservation has been a big topic. Gamers want their purchases to keep working in the future, not being broken by an OS update as it often happens with macOS (compared to Windows)
A lot of game industry operates on a "release and move on" model; nobody has time to keep updating an old game hardly anyone buys instead of working on a new thing. On PC and console this is fine because your games keep working more or less indefinitely.
But the vast majority of the games I've purchased on iOS can't be installed anymore. It's not great. In some cases the games still function, but I can't download them on new devices because the developer closed shop and disabled their Apple account.
I think you’re responding to “gaming” and thinking of AAA titles which are flashy and splashy but are a smaller market than mobile games. I guess gp might have been thinking of mobile or casual where Apple does have a significant stake and interest but no appreciable focus.
I'm thinking of gaming as in Steam, including indies, AA and AAA.
Of course Apple is doing perfectly fine for mobile gaming, and is giving more than enough tools to developers to implement mobile games perfectly well.
I am talking about PC gaming, and more specifically modern DXVK/Wine support. There's no need for ports, as the Steam Deck showed.
Apple Silicon GPUs are all capable of supporting Vulkan 1.3 and translating DirectX code. Proton 11 supports ARM/FEX natively, which would make Apple Silicon a first-class citizen if you use Asahi drivers. macOS users will be stuck with Game Porting Toolkit and it's lackluster support; iPad/AppleTV/iPhone users have no options whatsoever, presumably to redirect their attention to the App Store that Apple profits from so handsomely.
This is entirely a misleading point. DXVK, Wine and Proton are full of patches that exist to support individual games.
It is not just a translation layer, as much as a great effort of the open source community to force-port every game in existence to Linux. The effort also includes stuff like ntsync that gives the Linux kernel Windows-y APIs for performance.
I doubt Apple has any interest in any of that. I don't really blame them.
And purely in principle, why are we all going through so much effort to save game devs from writing good OS-independent arch-independent code?
That is the point. Valve is maintaining the patches; Apple has to do nothing besides support compliant Vulkan 1.2+ drivers (which their community already does).
Apple doesn't need to implement ntsync to support Proton or DXVK, either. macOS' synchronization primitives do the job just as well as esync or fsync does.
> why are we all going through so much effort to save game devs from writing good OS-independent arch-independent code?
Because Apple doesn't support OS-independent APIs. They also don't support old runtimes, so users will inevitably have to run the Windows version once the native code breaks.
Valve ported several of their games natively to macOS, and almost every single one of them is broken on modern Macs. Valve didn't change the game tech, it's all runtime breakage.
From what I understand you're saying that Apple should provide 2 things: (1) Vulkan drivers and (2) backwards compatibility forever.
I don't really know enough about graphics to discuss point (1). From what I understand, Apple GPUs don't really fit the Vulkan model too cleanly, and the Asahi Vulkan drivers are significantly less performant than Metal (how much of that is due to beta/community status vs. architectural bottleneck I have no idea).
But let's say they provide (1).
Providing (2) would simply be a big mistake. It is a huge mistake of Windows, of the C++ programming language and of the x86 ISA (none of which are very good). Linux distros do not provide this either, beyond the core kernel syscalls and glibc. It is certainly a very big ask and not something trivial.
I'm only asking for (1); Apple can keep breaking APIs forever as long as they support the libraries that enable Proton.
(2) is precisely the reason why nobody can port games to macOS anymore, and largely why ARM is a second-class citizen in PC gaming too. You cannot depreciate things like AVX or 32-bit library execution modes, and then demand native builds get made to 20-year-old games. Apple Silicon's ISA extensions like AMX are not a replacement for x86's SIMD extensions, it's not standardized through Arm or supported in Asahi either. Native Mac games need to incorporate Apple's proprietary and unstable tech like Metal and the Apple Silicon microarchitecture, which makes their games unstable and difficult to support in the long term. Translation is Apple Silicon's only choice for game preservation and mainstream game support.
> Apple GPUs don't really fit the Vulkan model too cleanly
This is a misconception that stems from Metal's preference for tile-based deferred rendering pipelines. Vulkan 1.3 is fully viable on the M1 onward, which is enough to support DirectX 12 translation in Proton. The performance of Asahi's drivers are not any worse than the official Vulkan drivers that Arm provides for TBDR-optimized GPUs like the Mali line.
Games should simply not be written for a particular architecture. The rendering part of the game engine should already be abstracted away from the particular rendering API (there are other significant platforms which do not support Vulkan: PS5 and Xbox, which your game should be capable of targeting). And the math library should have fallbacks to standard C (or standard C++ etc.) and then specialized implementations for AVX, NEON, SVE, etc.
Nothing else needs to be architecture specific.
Now, sure, NEON is slower than AVX-256/512. But backending to NEON or even standard C is certainly going to be faster than running stuff over an x86-to-ARM translation layer.
Sooner or later the Steam Deck 2 will release, probably on an ARM platform (if the Steam Frame compatibility layers go well), and millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when, if the games were well written in the first place, they could simply be trivially recompiled.
> 32-bit library execution modes
If your application assumes pointers are 32-bits, or any particular size, or even any set of particular sizes, it's completely broken.
As for (1), if Asahi Vulkan drivers are really good, that just goes to show why Apple isn't supporting Vulkan. Metal applications seem to be faster, and Apple wants to push devs to make their apps for the faster API.
You're welcome to disagree with me about (2), I don't care what macOS picks in this regard. It's not going to help games get ported to macOS or Apple Silicon any faster. There are hundreds of thousands of video games that will never be updated again, macOS will never support these games without translation. Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. This is why efforts like WoW64 and FEX exist in the first place; you will never recompile the majority of Windows games. Ever.
(1) is just common sense. Go ask your favorite LLM; does hardware-level TBDR optimization degrade basic Vulkan support? No, it doesn't, and we have dozens of mobile GPUs that support Vulkan to prove it. Metal is not "faster" and it's architecture does not preclude high-performance Vulkan drivers in any way. If you don't believe me, ask anyone else.
> millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when
x86-to-ARM doesn't have to be slow. Accelerators like Apple's AMX can leverage autovectorization during translation, which is significantly faster than NEON and potentially more efficient than x86 SIMD.
D3D-to-Vulkan and Win32-to-Linux is almost always more power-efficient for most GPUs/games. Wine is much thinner than a full-fat Windows runtime, and DXVK can translate DirectX code into batched calls with a shader cache even if the game itself doesn't support it. Do you think the Steam Deck runs games better on Windows, somehow?
Why are you deltaing to windows? You should be deltaing to native.
Obviously an IBM 704 program will run faster on an IBM 704 emulator than on a hardware IBM 704. That's not an argument to keep writing apps for the IBM 704 and "just translate them".
> Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality.
Happens in literally every other programming industry though.
The reason this cannot happen in the games industry is that game developers are not good software developers. They are much more akin to physics-numerical-methods people who can write some magic spaghetti-Fortran that runs really fast and does black magic, but no one can maintain, debug or integrate.
For casual kids gaming, Apple TV and Apple Arcade is a fantastic combo. It's been plenty enough to keep my kid occupied, using hardware I already owned.
It streams videos. It works. I'd rather they don't mess with it.
However, the guy who decided to put a useless button on the side of the remote that interrupts whatever you're watching, should get fired immediately. It's almost every day I grab the remote and press it by accident, and have to switch back to what I was watching, and resume playback, because Netflix exits out of the stream.
Sadly, Apple TV is the only Hollywood-approved streaming device that isn't a total trash heap.
Bloomber's Odd Lots podcast had an episode on rope a little while ago, "How the Invention of Rope Gave Us Modern Civilization":
> Rope is easy to take for granted. It seems obvious and straightforward. But of course, it had to be invented. Early humans discovered that by twisting fibers around each other, the resulting structure would be something durable and strong. Without rope, all kinds of things aren't possible, from lifting objects into the air to whaling or modern bridges. So how was rope developed and what were the big breakthroughs in its history? On this episode, we speak with Tim Queeney, the author of 'Rope: How a Bundle of Twisted Fibers Became the Backbone of Civilization.' He walks us through the history of the technology, and its ongoing evolution, including how it might one day allow us to build elevators into outer space.
You're right. I'm glad the very next sentence in my comment landed.
The problem with turning it off is that the system and applications have been architected assuming that it will be on, so things like fork/execing a memory heavy processes or allocating memory inside a cgroup (which still pretends overcommit is enabled and there's still no way to disable that assumption) that used to work fine might break with no good way to get them to work again. This comment (and siblings) have more specifics: https://news.ycombinator.com/item?id=27794237#27795199
> Whether it is called “Department of War” or “Department of Defense”, it’s still the same organization maintaining the same mission operating under the same budget.
The mission of the Department of War, which was its name pre-WW2, and the mission of the Department of Defence (post-WW2) is completely different: this is evidenced by the number of military personnel in the two time periods (and the draw-down in personal post-1990, after the Cold War ended):
How's the support for X.509 "Name Constraints" these days:
* https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Would restricting it to only dot-ir domains be a mitigation?
* https://en.wikipedia.org/wiki/.ir
reply