Hard to say. There’s lot of security policies out there, some of them useful, and some of them silly. I’m surprised they weren’t even able to view your original attempt at sending a link, although there could be many reasons for it. Depends on why and how it got blocked really.
I think everything would be loaded locally and not reach out to the Internet for anything at all. I could be wrong about that but I’m pretty sure that’s the case. So in that sense it would be extremely unlikely that the pages/documents/files could end up being malicious, unless the original site is somehow malicious and assuming they weren’t modified in transit somehow (e.g., someone intercepts and tampers with the attachment before it gets to the other person).
We’re also assuming they are permitted by their security policy to receive and download Zip files, and then open local HTML documents. Hard to say what their policies might look like.
This is how you’d use DevTools to capture the page, and it would save it as a single, simple image file.
Note that you’d use the ‘full size’ option if it’s more than 1 screen length that you’d need to capture.
So this is what happens when they try to open the link directly? With everything we’ve discussed until this point, figuring out why they can’t just open the link might be the easiest path. But without knowing the exact site it will be hard to say why they’re getting that issue. All that said, that error message is eerily reminiscent of an error many Chromium-based browser (Brave, Chrome, Chromium, etc.) were getting recently when they had out-of-date local certificate stores on their computers. This mainly affected people running Windows 7 as well as older versions of macOS. Might be worth seeing if that’s their situation.