@munin @cstross I trust you on this one. But unless you've got a bazillion dollers and a decade to spare suing MS.... ?

@falken @cstross

We don't have to sue microsoft.

We can invoke change by pointing out that this will directly impact the bottom line of their customer base, which will in turn result in an impact to their profits.

A few high value accounts telling their sales reps "we can't use your OS anymore for our workload because we won't be able to keep our compliance certs necessary to stay in business" has significant effect.

@munin @falken@qoto.org @cstross my university is fond of pointing out that we have a contractual “Business Associate Agreement” with Microsoft that prevents them from mining our HIPAA and export controlled data. No, i don’t know how they prove compliance.
I worry that for the high-value accounts they’ll provide opt-outs, while mining the “consumer” level systems. Thus it ever was under capitalism.

Btw, thank you for fighting for those who can’t. 🫡✊

@aizuchi @cstross

a significant issue is that, regardless of the ability to opt-out, if the code exists as a canonical part of the operating system then that means it is expected to be available -to- the OS.

This has systemic effects, which I allude to here - https://infosec.exchange/@munin/112480592607154358

@munin @cstross 100%. The principle of least privilege implies if you don’t use screen scraping, don’t have it installed. How many unintentional back doors have been enabled over the years by having code on systems that didn’t need it?!?
I’m looking at you, libtiff.dll or whatever you’re called nowadays

@aizuchi @cstross

It's worth noting specifically that, in the ongoing issue of ransomware, the standard workflow is to use OS-internal encryption libraries as the 'moving part' of the attack.

This is because third-party encryption tools are -very- easy to detect behaviorally, but the built-in ones have legitimate uses within legitimate workflows - so discerning between a 'legal' and an 'illegal' invocation of those functions is -way- the fuck harder and you end up having to do a bunch of process provenance bullshit to get behavioral detections working.

Yes, this is something that I've been very recently working on and it sucks unventilated donkey ass.

So beyond the principle of least privilege in operations, it becomes an issue of how you manage the system design generally - if you are enabling a given workflow, what does that workflow, in turn, enable? How does it interact with other system controls?

My personal stance has been that designing a system to encourage the 'safe' workflow, while making the unsafe/undesirable ones stand out as obviously divergent from the 'safe' baseline, is necessary for infosec defense generally. Make your systems such that the -attacker- workflow stands out as obviously transgressive, and - mirabile motherfuckin' dictu! - it becomes possible -to- discern attacks from authorized uses.

However, trying to educate people about this in the face of the learned-helpelessness that defensive infosec has generally is....a challenge.