wkhtmltopdf is pretty out of date at this point and headless Chrome/Chromium or something that wraps them is probably a better and safer, roughly equivalent, alternative. Docker might not be a great option if you're already running a containerized service and don't want to deal with getting them to play nice together.
I've been trying to use HTML's native popover and dialog recently. The promise of not having to write/import focus traps, better integration with standard platform "cancel" UX, the top layer concept, etc made them sound great, but in reality it's been kind of painful.
Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog. Anchoring is currently only supported in Chrome, so popover tooltips show up in the corner. Firefox supports transition animations when opening a dialog but not closing it. The web platform feature needed to tie the mobile back button to closing a dialog isn't actually implemented yet. Frameworks that patch the DOM might clobber modal dialog state because it's a function of both the "open" attribute and the result of showModal().
Some of these will improve but I think the display order problem is here for the long haul.
>Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog.
Whenever I have to fight something like this it always makes me question the goodness of the pattern to begin with. Stacking multiple modals/popovers/tooltips can’t be a great UX (or accessibility) pattern, can it? I find at least half the time that I’m fighting the browsers it’s because I’m trying to do something suboptimal
It’s a pattern that I’ve seen called dialog tunneling, and I think the most prominent example of it is Windows 9x up through 7. Web apps are pretty bad about it too though, more often than not because navigation can’t be made sensible when there’s a new feature that needs to be shoved in front of users every few weeks/months, so stuff ends up getting buried in dialogs N deep to make room.
I agree that stacking multiple modal dialogs should generally be avoided, and if whatever you're doing is complex enough you should consider whether it needs to be in a dialog at all.
What I'm talking about is if I'm using popover to alert the user about something, let's say another user updated the page they were viewing, and they clicked into a confirmation dialog fractions of a second after the alert arrived, the alert is now behind the dialog and attempting to click on it either does nothing or closes the dialog, depending on how I've configured the dialog.
As the application developer, I'm responsible for deciding how the modes in my multi-modal application behave, and I want top-level alerts like this example to be interactable and in front of confirmation dialogs in all modes, regardless of which one opened first. With the current top layer behaviour, that is not really achievable without doing something like reparenting open alert popovers into the most recently opened dialog, and that's ALSO not properly functional (element state gets reset) until Element.moveBefore() is generally available.
I have an ImageViewer component, which is sometimes displayed in a modal dialog for confirming operations on that image, like delete, move, deduplicate, etc.
The ImageViewer has a context menu popover that needs to appear above the modal that contains it. Using the Popover API lets me be sure that there'll be no z-fighting, the popover won't be clipped by its parent element, and that the popover will dismiss correctly when the user wants it gone. It's pretty great, and I don't think it harms accessibility any more than _having_ a context menu in the first place harms it. And the UX is fine.
(Aside from some hellish work making it so that `oncontextmenu` can actually open a popover. According to the spec, right button mouseup triggers light dismiss, closing the context menu as soon as it opens)
Stacking modals is no good for sure, but just because a form is part of a modal doesn’t mean it should never be able to use a tooltip, dropdown, or popover.
Uhg the other day i found a job posting that initially looked russian, but on further looking i was able to understand far more of it than i ever could russian. I inspected the source. Some weirdo developer set "font-family: Symbol" on every div. Not even in css, right on every divs style tag
If you need features offered by the self-managed Enterprise version of a Hashicorp product, I've heard the price tag is something like low six figures per product.
I've only played around with LXC/LXD a little bit, what are some of the Ubuntu image issues? I did a quick google, but the first results seemed to be questions about hosting on Ubuntu rather than with the images themselves.
In my experience, most issues are related to kernel interfaces which LXC disables inside unprivileged containers, paired with software that does not check if those interfaces are there/work before attempting to use them.
These issues can be observed in the official Ubuntu image and seem to get worse over time. I would recommend to just use VMs instead.
Relatedly, I was recently horrified to learn that not only will Excel (and LibreOffice Calc) automatically parse formulas in plain CSV files, but there is also a formula that will _run external programs_.
Yep. To add insult to injury, for many years there either wasn’t a setting to disable loading of external programs or doing so required a subscription of some kind to a MS enterprise license/endpoint/policy management feature.
I'm skeptical that Excel does this without prompting. Microsoft takes these kinds of vulnerabilities—opening a data file causing ACE—seriously. Do you have more information?
> Microsoft takes these kinds of vulnerabilities (...) seriously.
Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
From those 439 around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing.
I'd argue that "taking this seriously" is the opposite of the sheer amount of those CVE IDs.
And these are only the vulnerabilities we publicly know of, there are far worse VBA exploits being traded on dark markets.
The reason why Microsoft took so long to deprecate these VBA APIs is that large enterprise-grade organizations do almost everything in Excel. From querying a database server to storing a financial report remotely on a mounted net share drive to even including another external file for the inclusion of modules or methods. It really makes you wannacry.
> Sorry, CVE database disagrees with you when looking at the statistics of how often RCE macro loopholes are found in embedded VBA APIs inside spreadsheets.
Sure, but there's a difference between having a large codebase to cover and what is being discussed above. Nothing you've said is contrary to GP.
I am willing to counter any bet that Excel formulas will open an external program without prompting.
> around ~350 are _remote_ execution exploits with their own CVE ID, meaning another VBA API or programming paradigm was affected and downloaded and executed code remotely without the user noticing
Exploits and macros are orthogonal. Macros don't require exploits to run, and I've never seen an exploit bother running a macro. It already owns the process at that point. It can do anything it wants.
> The reason why Microsoft took so long to deprecate these VBA APIs
Microsoft isn't deprecating anything, just disabling macros for files with ZoneId=3. This won't be a particularly effective change in the near term given the practical realities of how people work*, but it's long overdue.
* Roughly what will happen at mid-sized+ companies: 1) New feature is enabled. 2) New feature breaks a bunch of existing workflows. 3) IT is flooded with tickets. 4) New feature is disabled with plans to redeploy with exceptions for finance and other teams whose workflows were broken. 5) Everyone gets busy with other projects and new feature is never revisited.
I wouldn't call it serious, more like indifference. Microsoft has been watching viruses and malware spread by emailed office files for 25+ years. They listen to their users when users want insecure features, and are fanatically committed to only incrmeental changes and backward compatibility - like they do in their other products. Some of this of course is the field of industry called anti-virus software, where glorified blacklists of previosuly observed harmful files are dressed in security theater costumes and MS users are guilted into paying various large costs for them.
This bit of news shows that there are people at MS who takes the vulnerabilities seriously as well, but they very rarely have the influence to effect change if it's weighted against anything else.
It prompts about enabling macros, generally. I haven't tested in the most recent versions of Excel but we see this about once a year at clients. You can test it yourself by with a test CSV like:
I just tried that CSV in Excel for Windows and it gave two warnings about it being insecure, had the disabled button default each time, and even 'enable' each time it still didn't run that cell.
I've come to the conclusion that absolute security is a fool's game, sort of like never getting sick. You have a Turing machine, you have a tape, it's not going to be secure. It's better to invest in research on an adversarial "immune system", so to speak.
This is absolutely correct! Modern technical security practice preaches defense-in-depth. Over a long enough period of time, you WILL be compromised. It’s much more effective to plan for it and mitigate the damage than it is to attempt perfect security.
The trick is to make sure you have good network segmentation, don’t allow apps/users more access than they need, and have reliable monitoring and anomaly detection in place so you can respond rapidly to breaches that do occur.
The only problem with that take is that people will hear it and remember “don’t attempt security because it’s hopeless”. It’s the same problem that comes from people discussing premature optimization and using it as a reason to skip simple and obvious performance improvements.
Nuance has a way of being lost in advice like that.
Like many things, it's about how far into the diminishing returns you want to go. At some point it's more effective to apply further investment to other parts of the ecosystem.
My own conclusion for the security of a small business was to set up a honeypot - a virus needs to search for vulnerabilities to transmit itself, and that search can be detected. Any virus that doesn’t search for vulnerabilities is much more benign.
That might be how worms work, but it’s not going to protect someone from installing a keylogger or a RAT from opening an infected Excel spreadsheet in an email, for example.
That’s much more reactive than proactive either way. Better as a secondary measure for a large business than as a primary measure for a small business.
Wait until you learn Windows has a default file handler for JavaScript (wscript.exe), which can execute external applications, write files and much more.
I would guess it's a combination of Framework not having the same deal the big OEMs are getting, OEM grift, and based on the price, Framework appears to be selling retail Windows licenses rather than OEM licenses.
