Since its inception, Microsoft Excel has changed how people organize, analyze, and visualize their data, providing a basis for decision-making for the flying billionaires heads up in the clouds who don’t give a fuck for life offtheline

  • dax@beehaw.org
    link
    fedilink
    arrow-up
    3
    ·
    10 months ago

    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.

    • conciselyverbose@kbin.social
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      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.

      • dax@beehaw.org
        link
        fedilink
        arrow-up
        4
        ·
        10 months ago

        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.

        • conciselyverbose@kbin.social
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          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.