Microsoft specifically denies windows certification to any device that doesn't allow secure boot to be disabled and custom keys loaded, and they have since the release of Windows 8.1 (13 years ago). There's no Windows RT devices on sale, and even Microsoft's own first party Surface Pro Snapdragon devices give you, the user, complete control over secure boot process and custom key loading.

But if the best you can come up with is criticising a Windows version that flopped so badly it nearly took an entire idea of using arm as a desktop computer architecture with it, that was used by so few people that Microsoft abandoned ideas to develop an ARM based system for a full decade, then I'm sorry but you are advertising a huge win for Microsoft there.

Now, have you got anything to say that actually impacted users, preferably something from this decade?

Your lack of understanding doesn't make something bullshit.

You forgot one. I had root on your box. That made me an evil-maid, and you just said secure boot protects against that. There's a difference between malware at a point in time, and achieving residence. Maybe I don't want your shitty dick picks in your mounted volumes, maybe I'm after your bank account details. Oh I know how about a key logger. But what if you attempt to remove said key logger? Well we have the perfect solution, since you don't know about persistent malware and choose to leave secure boot disabled I now have fucked your system beyond your repair. We thankyou for your ignorance and lack of security.

Maybe you should look up the word "secure" in the dictionary. You just described data in its *most* secure state. Nothing is more secure than something inaccessible and unrecoverable. Even if your case were true (secure boot has zero to do with your data) the result would still be more secure not less secure.

At this point it's clear you don't even understand the basic terms being used in the discussion.

The question "who is responsible for accidents" here is no different from a thousand other "who is responsible" judgements. Unless you have some reason to think that a repaired John Deere tractor is more likely to cause accidents than a non-repaired one, this is just a distraction.

We have a legal system that addresses questions of who is responsible. If you don't like the way these decisions are made, you need to fix the legal system, because changing right-to-repair laws won't do beans to solve that problem.

You're speaking in circles. You remove all the things you claim you don't want and then you complain that there's nothing left and that you may as well run Linux? Please don't ever advertise for Linux anymore you make it sound horrible.

No it's a conspiracy theory. They admit to specific things, calling it "your data" is FUD. What is actually taken is known and agreed to in ToS, so not only is it not "your data" it's not "stealing".

They don't do anything by default. They force you into a choice screen which is not able to be bypassed by an X. And even if you blindly click okay because you don't want to read it backs up only specific folders on your computer, and does so with big bright green visible tickmarks leaving no doubt.

Yeah nah, no data is being stolen there. They aren't taking all your data, just a database of mistakes that are miscorrected. You can thank me for participating for your spellchecker working better than ever before.

I may have told you before you have no idea how security works, but in case you tried to educate yourself in the mean time you clearly failed. VeraCrypt addresses precisely zero, nada, NIL, none of the issues you list or complained about. It has no ability to hide any data from Microsoft what so ever other than the data that you never access.

Please get some help.

The em-dash is once again crying in the corner for not being invited to the party.

Congrats, you don't understand the basics of secure key exchange, but that's easy to fix: I suggest starting with the colour model for a basic understanding: https://www.arsouyes.org/artic... afterwards you can look into the details of how this works mathematically. No your key is *NEVER* sent anywhere. EVER. It's not required for key exchange.

There's nothing to reverse engineer. Encryption and security is based on well known public algorithms. These are designed to enable secret communication, that you can verify on a mathematical level. There's no reverse engineering anything, there's only breaking the key, and the key generation process relies on a the concept of mathematics that easily calculate but difficult to reverse. E.g. Discrete logarithm problems. Take M^b mod p = x. I could tell you M and p and x and you would still have no hope in hell of figuring out b.

Why post if you don't want to engage in a discussion?

If this is the kind of thing you normally post I don't have any idea why no one has called you deranged before.

Hardly. If the user has access to files then Microsoft does as well. That's the fundamental problem with this debate by multiple people here. If you can open a file then Microsoft has access to it. If you use VeraCrypt to secure your windows partition then Microsoft has access to all the files since you literally need to decrypt the partition to load the OS.

