Microsoft is still planning to block Visual Basic for Applications (VBA) macros by default in Office apps. The software giant rolled back planned changes last week, surprising IT admins who had been preparing for Microsoft to prevent Office users from easily enabling macros in Office files downloaded from the internet. The change, designed to improve security in Office, was supposed to go live in June before Microsoft suddenly reverted the block on June 30th.
“Following user feedback, we have rolled back this change temporarily while we make some additional changes to enhance usability,” explains Kellie Eickmeyer, principal product manager at Microsoft, in a blog post update. “This is a temporary change, and we are fully committed to making the default change for all users.”
It seems bonkers that in this day and age VBA macros are still a thing, but I guess the business world is quite dependent on them.
Is it so hard to have a checkbox called “can has macros please?” or similar? I never understood the all-or-nothing approach of the “enable editing” button, where if you want to fix a single spelling error you also have to run the macros.
It’s great that you read the article and aren’t just posting stuff out of your ass.
Thom Holwerda,
The benefits of automation should be obvious to anyone who’s had to do the same thing manually over and over again! I understand that some people don’t use them, and perhaps they should be disabled by default. I think it’s overly dramatic to call it “bonkers” though. VBA scripts are incredibly useful for relatively quick and easy automation that is extremely difficult to replicate using external tooling. And having this automation (especially in excel) can make the difference between getting something done at the click of a button and having to hire/train employees to do it by hand week after week.
Obviously you don’t want users running malicious code. I think automation is still an excellent concept, but in retrospect it was probably a bad idea to embed the scripts inside the exact same data files that users end up emailling to one another. In other words, XLS should only contain data and never executable code. Executable code should be in separate code files that users would have to install separately if and when they need to. This would have made it far easier for everyone including home users and system admins to follow and enforce safe practices transferring documents while keeping a mechanism for the automation.
I dunno. VBA scripts and worksheet contents are often tightly linked. Having users run random scripts on their worksheets isn’t fun either — and don’t forget the increase in support calls because they cannot find their files / scripts.
VBA offers a lot of functionality and was a mayor selling point for some firms I’ve worked with. Also there were COM add-ins in the past, going even further.
Of course functionality comes with risks – that’s a general rule. Life itself is very functional, and deadly. Finding a balance is hard. Maybe each and every office file should ask (one time) for permissions like on Android; can I have filesystem access? Most VBA macro’s don’t need filesystem access. And so on.
Or a PKI infra could be created where the owner of the private key can determine the execution rights of the signed VBA script.
evert,
I agree data and code can be tightly linked, however I’m not sure distributing executable code inside of data documents was ever all that important for the pro-automation people including myself.
I actually think it would be easier for an organization to push/synchronous scripts if they were NOT inside of the spreadsheets. Separating code makes it easier for system administrators to push down code & keep it synchronized throughout an organization. For users who are developing their own scripts, IMHO they should be knowledgeable enough to figure it out where to keep them. Frankly users who cannot figure it out are unlikely to have the skills necessary to write their own scripts.
I concede there are pros and cons, but in this particular case since separating the code and data will drastically decrease the risks of exchanging/opening document files without creating a large burden for automation. that gets my vote. I don’t want to be reliant on error prone AV technhology to scan for documents containing malware. Keeping code and data separate solves the “beware malicious office files” problem since the data files would not contain code by design.
That would introducing a ton of complexity without much gain IMHO. The “Do you trust XYZ? YES/NO” “don’t ask me again” Isn’t my idea of a good security model. That’s how active-x worked and I for one hated it, It was an all or nothing trust model that blindly asked users for permission when they had no reasonable way to know whether an active-x control was safe or not.
I agree that separation of data and code is, in principle, good. But those Excel files tend to be emailed, copied to computers at home and laptops…. I rather not be the sysadmin that has to deal with support calls from people who don’t understand why they get a “script not found” error. Of course those scripts can be placed on a public webserver but that creates other problems. Good point though on AV scanning…. indeed a problem. Maybe a centralized server could do a more reliable job in that regard.
Anyway those Excel files still ask for code to be executed, even when the code is somewhere else. It needs permission to do so. That’s why I mentioned the permission model of Android. Normally, VBA code doesn’t need filesystem access. But those pesky security questions are a nuisance indeed, even more so for PKI; I agree to your objections. Still you can limit those questions, e.g. only ask permission when the script wants to initiate unusual actions external to the worksheet.
Probably there is no golden scenario here.
evert,
Yes but at the same time large enterprise environments have solutions for that. IT could push the scripts to all members of an active directory group automatically as soon as they log in whether it is dozens or thousands of users without much fuss. It was along these lines I was thinking when I suggested that separating code makes it much easier to automate deployment to a massive user base. When the code is trapped inside of documents on network shares/local disks/thumb drives/email/teams/etc I think it makes it even harder to deploy and update scripts across many users.
I am in favor of sandboxing too and don’t object to that being the default. It doesn’t have to be perfect for everyone, as long as advanced users can override settings with group policy that ought to be good enough IMHO.
Not only that. You can also add useful functions to your spreadsheet
That’s the sane approach to it. I mean, we have browsers asking for permission to use location, microphone, camera and the like (so far so good), but when it comes to macros and Microsoft Office, Microsoft Office is like “Run all the macros right away! You only live once!” despite the fact macros can do actual damage.
My guess is that the relevant code is in the parts of Microsoft Office source code that nobody in Microsoft understands anymore, and as a result, nobody dares touch out of fear of breaking something. Hence the cop-out solution of disabling editing altogether, which basically disables a large part of Microsoft Office. And don’t get me started with the lack of a proper sandbox. Again, this has the whiff of code that was written in the 90s and never touched since.
I disagree with the idea macros should be a separate code file though. Do you expect users to correctly match code files to documents?
kurkosdr,
I suspect there’s a lot of truth to that, haha.
No, but I don’t think it’s that hard a problem to solve either. It would have been solved a long time ago if the decision had been made to keep code and data seperate in the first place. Just as an example you could have data tags provide connection points similarly to the way 3rd party javascripts on CDNs use “getElementsByClassName” or “getElementsByTagName” to interact with documents that have no inline code connections.
I think it’s one of those things that people will complain about now because it already works one way, but had it been done another way from the start then people wouldn’t complain because they’d already be used to it. And to be fair there is something to say about keeping things the way they are because people are already used to it.
I don’t see how this could help though. If the file refers to the code file, it can still run the code as if it were inline. What Microsoft Office needs is sandboxing (it’s a document macro for ffs) or an ability to disable macros but keep all the other functionality. But I wouldn’t hold my breath for it.
kurkosdr,
Think of an XML file. One can write and/or install a script to do something with your data but the XML file itself doesn’t contain arbitrary code. If the user HAS in fact installed arbitrary code on their system then it needs to be understood that the code they install could be malicious or vulnerable. Standard security practices should apply to the code just as with all executable software. However in the same way that an XML file is just an XML file, I think a spreadsheet should just be a spreadsheet with no code.
Sandboxing is important too. But people can be tricked into clicking yes because they’ve done it hundreds of thousands of times before out of habit, even informed users can be tricked and not notice a changed character in an email address, etc. So I still think it’s dangerous that documents types that are routinely emailed every day may potentially contain malicious code. Contrast this to installing an automation script: 1) it is a relatively rare event, 2) the barriers to accidental installation are higher, 3) it is more likely to be done by a competent administrator. So I think it’s easier to make users safer by keeping code and data separate while still providing an avenue for automation.
Anyways I do agree with you it’s unlikely to change now.
@Alfman
Surely Thom’s comment is clickbait, how could any proponent of the Linux GUI, and it’s various Word Processors or Spreadsheet solutions, be seriously questioning the utility of macros regardless of what basic scripting language they make use of?
How is LibreOffice Basic somehow superior to Visual Basic, can someone answer this with a straight face?
Almost never have any need for macros. But when I need to use them, my god are they useful.
if they do the job, they are not bonkers. doesn’t matter how old the technology is.
[quote]
“It seems bonkers that in this day and age VBA macros are still a thing, but I guess the business world is quite dependent on them.”[/quote]
Makros are very useful in daily office life. They are not bonkers at all.
The problem here is that MS thought is would be a good idea to classify ALL network connections unreliable, which includes shared drives via NAS … and of course excluding MS Onedrive from that rule. So MS was trying to push users to use MS cloud services instead of self hosted ones…
Sadly they are still trying to do that … just little bit later.
cybergorf,
Can you elaborate what you mean by this? I have noticed that NAS got harder between different versions of windows/SMB, but they work with my linux samba shares so I haven’t been terribly affected (at least not yet).
One of my major gripes with both IOS and android has been the inability to access my files without some stupid dependency on 3rd party services that I don’t want and wouldn’t otherwise need. The lack of native support for file shares is a major con of these mobile platforms that has persisted to this day. I think the motivation for the lack of such services was to push users onto centralized services from the start and making self hosting extremely impractical.
I know microsoft is forcing windows users to create microsoft accounts for local login with new installs, but I’m curious, are there more networking policies that go beyond this? What are they?
You got somehow lucky there … in our case:
SMB shares via Sinology NAS (Linux based) and Office395. After the now rolled back changes one could no longer manipulate files with macros on such shares, but you would need to copy them on your computer first and open from there (and save them back eventually).
And yes: Android and iOS are even worse here. There are good 3rd party Apps like “FE File Explorer” that work for both systems, but as you say: PITA
cybergorf,
Oh, that explains it, I don’t use ms office any more, not for a long time.
Actually now that you mention it we used to be able to run installers and even full applications directly from mapped shares, which functioned identically to local drives. I think it was with windows 7 (?) microsoft disabled that forcing files to be copied locally. I guess it could be related to what you are seeing.
Yeah it is. Accessing LAN shares shouldn’t be so difficult. The need to copy files back and forth manually in 3rd party apps is so damn tedious. In the case of android the network file system features were already implemented upstream, they just had to enable it. This lack of connectivity has made android and IOS worse off in heterogeneous environments and it is such an obvious con that I’m certain there were employees who wanted to fix it. But the bosses likely told them “no” because the connectivity problems gives them more leverage to upsell centralized services instead.
LibreOffice is installed here on every machine as well, but the acceptance among my coworkers is not very promising …
And in case of MS-Office files with macros: no chance!
One would have to convert/recreate them manually to get it right, which is simply far to time consuming.
Not only Google is artificially holding back here: its not like Apple’s macOS would not understand SMB (or NFS or AFP) on Apple Silicon – it does!
So there is no real excuse for iOS not doing so.
So now it looks like MS it watching this and tries to recreate that same limitations on Windows.
cybergorf,
Yes I understand. Honestly I don’t like libreoffice that much either. It mostly does what I need but isn’t refined. Unfortunately the versions of MS office that I really liked are long defunct. Even if I switched back to ms office it’s a different product now.
That’s the problem when the dominant tech companies design products to maximize their control rather than maximize innovation.
Imagine Microsoft would invent the Internet. You would need antivirus software for using the internet. Just remove the VBA macros support altogether. It’s broken by design. No checkbox can resolve that. It just gives false sense of security.
Geck,
That’s a rather egotistical point of view. You are only saying that because you don’t use office scripting yourself, not because they’re not useful to others.
So are you against android & macos sideloading checkboxes? I certainly think there is room to debate the implementations, but I for one am glad to have the option and in the same vein I think office scripting needs to be an option too.
There is nothing egoistical about it. It’s insecure in it’s current form and shouldn’t be used. Using such technology at home or worse in corporate environment. People that made it should be shot. If you plan to defend them then be my guest but you are wrong.
Geck,
You are just thinking about yourself and not the needs of others, which is the definition of egotistical I’d agree that autorunning scripts is insecure, but that doesn’t mean we have to get rid of scripting entirely.
You didn’t answer the question about sideloading. This is the same thing. Many people don’t want to sideload and that’s fine for them, but it doesn’t mean that others shouldn’t be allowed to.
You can visit OSNews without being asked a question if you would like to compromise security for being able to view its content. And that is with auto running scripting involved. If Microsoft would invent the internet then you would get a pop-up. Asking you would you like to compromise security for being able to view OSNews? And some people would call such crap as being extremely powerful. And i can imagine some would defend it too. For whatever reason involved.
Geck,
Honestly that rhetoric sounds more like pure anti-ms bias than a coherent argument why users shouldn’t be allowed to have scripts to automate routine tasks.
In the end you don’t have to listen to people from some internet debate. Fell free to disregard the security notice Microsoft has installed. To run VBA macros. From a lets say an e-mail attachment. At your home and at work. That is if you feel we are doing Microsoft wrong. Due to some bias. An average person should get some coherent answers after a few of such acts.
Geck,
That’s misdirection though. The post that I criticized for bias didn’t mention VBA scripts at all.
I agree that it’s bad to run arbitrary scripts from the internet or emails, but I never suggested people should do that. If you read what others and myself have been saying, there need to be protections especially against accidental execution. But still automation is too useful to remove entirely. Sandboxing came up, which could differentiate between scripts that modify the document versus ones that modify the file system, etc. Although it didn’t seem to get much traction here, I was even in favor of separating the code from the data.
As I said before: I certainly think there is room to debate the implementations, but I for one am glad to have the option. If you are against owners having this option, then where are you drawing the line in terms of what owners are allowed to do? Should they be allowed to sideload? Why/why not? You didn’t answer this before.
Rather just read again what you wrote in your two answers. And that is basically you acknowledging it’s crap and it shouldn’t be used. Hence i don’t feel this needs any further discussion. Us arguing we agree.
Geck,
Everyone’s entitled to an opinion, but just because you aren’t the target audience for automation & scripting doesn’t mean a target audience doesn’t exist! You keep evading the question of whether you think owners should be allowed to sideload despite the fact they could also run into malware. I think it’s a fair question.
I couldn’t care less what people prefer to do on their own devices, but if you are going to dictate what others can and can’t do on their machines, that’s a load of authoritarian BS. People have different needs and there’s nothing wrong with technology catering to them. Will you accept that people’s needs are different?