110
Microsoft announces Python formulas in Excel... which have to get sent to the cloud
(techcommunity.microsoft.com)
this post was submitted on 23 Aug 2023
110 points (100.0% liked)
Technology
37713 readers
337 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I sometimes question whether it's as easy as we think; surely they'd be able to have done the same for vba scripts, but instead they just yanked the whole dang thing. I don't know enough of Windows to have any idea tbh.
I just don't see it. They control the whole stack and permissions structure from top to bottom. If they wanted IT to authorize every module you import (to limit low level access), they could do it. If they wanted to allow IT to host their own cloud with whatever constraints they want, they could do it.
This is to increase reliance on their cloud. I don't see any other explanation.
I think it's easier and less risky to bank on a whole-ass isolated OS than it is to bank on making sure you have perfect coverage and mitigations in place for every possible module that ships with conda (not miniconda). But honestly, they could just require that Hyper-V is allowed if you want Python in Excel and offload it into a tiny little excel-hypervisor-daemon, same as they're doing in the cloud.
Ultimately, it's all just us reading tea leaves tho. I don't feel super strongly about any of the hypothetical motives talked about in this thread - not even my own. They're all possible, and reasonable people would make different decisions based on their priorities, and we don't even know what the priorities were of the team that decided to ship this. I mean, obviously they want to make money; but making money can be done by asking your customers to pony up more, or it can be done by having a strong degree of confidence that you won't get your ass handed to you when an xslx doesn't tap into cortana tts and try to extend your car's warranty or whatever. Maybe it's both. Maybe they want to start shipping Python with Windows but it isn't ready yet, so they're doing this Up There for a bit first. Or none of these. My goal in my initial response was just to say "it could be this too", in reference to the "there is no possible other explanation". There is a possible explanation. Heck, I gave you two new ones in this response alone! I only submit it as an entrant, not necessarily as the frontrunner.
Giving organizational policy administrators control over execution doesn't preclude using the cloud as your primary or strongest security model.
It's sincerely not difficult to allow the organization to literally sign the executable of the interpreter they want to use, to explicitly enable or disable specific modules from base Python, to enable specific external libraries by ID through Conda or by signing them with their own keys, or to pass the scripts to their own signed server for execution with any mitigations they want. They wouldn't be assuming any liability or even bad will if a company's IT fucked it up and left an attack vector exposed.
There is not a good faith explanation for forcing execution to the cloud. It only protects against bad configuration, at the cost of a hell of a lot of capability to a competent organization. Defaults are way more than enough to mitigate any exposure for Microsoft. Not providing the right way to do it as an option is all about control.