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
37735 readers
49 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
Full disclosure, I work for MSFT, but I do not speak for them. I fucking hate python and am forced to write it a lot while working here, but I want to suggest there's a complementary technological reason for wanting to run it in the cloud. This isn't to say that MSFT will stand to make more money if you are using their cloud services, and I don't have any insight at all into the "gib us money plz" side of this business.
The reason: One of the biggest headaches for IT depts has been attack vectors through office productivity suites. Download a sketchy excel spreadsheet from someone, and suddenly custom macros are purposefully creating avenues for attack, or are attacks themselves. Ken and Debra in accounting aren't security people. They got a spreadsheet from an email that seems superficially plausible, so they pop it open. Suddenly, your entire org is ransomwared just because two people who are just doing their normal duties get tricked.
That's why the ol' VBA shit and all those fancy macro systems from the past got neutered. Sandboxed and isolated, removed entirely, whatever. But a good feature gets lost.
Enter The Cloud, or in other terms, "Someone Else's Computer". As in, someone else's computer out there, far from your corporate network, that has no ability to reach back through your security perimeter and have a rummage around your business guts. The worst thing that will happen is the attack-vector-spreadsheet, itself, might be compromised. Or Microsoft's cloud computers, which are, again, not your computers.
Anyway, that's honestly a great reason for it. And there's also the business cat reasons, which I don't like in principle; I always begrudge businesses their attempts at squeezing us for more and more every single fucking day. So anyway, it probably isn't worth it to the average home user, but IT departments are going to be thrilled, even if the tech budget is going to get even fatter paying for all these users using someone else's computer.
I have strong opinions about home users who can write Python already but choose to use excel, but I'll keep them to myself. They're elitist and basically just me being a little shit, so... you do you, boo.
Actually, I believe you just need to root out the networking and disk access then 90% of the attack surface vanished. At least it will not be persistant.
But they house my information, and goodness knows Microsoft will not compensate me when my information gets leaked through no fault of mine.
No cloud, no how. Keep it local.
If you read the release, each spreadsheet gets to run in it's own isolated container in a hypervisor system. You literally have separation of information at the file level, which is good. But I absolutely agree with you that if you store things in the cloud, you don't own those things, you give them away and lease that access back under restrictive terms. I don't find it to be worth it, but countless other people disagree with me.
If I'm to get on my soapbox after all, I'll just say this: Use json or jsonl, use polars, use jupyter and seaborn/matplotlib-pyplot, keep your data lolcat, and never open Excel again.
Edit: unless someone sends you an xslx and you need to convert it to csv before you transform it to jsonl. If someone has a cli that'll turn xslx -> jsonl directly I'd be so happy.
Works for Microsoft and hates Python. Checks out at least.
IMHO opinions (read: “hard takes”) on popular and useful programming languages doesn’t have to be part of any disclosure, it just creates unnecessary drama.
At the end of the day programming languages are tools, and Python is a good tool. Part hammer, part Swiss Army knife.
Sure, you can grab your compressor, a hose and a nail gun, but the fact is that with Python I can process CSV documents that excel struggle to open in less time than it will take most people to setup a new project in Visual Studio.
I fully agree that running stuff in the cloud may be good for security, but it will probably also open the door for a number of security holes that may or may not be exploited before being patched.
Giving full access to random scripts on random people’s computers is begging for problems.
Sandboxing only works until there’s an escape. But IMO that should have been the target. Proper ground up sandboxing.
On the other hand - how on earth do you make sure that it’s escape proof? I certainly wouldn’t carry that responsibility.
If it’s Python or something else doesn’t matter, but Python certainly carries a lot of the “accessibility” that VB did way back when they made VBA.
Will be interesting to see what people make of it. And if they’ve managed to make the programming interfaces better than during the VBA era.
I feel like you think you're talking to a different person than I am. My work computer is a linux box, my work IDE is either Jetbrains CLion or Pycharm, and my 40-hour-a-week-job is writing open source software that I release on behalf of Microsoft. So, yanno, if you want python libraries for graph spectral embeddings or approximate nearest neighbor algorithms, that's me.
The only thing I know about Visual Studio is it is distinctly not built for me, and I don't use it. I wouldn't know the first thing about creating a project in Visual Studio, because in the last 7 years I haven't created a single one in it. Gradle and Kotlin or SBT and Scala, sure. Python and pip, sure.
My problem with Python has nothing to do with the language itself. It has to do with the packaging. Remember that bit about me releasing open source software for Microsoft? Yeah. I'm stuck doing a lot of the packaging.
Friends don't let friends use Python, because then they're complicit in the frankly inhumane conditions in the pypa pit of eternal despair. Hug your numpy packager today!
If I misunderstood it’s probably because of the way you represented yourself.
Python packaging sucks, definitely, but saying you hate Python because packaging sucks (and you do it a lot) is bit like saying you hate the US because US immigration sucks (and you travel through immigration a lot).
Sure, you could hold the opinion, but I think most people would differentiate between the two positions.
However, kudos for working on OS! I’d give you a hug if I could!
I've tried the EAP CLion before for a while. Are the suggestions as good as IDEA's? Last time I tried it was average and just on par with clangd.
As someone has noted above the API doesn't have disk access.
I wonder if the model is "all data you want to process on has to already be in the sheets" or something?
See, I kind of see all this, but they control the OS, all the enterprise policy tools, and the software. They could very easily facilitate IT locking execution to the cloud (or custom environments) for their domains without ridiculously limiting people who know what they're doing and want tools that aren't dogshit.
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.