edelbitter

How about: civility? Because I'd argue that was always the expected, the appropriate thing to do. Always watch for feedback and quickly edit any missed meta-issues with your question. So that during the slim window it can reasonably be shoved into possible answerers faces it will not waste their time.

As long as vision zero is considered more of a gross infringement on personal freedums than a laudable goal, making trains as safe as they are uniquely fit to become is not exactly a great way to allocate funds to maximize impact. Trains are already very safe. Even where they currently lack 4 layers of fail-safe systems operated at a level where that still permits reliable&punctual service. The same money on making them shine could be spent on improving car infrastructure (or even removing some car infrastructure!) for greater expected harm reduction.

There is also plenty of ways to confuse the WAF by simply sending multiple instances of of the relevant header and/or parameter..

If your application is known to routinely "deserialize" (unsafe-eval) strings from a database or cache, an attacker might have placed a tiny backdoor that way, only to be used after the everyone has applied the PHP patches and attention levels & active staff are back to normal.

Scroll down in the actual patches to the weirdness of the multipart parser. That very much looks related to the what can be abused via the upload progress callbacks that had been discussed on (anti)social media.

A rewrite would tackle the classic C-style W^X problems, at the expense of maintainability and focus on logic bugs and general oversights from inelegant (or lack of) design. And I'd bet PHP (and popular PHP software for reasons rooted in the language) still got plenty of the latter. You know, the "oops, that filename was client provided" kind of code execution that no amount of (un)safe blocks can help with.

I think I see a way to overwrite suitable memory in the parser, so smuggling (as in: confusing another parser) would be purely for bonus points.

Cars occupy public spaces where more efficient modes of transport have already been mostly driven out, while delivery robots conquer additional public space.

I find it slightly less weird because I see potential for indirect attacks on the not-quite-so-ECC parts of actual implementations. Wherever a network client can ask many times for each of the different, but somehow not entirely uncorrelated curves, it might be able to expose previously not deemed critical side channels. Following in the general direction of the discoveries that so far resulted in IV and padding determinism/randomness being considered as important as the "actual crypto" itself. In that case the structures that would need to somehow interact would not be ECC and LCG, but merely LCG and key derivation..

This is the reason why this is desirable for humans. But I do not like extending excuses that apply to human (limitations) also to companies that could keep a log.

>they can be hit randomly with 2^30 tries

More precisely: not very random tries.

Remember the currently common margins account for the fact that you actually use some of the water every now and then. That water in the tank will regularly cross the merely transiently safe temperature range, by design.

Once silicon is in control (which is where responding grid requests to delay consumption is more or less necessarily heading) you could even achieve better (worst-case) safety margins at reduced (total) power consumption. Because the machinery no longer needs to be designed around two "dumb" thermo switches and do a little extra in case layers of varying temperature manifest after two or more spaced periods of consumption. With continuous monitoring in software, you can integrate the worst-case bacterial growth based on time elapsed outside the "practically safe" temperature ranges. Then the tank always knows what is needed, and can both operate on tighter margins and reliably know when reducing or delaying power draw is ok.

The current policies are not very enterprise-friendly yet.

Some settings are flat out refused (for "security reasons"). And with each new update there are a few new popups / invitations to try this new feature / re-enabling the v2 of the thing of which the v1 was already opted out in the policy. And it seems like you cannot apply new policy while the browser is running - meaning it cannot be used to roll out hotfixes without interrupting the work of currently unaffected workstations.

And then there is the syncing. If you want to manage & sync history, bookmarks and the password managers content.. you are probably going to find that easier by overriding the builtin features with 3rd-party extensions, as the builtin sync feature is very much tailored to the needs of privately owned devices and one-device-at-a-time usage patterns.