"or wanders into a user's sensitive files."
WARNING: Windows is trying to access your files! You are recommended to block this action.
Microsoft is introducing a raft of Windows security features that users and administrators alike might assume are already part of the operating system. Dubbed "Windows Baseline Security Mode" and "User Transparency and Consent," the updates are intended to deal with suspect behavior behind the scenes while also prompting the …
You might joke but yonks ago i installed Skype and was quite horrified when i found it had accessed my outlook .pst file and hoovered up all the contacts in it and added them to Skype.
It did not ask before doing so. that was the day i stopped using outlook to store contacts.
I find it ironic that the mighty MS is suggesting it will protect us from things it has done before itself, and probably continues to do now.
It's what Apple added to Mac OS because when they've run out of ideas the only thing left is to make it more like iOS. I think Apple only managed to make it work because of the more organised home directory format, but even so it's just a pointless pain in the arse. I can't see this working at all in Windows with the amount of files thrown around everywhere.
"Apple only managed to make it work" for an independent freelance graphics designer who needs to confirm any system action 6 times and type the right password at least twice in the process. Unattended operations in a corporate setting are only possible - sometimes - with the help of companies like JAMF who need to be paid separately and keep chasing Apple's tail themselves all the time, not always successfully.
Cue cursing from sysadmins and CISOs who need to deploy/update en mass, aa well as from QA engineers (especially with cybersecurity vendors whose products need elevated permissions to do their job) who need to test, among other things, installs, upgrades, uninstalls, reinstalls, compare different versions to check for regressions, and can't automate it because Apple decided that a user must get a password prompt, twice, and grudgingly admit there is no programmatic way around it.
Frankly, I doubt that MSFT will manage to do something like this and keep their corporate customers happy, even with CrowdStrike's help.
This is because Apple has app sandboxing by default (the change that you are referring to is when this became the default in MacOS - having previously been the standard in iOS).
By default every app downloaded from the App Store launches in a private container. It is least privilege by default. By default, the app can only access its own container and declared (by the developer to Apple during app submission) resources - i.e. printer, or the network adapter. It can't break out of this container and access the file system, or RAM, etc.
Most importantly, no app can ever access the data from another container/app without user permission. This is why your Facebook app needs permissions to access the data contained within your Photos app. They are two completely separate containers, hence requiring user permission.
If you and the 23 other people who upvoted your comment still think this is a "pointless pain in the arse", you may want to consider an offline device, because whatever threat level exists in your head is about 30 years out of date.
p.s. Windows 11 also somewhat does this (not as common, not as secure, but a start...) - msix apps from the MS Store, for example, run in AppContainer.
"This means only properly signed apps, services, and drivers. However, users and administrators can still override the safeguards for that one weird legacy app, and app developers can check if the protections are active and if any exceptions have been granted."
I agree that a way of allowing granular access to whether or not software should be able to access the microphone and camera, should be present (and optional). However the above quote about "app signing" has me worried. How long will it be until they turn the screws some more and don't allow any unsigned software at all? Android is currently about to face this reality thanks to Google having complete control over the vast majority of the platform, and as a result a lot of software simply won't be able to run any more, or else it will be subject to restrictions put in place by Google.
I am not against the idea of software being able to be signed by the developer: rather, I worry that the signing keys, and ability to meaningfully distribute Windows software, will be locked behind an agreement dictated by Microsoft at some point.
They really are intent on making everyone move to Linux (or anything else BUT Windows).
Not even properly OV signed apps from independent developers can escape SmartScreen now (unless you are a corporation and can afford/get EV certs), and most AV software assumes anything writing to a sub-folder of Public Documents (a perfectly legit folder to hold read/write application data until the advent of ransomware) can only be malware trying to encrypt all your files, so it MUST be SILENTLY blocked without warning the user MUCH LESS giving him a choice (daddy knows best, and users are too stupid to know what they are doing anyway). The application being silently blocked will take the fall as being "buggy" anyway, so win-win for the AV companies.
So sick of this.
Microsslop will ramp up security even further by insisting your webcam is constantly enabled so that a secret security app that no one knows about but was installed by stealth in a future security update will act as a retina scanner. If you haven't been "scanned" then you can't use Windows. Password, passkeys will be a thing of the past. They will want your blood (literally) to use future Windows versions.
Why not design an OS that can't be hacked by opening an email attachment or clicking on a malicious URL? That way we wouldn't need such protections as:
Application Guard for Microsoft Edge
Attack Surface Reduction (ASR)
BitLocker
BitLocker secure-boot
Credential Guard
DNS-based protections
Encrypting File System (EFS)
Exploit protection, including DEP, ASLR, CFG and GPO.
Hypervisor-Enforced Code Integrity (HVCI)
Kernel-mode Code Integrity (KMCI)
Local Security Authority (LSA)
Microsoft Defender Antivirus
Microsoft Defender SmartScreen
Microsoft Defender’s cloud-delivered protection
Microsoft security
Network Access Protection
Ransomware protection
Rights Management
Secure Boot (UEFI)
Smart Card and FIDO2
System Guard
Trusted Platform Module (TPM) support
User Account Control (UAC)
Virtualization-Based Security (VBS)
Windows Defender Application Control (WDAC)
Windows Defender Firewall
Windows Hello
Windows Information Protections
I'm so fed up with pushing stupid changes on the guise of "security". this particular one will only result in more mindless clicks because users will confirm it either way...
but hey, we can say that we are "more secure", some stupid c-suite will get a bonus and the world will be a worst place in the end...
on the other hand microslop is first to force-fed it's shitty copilot, which is basically abomination if any security and privacy, because people send / upload there virtually anything... and there is no prompt...
What's wrong in per-app permission? It's the right way to ensure better security. It should be extended to system resources (CPU, memory, disk space and even directories, bandwidth, etc.)
If one set you are no longer "nagged" - and application can know what settings have been applied to them, that's a sensible design decision. That should have been taken earlier.
It may sound sensible but then reality is that each app naggs user for all required permissions, USRR accept everything without reading and then ia bombarded by (usually) notifications...
It's enough to take any phone of your (less technical) friends and are their notifications area... "why font you disable those, you just ignore them!?" ia usually followed by "I don't know why / I Don't care"
That should be done at setup time - add a button "enable all" if you wish, trying to counter user stupidity is useless. But at least skilled enough users can reduce the attack surface.
After all, is not much different than what AppArmor is trying to do under Linux - and I found it blocking Ceph from using some SSD disks because their /dev paths were not in the allowed list, finding it was a bit more difficult than flipping some switches in a GUI - or not lliking a database on a different mounted directory....
Anyway, if you want security without any effort, you don't get security, and then you get the effort to clean up the mess....
But of course whatever MS does is to blame per se.
If Micros~1 had provided a list of changes that are coming in a future release and provided a preview so app developers can change the installation process to include a list of permissions the app needs for a clearly stated purpose to allow the admin/user to deal with this at installation time (or first run of the app) that would be fine.
Microsoft's announcement linked in the article says:
"We recognize that change takes time. That’s why this will roll out through a phased approach guided by clear principles".
I fear they'll use an "agile process" to keep changing stuff forcing users and admins and app developers to play catch up and keep configuring permissions for applications even if they were in daily use for years.