Tinfoil hats are not a nice fashion accessory.

You have clearly not enough knowledge and too much ignorance on the topic. No you don't need to disable secure boot. Microsoft has no control over secure boot. You can even load your own custom keys for the Windows boot process, to say nothing of Linux's secure boot process having zero to do with Microsoft control either.

But you don't care, you've been told this before. At this point you're willfully ignorant.

There is no way of querying secure boot or using it for DRM. All you can do I report if secure boot was on or off.

That could be as well, but we already had non-secure boot options for that.

See a) Saying something wrong twice doesn't make it right, it makes you twice as wrong.

Manufacturers have no control over secure boot. The implementation requires the keys be able to be managed by the user. You just jump into UEFI and delete Microsoft's key if you want and load your own. It's no more giving someone else control than a website that suggests a strong password.

No that's not, you missed what Secure boot does.

You actually said a few right things there. Yeah it has nothing to do with hardware attacks, it has to do with persistent attacks.

No. The assumption for any computer is that it boots into a known configuration. Persistent in this case means it is impossible to remove from the OS. At no point has the definition included your "nuke from orbit" approach.

Viruses can be removed and cleaned from machines. At least the ones which aren't following the correct definition of persistent. Damage in the modern definition is continuous and ongoing. Just because you've been infected at one point in time doesn't mean it's game over.

Yes I'm sure if you have no idea what you're talking about you'd think that. I agree with you by the way. Passwords do nothing so I just leave the field blank.

Except for sign the boot process to ensure no resident malware can persist through reboots. There's example of it by the way, this isn't theoretical, Bootkitty is bootlevel malware that is exactly the kind of thing Secure boot protects against.

You are technically correct. UEFI doesn't enhance anything, it doesn't force secure boot. Secureboot however objectively does enhance security, it's literally an open standard which puts encryption keys to validate the boot process in the hands of the user. MS has no stranglehold what so ever beyond making sure that unpermitted processes don't precede it in the boot chain, which is explicitly the boot time security hole being plugged.

You do the same thing in Linux, generate a keypair, sign the bootloader, and load the key into the UEFI to ensure no boot time attack creates resident malware.

There are examples of resident malware out there. This isn't theoretical (unlike Spectre type attacks).

You answered your own question. Here: "since having someone else hold the keys completely mitigates the value of secure boot". Microsoft can't certify the secure boot process isn't maintaining the integrity of the kernel if 3rd party software bootstraps Microsoft's own booting procedure.

This shows a fundamental failure of understanding of security principles. VeraCrypt encrypting the boot volume (the only thing that it would need a secure boot key for) in no way prevents Microsoft from doing what you're tinfoilhatting about as once VeraCrypt decrypts the boot volume Windows has full access to that volume anyway, and if you're concerned about non-boot volumes they blocking their secure boot key wouldn't have any impact on its use (I also use VeraCrypt).

Your conspiracy makes no sense and your mitigation (encrypt away from the OS) isn't even implicated by this secure boot discussion.

That's why I leave my password fields blank. It's so much easier to ignore security. (Also no Microsoft has no capability of preventing you booting Linux or using Linux with secure boot disabled, the only thing they have the ability to block is you booting Linux using Window's boot loader).

No, Microsoft issues secure boot keys that allow Linux to be booted by bootstrapping Microsoft's bootloader's shim. You don't need Microsoft to run secure boot in Linux, you just need to load your own key into the BIOS. SecureBoot is 100% under your control.

The problem here that sets VeraCrypt apart is that VeraCrypt after doing its thing needs to load Microsoft's Bootloader. This entire system is interlinked. The whole point of secureboot was that software doesn't fuck with the boot process without authorisation.

Microsoft has no control over what you do with Linux (unless you let it)
Microsoft has ALL control over what you do with attempts to boot Windows.