As someone who grew up near Redmond, who still has an emotional soft-spot for Microsoft for some reason, I feel truly embarrassed for their implementation.
All the efforts from other teams to have .NET reach Swift, Java, Kotlin levels of adoption on Windows, have always hit a wall against WinDev culture.
Also the 90's spirit from features over security hasn't yet gone away from WinDev, so it isn't really surprising this turned out this way.
We have seen some recent efforts, but how does one right such a large ship?
https://www.theregister.com/2024/06/14/brad_smith_microsoft_...
https://www.theverge.com/2024/4/3/24119787/microsoft-cloud-e...
They can figure this stuff out sometimes, right?
How did they get from Windows/AVG/ESET to Windows Defender, and how can they make that happen on Azure?
The difference with recall is about blast radius of any unauthorized/unintended access, which still happens even if it's less common or via something like clicking a bad link in an email. That's in addition to mistrust of MS or large corporations sucking up data, and how secure they are (what would a Ashley Madison type breach look like with recall data?)
However that was it, WinDev fought against Longhorn, Office folks redid the .NET ideas in COM for Vista, and so on.
For example, Kerberos support in Azure AD led to the some of the latest issues?
Most stuff is built with .NET, Go, Java and Rust, while the hypervisors are based on Windows (Azure Host OS[0]) it isn't the same as regular Windows, and most workloads are Linux based, officially > 60% [1].
Finally, starting this year, Azure has new security guidelines, all new software is to be written in managed languages, if a GC is not an impediment, Rust otherwise.
Writing code in either C or C++, is only allowed for existing products, with the related security guidelines in place[2].
[0] - https://techcommunity.microsoft.com/t5/windows-os-platform-b...
[1] - https://azure.microsoft.com/en-us/products/virtual-machines/...
I can't get over that little tidbit.
> Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected.
So the attackers found a valid private key for MSA (undetermined how, the theory was that it was scraped from a debug dump that was moved from high privilege prod to someone's low privilege shared drive). They then used that key to sign invalid tokens for AAD and the validating side incorrectly accepted those tokens. In this case, the validating side would be Exchange / OWA. Azure AD seems to not be implicated in the security issues, since it was MSA that leaked the key and OWA that failed to properly validate it.
That's my interpretation of the text anyway. It also aligns with my own understanding from a brief time at MS that Azure is much better at security than the rest of MS and that Exchange is a dumpster fire because of decades of cruft and evolution of systems.
This seems like the general attitude that delivers lackluster solutions across many products, like Teams, SharePoint, etc.
The critical blunder was in indexing that personal data by watching over your shoulder, which is both creepy and low-effort. They've got to put the work in to find a better way.
They invested a bunch of effort into a product the market loudly rejected.
They're now withdrawing the product while they figure out what they can salvage from the effort.
Key stakeholders may have a few ideas about how to proceed (ranging from "try again later" through "repurpose it" to "forget it"), but enterprises of Microsoft size make decisions very slowly so of course it's vague about what's next. Collectively, they almost certainly don't know!