There's a "Zone.Identifier" alternate file stream [1], written to downloaded files by all browsers to indicate that the files come from untrusted location, and their treatment should be restricted until they are unlocked [2]. The proposal is to honor this data, and offer to open such files in read-only mode, with macros disabled. [1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/6e3f7352-d11c-4d76-8c39-2516a9df36e8 [2] http://woshub.com/how-windows-determines-that-the-file-has-been-downloaded-from-the-internet/
I believe you, so I set to NEW
IMO, the proper place to put this check would be SfxMedium::IsReadOnly (sfx2/source/doc/docfile.cxx), which is called from SfxObjectShell::IsReadOnlyMedium, which in turn is called from SfxObjectShell::DoLoad. I am unsure wrt implementation; maybe we could use ucbhelper::Content::getPropertyValue, passing some new property name like "SecurityZone" or similar, which would on Windows check the stream documented in references listed in comment 0. Stephan: what do you think?
(In reply to Mike Kaganski from comment #2) > Stephan: what do you think? Sounds like a plan, but I don't think I have any useful input. (Whenever I tried to modify the relevant sfx2 code, it looked like a complete mess to me. And instead of doing the alternate file stream access via UCB, it might also be plausible to do it directly via whatever Windows-only API in sfx2.)
FTR: IInternetSecurityManager handles everything required itself: mapping both the location, the Zone.Identifier stream, and even something called "Mark of the Web", itself. So this function would suffice: static bool IsRestrictedZone(const OUString& sURL) { #ifdef _WIN32 if (sURL.isEmpty()) return false; try { DWORD dwZone; sal::systools::COMReference<IInternetSecurityManager> ism(CLSID_InternetSecurityManager); sal::systools::ThrowIfFailed( ism->MapUrlToZone(o3tl::toW(sURL.getStr()), &dwZone, MUTZ_DONT_UNESCAPE), "IInternetSecurityManager::MapUrlToZone failed"); if (dwZone >= URLZONE_INTERNET) return true; } catch (const sal::systools::ComError&) { // No problem; assume no zone information == no restriction } #else (void)sURL; #endif return false; } Using it as another condition to SetReadOnlyUI() in SfxObjectShell::DoLoad would do - except the infobar would not hint why the read-only happened. So I put it all here, because I don't have energy to do deeper modifications in UI myself. Also there seem to be no similar requests - so maybe it's just me, and not needed to users actually. So - WF; but if someone decides to implement, please reopen and do it.
Some related links: https://textslashplain.com/2020/01/30/security-zones-in-edge/ https://textslashplain.com/2016/04/04/downloads-and-the-mark-of-the-web/ https://docs.microsoft.com/en-us/deployoffice/security/internet-macros-blocked
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b22bbfa25ab1f0b9cfa1dedc85b8f9874f0a5e5b Related: tdf#125093 Check Windows Security Zones for macros It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
More related links: https://textslashplain.com/2022/12/02/mark-of-the-web-additional-guidance/ https://devblogs.microsoft.com/oldnewthing/20131104-00/?p=2753 Use in browsers: Firefox: https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/downloads/mozIDownloadPlatform.idl https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/downloads/DownloadPlatform.cpp#l258 Chromium: https://chromium.googlesource.com/chromium/src/+/283fce1e5a7b517f92d2cedcefff7b42d2b9772a/chrome/browser/download/trusted_sources_manager_win.cc#30
How should this work in combination with the existing macro security levels? Currently when Macro Security is "Low", the Windows Security zone is ignored and macros are always enabled. When Macro Security is "High" or "Very high", the Windows Security zone is also ignored. It is only evaluated when Macro security is set to "Medium". Somehow the security zones need to be integrated with the existing Macro security levels.
Note that the macro security is somewhat orthogonal to (or maybe just part of) the original proposal here: the read-only mode of the file open is not the same as blocking macros. I suppose that the read-only state needs not to be bound to the macro security.