Microsoft terminates VeraCrypt account, halting Windows updates
404media.co
404media.co
A couple of months ago I needed to renew the certificate because it expired, and I ran into the same issue as the author here - verification failed, and they refused to accept any documentation I would give them. Very frustrating experience, especially since there no human support available at all, for a product I was willing to pay and use!
We ended up getting our certificate sourced from https://signpath.org and have been grateful to them ever since.
My completely uninformed guess was that someone had done something naughty with Trusted Signing-issued code signing certificates.
Anyway, when I first saw the VeraCrypt thing this morning my initial reaction was “I wonder if this is them pushing developers onto trusted signing the hard way?”
So I can see why offering trusted signing for individuals worldwide would come with certain challenges.
[1] https://shop.certum.eu/open-source-code-signing.html
[2] https://comodosslstore.com/code-signing/comodo-individual-co...
You also have the verification happening in the right place. The person who maintains the Arch curl package knows where they got it and what changes they made to it. Some central signing authority knows what, that the Arch guy sent them some code they don't have the resources to audit? But then you have two different ways to get pwned, because you get signed malicious code if a compromised maintainer sends it to the central authority be signed or if the central authority gets compromised and signs whatever they want.
The downside to a centralized authority is that they're a single point of failure. PKIs like the Web PKI mediate this by having multiple central authorities (each issuing CA) and forcing them to engage in cryptographically verifiable audibility schemes that keep them honest (certificate transparency).
It's worth noting that the kind of "small trusted keyring" topology used by Debian, Arch, etc. is a form of centralized signing. It's just an ad-hoc one.
So the apt binary on your system comes with the public keys of the Debian packagers and then verifies that packages are signed by them, or by someone else whose keys you've chosen to add for a third party repository. They are the pre-established root of trust. What is obtained by further centralization? It's just useless indirection; all they can do is certify the packages the Debian maintainers submit, which is the same thing that happens when they sign them directly and include their own keys with the package management system instead of the central authority's, except that now there isn't a central authority to compromise everyone at once or otherwise introduce additional complexity and attack surface.
> PKIs like the Web PKI mediate this by having multiple central authorities (each issuing CA) and forcing them to engage in cryptographically verifiable audibility schemes that keep them honest (certificate transparency).
Web PKI is the worst of both worlds omnishambles. You have multiple independent single points of failure. Compromising any of them allows you to sign anything. Its only redeeming quality is that the CAs have to compete with each other and CAA records nominally allow you to exclude CAs you don't use from issuing certificates for your own domain, but end users can't exclude CAs they don't trust themselves, most domain owners don't even use CAA records and a compromised CA could ignore the CAA record and issue a certificate for any domain regardless.
> It's worth noting that the kind of "small trusted keyring" topology used by Debian, Arch, etc. is a form of centralized signing. It's just an ad-hoc one.
Only it isn't really centralized at all. Each package manager uses its own independent root of trust. The user can not only choose a distribution (apt signed by Debian vs. apt signed by Ubuntu), they can use different package management systems on the same distribution (apt, flatpak, snap, etc.) and can add third party repositories with their own signing keys. One user can use the amdgpu driver which is signed by their distribution and not trust the ones distributed directly by AMD, another can add the vendor's third party repository to get the bleeding edge ones.
This works extremely well. There are plenty of large trustworthy repositories like the official ones of the major distributions for grandma to feel safe in using, but no one is required to trust any specific one nor are people who know what they're doing or have a higher risk tolerance inhibited from using alternate sources or experimental software.
Nothing, I can’t think of a reason why you would want to centralize further. But that doesn’t mean it isn’t already centralized; the fact that every Debian ISO comes with the keyring baked into it demonstrates the value of centralization.
> Each package manager uses its own independent root of trust.
Yes, each is an independent PKI, each of which is independently centralized. Centralization doesn’t mean one authority; it’s just the way you distribute trust, and it’s the natural (and arguably only meaningful) way to distribute trust in a single-source packaging ecosystem like most Linux distros have.
That literally is what centralization means:
> cen·tral·i·zation: the concentration of control of an activity or organization under a single authority.
I mean people try to motte and bailey this all the time. You have someone proposing or defending a monopoly by putting it up against the false dichotomy alternative where no party trusts any other party whatsoever and then everyone is required to do everything on their own because no delegation is possible.
There is an alternate which is neither of those things, and it's a competitive market. You have neither a single authority nor the total absence of trust. Instead there are numerous alternatives that each try to maintain a good reputation for themselves because people can choose freely among them without their choice being coerced by tying it to numerous otherwise-unrelated factors.
Notice how this is importantly different. If you have a PC, you can install Debian or Arch or Windows; if you install Debian, you can install software with apt or flatpak or snap; if you use apt, you can use the official repositories or numerous third party ones. If you have an iPhone, you get iOS and you get Apple's store and everything else is anti-competitively excluded.
My point was that Debian, etc. as conceptually distinct organizations, and so there’s no point in centralizing beyond their organizational boundaries. Each already performs centralized key management, but nobody would particularly benefit from a single global keyring for all Linux distributions, because nobody (?) is transferring package formats across distribution families.
It would be the most corrupt(ible) org ever involved in open source and it would promote locked-down computing, as that would be their main reason to exist. Be careful what you wish for!
My second argument stands.
This is what the Digital Markets Act is supposed to protect developers against. Have there been any news regarding EU's investigation into Apple? Last I remember they were still reviewing their signing & fee-collection scheme.
> Without access to the Microsoft account used for sending software updates, “I will not be able to apply the required new signature to VeraCrypt, making it impossible to boot.”
So yes there is.
(there is probably a third, fourth, fifth option but this is an internet comment section)
https://community.osr.com/t/locked-out-of-microsoft-partner-...
> According to a post on Hacker News, the popular VPN client WireGuard is facing the same issue.
Microsoft is building things on top of it:
https://learn.microsoft.com/en-us/azure/aks/container-networ...
The entire Trusted Computing initiative had exactly one benefactor, and it was people looking to constrain what you did on your own machine. Y'all just set up your "End-of-Analysis" goalposts too early, and blinded yourselves to the maliciousness bundled in silver tongued beneficent intentions.
We'd be better off as a society all recognizing the inherent risk of computation than lulling people into a habit of "trust us bro" espoused by platform providers. Anyone trying to sell Trust is someone you can't afford to be trusting of.
I'll live with the threat of rootkits if it means no one can pull this kind of shit.
1. A customer wants to run their own firmware, or
2. Someone malicious close to the customer, an angry ex, tampers with their device, and uses the lack of Secure Boot to modify the OS to hide all trace of a tracker's existence, or
3. A malicious piece of firmware uses the lack of Secure Boot to modify the boot partition to ensure the malware loads before the OS, thereby permanently disabling all ability for the system to repair itself from within itself
Apple uses #2 and #3 in their own arguments. If your Mac gets hacked, that's bad. If your iPhone gets hacked, that's your life, and your precise location, at all times.
2. P(someone wants to run their own firmware) * P(this person is malicious) * P(this person implants this firmware on someone else’s computer)
3. The firmware doesn’t install itself
Yeah I think 2 and 3 is vastly less likely and strictly lower than 1.
#2 is WAY more likely than #1. And that's on Android which still has some protections even with a sideloaded APK (deeply nested, but still detectable if you look at the right settings panels).
As for #3; the point is that it's a virus. You start with a webkit bug, you get into kernel from there (sometimes happens); but this time, instead of a software update fixing it, your device is owned forever. Literally cannot be trusted again without a full DFU wipe.
> You don’t need firmware access to install malware on Android, so how many of stalkerware victims actually would have been saved by a locked bootloader?
With a locked bootloader, the underlying OS is intact, meaning that the privileges of the spyware (if you look in the right settings panel) can easily be detected, revoked, and removed. If the OS could be tampered with, you bet your wallet the spyware would immediately patch the settings system, and the OS as a whole, to hide all traces.
If someone brought me a device they suspected was compromised and it had an unlocked bootloader and they didn't know what an unlocked bootloader, custom ROM, or root was, I'd assume a high probability the OS is malicious.
Can you stop this bad faith bullshit please? "Stalkerware" is an app, not an alternate operating system, according to your own source. You're comparing the number of malicious app installs to the number of installs of a single 3rd party Android OS which is rather niche to begin with.
You don't need to install an alternate operating system to stalk someone. And in fact that's nearly impossible to do without the owner noticing because the act of unlocking the bootloader has always wiped the device.
> The Coalition Against Stalkerware defines stalkerware as software, made available directly to individuals, that enables a remote user to monitor the activities on another user’s device without that user’s consent and without explicit, persistent notification to that user in a manner that may facilitate intimate partner surveillance, harassment, abuse, stalking, and/or violence. Note: we do not consider the device user has given consent when apps merely require physical access to the device, unlocking the device, or logging in with the username and password in order to install the app.
> Some people refer to stalkerware as ‘spouseware’ or ‘creepware’, while the term stalkerware is also sometimes used colloquially to refer to any app or program that does or is perceived to invade one’s privacy; we believe a clear and narrow definition is important given stalkerware’s use in situations of intimate partner abuse. We also note that legitimate apps and other kinds of technology can and often do play a role in such situations.
Exactly, secure boot advocates once again completely miss that it doesn't protect against any real threat models.
P(robably not)
So, the first term in 1) and 2) are NOT the same, and it is quite conceivable that the probability of 2) is indeed higher than the one in 1) (which your pseudo-statistical argument aimed to refute, unsuccessfully).
(Even if, in some cases, it as just a custom-built SBC running BusyBox, customers still aren't going to go digging through a custom network stack).
Imagine any of your friends, family, or colleagues. (Including some non-programmers/hackers/embedded-engineers) What would their answers be?
Should either of those things happen the bootloader puts up a big bright flashing yellow warning screen saying "Someone hacked your device!"
I use a Pixel device and run GrapheneOS, the bootloader always pauses for ~5 seconds to warn me that the OS is not official.
Lol security people are out of their mind if they think that's actually a relevant concern.
> 3. A malicious piece of firmware uses the lack of Secure Boot to modify the boot partition to ensure the malware loads before the OS, thereby permanently disabling all ability for the system to repair itself from within itself
Oh no so now the malware can only permanently encrypt all the users files and permanently leak their secrets. But hey at least the user can repair the operating system instead of having to reinstall it. And in practice they can't even be sure about that because computers are simply too complex.
https://pip-assets.raspberrypi.com/categories/1214-rp2350/do...
https://documentation.espressif.com/esp32_technical_referenc...
And those markets are certainly not IoT gizmos, which I suspect induce some knee-jerk reactions and I understand that cause I'm a consumer too.
But big/serious customers actually look at the wealthiness of the company they buy from, and would certainly consider running their own firmware on someone else's product; they buy off-the-shelf products because it's not their domain of expertise (software development and/or whatever the device does), most of the times.
Some sandboxing and a little friction to reduce mistakes is usually wise, but a general-purpose computer that can't be broken through sufficiently determined misuse by its owner is broken as designed.
This isn't rocket science and it has nothing to do with artificially locking down a computer to serve the vendor instead of the owner.
Edit: I'd like to add that no amount of extra warranty from the vendors are going to cover the risk of a malware infection.
This is just another example of how secure boot provides zero additional security for the threat modes normal users face.
We need this law. Once we have this law, consumers csn get maximum benefit of secure boot withiut losing contorl
...it's already allowed. The problem is that this isn't the default, but opt in that you need quite a lot of knowledge to set up
If you install Windows first, Microsoft takes control (but it graciously allows Linux distros to use their key). If you install Linux first, you take control.
It's perfectly possible for you to maintain your own fully-secure trust chain, including a TPM setup which E.G. lets you keep a 4-digit pin while keeping your system secure against brute force attacks. You can't do that with the 1990s "encryption is all you need" style of system security.
The firmware of the device being a binary blob for the most part... Not like I trust it to begin with.
Whereas my open source Linux distribution requires me to disables SecureBoot.
What a world.
An unsigned hash is plenty guard to against tampering. The supply chain and any secret sauce that went into that firmware is just trust. Trust that the blob is well intentioned, trust that you downloaded from the right URL, checked the right SHA, trust that the organization running the URL is sanctioned to do so by Microsoft...
Once all of that trust for every piece of software is concentrated in one organization, Microsoft, Apple or Google, is has become totally meaningless.
There's also plenty of folks combining this with TPM and boot measurements.
The ugly part of SecureBoot is that all hardware comes with MS's keys, and lots of software assume that you'll want MS in charge of your hardware security, but SecureBoot _can_ be used to serve the user.
Obviously there's hardware that's the exception to this, and I totally share your dislike of it.
Right, but as engineers, we should resist the temptation to equate _possible_ with _practical_.
The mere fact that even the most business oriented Linux distributions have issues playing along SecureBoot is worrying. Essentially, SB has become a Windows only technology.
The promise of what SB could be useful for is even muddier. I would argue that the chances of being victim of firmware tampering are pretty thin compared to other attack vectors, yet somehow we end up all having SB and its most significant achievement is training people that disabling it is totally fine.
Device is bricked, firmware is secured with a signing key, refactoring a new device is pretty hard. The current one needed 10 years of development. I'm on the wait to either patch the firmware by finding the problematic byte (if it's patchable, round() needs much more), or to wait for the original dev willing to release an update on his own. BTW Claude opus got much better than ghidra lately. It's perfect.
I see the value of protected firmware updates, but business has to survive also.
At one time at our university we had table desktop dancers installed everywhere. Was kind of funny when it turned up just as a student wanted to defend their work in a lab.
Stallman tried to warn us with "tivoization".
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.
Same problem with age gating. It's fine, as long as zero additional demands are placed upon users.
We shouldn’t need the hassle of locks on our home and car doors, but we understand they are probably worthwhile for most people.
It's a decent one for "locks on an apartment building that someone else owns."
But no, purchasing a house ought not include by default "a set of locks that you must work around, permission-wise."
Y’know, for security.
And then, do computers.
Apples and oranges here, for this point.
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.
Users who don’t care about the runtime integrity of their machine can just turn it off.
Both options are so easy that you could’ve learned how to do them on your machine in the time that you spent posting misinformation in this thread.
My mom uses Secure Boot with Windows and doesn't know or care that it's enabled at all.
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.
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.
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.
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.
Backdooring your kernel is much, much more difficult to recover from than a typical user-mode malware infection.
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.
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.
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.
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.
An example of such an implementation, since well before TPMs were commonplace: https://www.recompile.se/mandos
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.
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.
[1] https://en.wikipedia.org/wiki/Viasat_hack
[2] https://www.telekom.com/de/blog/netz/artikel/lost-place-und-...
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.
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.
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
Plus they signed the shim loader for Linux anyways so they almost immediately gave up any "control" they might have had through SB.
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?
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.
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.
For home/business users I'd agree. But in Embedded / money-handling then it's a life-saver and a really important technology.
In this case, that's an OS controlled by an unaccountable company that can take application software away from you.
Related: If you're the customer, you're the product.
I'll tell Grandma that's what she needs to do.
In my limited experience with bitlocker, the disk is decryptable automatically as long as it's in the original motherboard.
Wat? Bitlocker is the answer to your question.
> In my limited experience with bitlocker, the disk is decryptable automatically as long as it's in the original motherboard.
It's unlocked (not decrypted) when the OS boots, yes. You can optionally enforce (not on Home) other unlock methods, such as PIN before the OS boots.
> I want my FDE to be based on a password or a keyfile, not simply by some code in the motherboard.
That's less secure than TPM.
If bitlocker has a PIN/passphrase decrypt option, then I missed it.
Furthermore it wasn't intuitive to me that my user account would decrypt more than just my home directory.
Now… maybe we could condense the 10,000 pointless distros down to a dozen? Oops, nope. Now 10,001, except this one has the menu bar in the middle of the screen and it moves around.
There needs to be some competition between ideas, but if every bit of disagreement about direction ends in "I'm going to build my own distro, with blackjack and hookers", then we as a community won't ever end up building something that can compete with the megacorps.
It takes leaders. And people with vision. It seems the lack is there, and not at technical makers.
But I still like it for containers, and I hope they can figure out a way to get it fixed for VC and WireGuard or they can figure out alternate signing options and a migration path.
Using arbiter platforms like this sounds like a great way to footgun yourself.
See Notepad++ for how that winds up.
Using Azure Trusted Signing or any other certificate vendor does not guarantee that a binary is 100% trustworthy, it just means someone put their name on it.
i dont think its fair to conflate the tech industries self-owns with microsofts damages. microsoft has for decades poured untold resources and money into capturing everything they possibly could to sustain themselves with honestly what i call cultural and software vendor lock. we're only just now seeing the gaming industry take its first real footsteps towards non-windows targets, but for the most part the decades of evangelizing Microsoft apis and bankrolling schools and education systems to carry courses for their way of doing things makes that a particularly uphill battle thats going to take a lot more time. people have built entire careers out of the microsoft-way in multiple industries. pure microsoft houses are still everywhere at many orgs, so many of them don't even recognize that there is another path. there's plenty of infra/dbadmin/devops people who are just pure windows still. there's multiple points where microsoft did have the best in class solution for something, but these days you'd be hard pressed to not go another way if you were starting from scratch. problem is such a lift and shift is really hard to do for orgs that have spent decades being a microsoft shop.
in a roundabout way, this sort of translates to real long lasting impact/damage to me. microsoft has always been such a force over history that it caused a massive rift in computing. no matter how much they embrace linux and claim to not fight the uphill battle of open source anymore, that modus operandi of locking people into their suite of things still exists on so many fronts and is in some ways more in your face than it's ever been. there's no benefit of the doubt to give here, i just have a hard time choosing microsoft for... well anything.
Explanation: Microslop is a power hungry, greedy and frankly evil corporation whose only goal is complete financial domination of the government, business, and personal tech industries. They actively promote making regressive software, increasing complexity, and hiding straightforward processes behind an information veil.
Example: Go to learn.microsoft.com and try to actually learn HOW to do anything. You'll read 35 pages of text talking about the concept of working with a specific microslop product but not 1 single explicit example of HOW to accomplish a specific task.
Example: Windows 11
Example: Copilot
The whole company is run by backassward tech hicks and digital yokels who can't think past a dime on the floor for a dollar in customer satisfaction, and somehow they run the majority of non-server space or personal device tech on the planet.
And of course companies in the US are wanting to make money/capture markets. They’re not a charity. None of that has any relation to holding back the industry. Unless you wish to explain how they hold back all FOSS projects.
You don’t need to be rude in your replies. This is HN, not reddit.
currently have a 32bit win xp env spun up in 86box just to compile a project in some omega old visual studio dotnet 7 and the service pack update at the time (don't ask). it is seriously _wild_ being in there, feels like stepping into a time machine. nostalgia aside, the OS is for the most part... quiet. doesn't bother you, everything is kind of exactly where you expect it to be, no noise in my start menu, there isnt some omega bing network callstack in my explorer, no prompts to o365 my life up.
it feels kinda sad, what an era that was. it's just more annoying to do any meaningful work in windows these days.
im currently working with c/cpp the idiot way (nothing about my story is ever conventional sigh), by picking a legacy project from like 22 years ago. this has forced me to step back into old redhat 7.1+icc5, old windows xp + dotnet7 like i explained above, and im definitely taking the most unpragmatic approach ever diving in here.. but there's one thing that absolutely sticks out to me: microsoft has always tried to capitalize on everything. tool? money. vendor lock. os? money. vendor lock. entire industries/education system capture? lotta money. lotta vendor lock. lotta generational knowledge lock.
they are lucky people are still using github. theyve tried to poke the bear a few times and theyre slowly but surely enshittifying the place, but im just kinda losing any reverence for microsoft altogether. microsoft has been big for a hot minute now, they have their eras. you can feel when things are driven by smart visionary engineers working behind the scenes, and you can tell when things are in pure slop mode microservice get rich or die trying mode. yea, microsoft has.. always been vendor-lock aggro and kinda hostile, but the current era microsoft is by far the grossest it's ever been. see: microsoft teams (inb4 "i use teams every day, i dont have a problem with it")
im aware people smarter than me can write diatribes on why windows is the best at x thing, but im only informed by my own experience of having to use all three (linux/macos/windows) for my professional work life: i grew up thinking windows was the best.. now im like mostly confident that windows is actually the worst lol. by a pretty damn decent margin. i was gaslit for ages
I run Crossover and I feel like I gotta take a shower after. Just knowing there's a folder called drive_c on my Mac is the stuff of nightmares.
Apple Mail and Apple Calendar are fine to replace Exchange, as is Thunderbird(see 1), but Mail is more turnkey (1-click pairs with MS Exchange)
You can downgrade your O365 licenses to Exchange Plan 1 and keep your email hosting at a tiny fraction of the price of full 365 suite.
(1): Beware thunderbird has an open and unsolved bug that randomly deletes all your emails, kind of like a 1d1 million dice roll.
what is apple doing that is similar?
Apple is holding the tech industry back by forbidding any browser on iOS except Safari and then refusing to implement any APIs that would allow web applications to compete with their app store. Apple is choosing profit over progress.