It doesn’t need to be able to entirely automate a job to replace jobs though. If it enables one worker to be 10 times as productive, then the company can hire 9 fewer people (depending on how the productivity of the position scales)
I don’t have hard data on this; however, I believe that cash buyers are minority, maybe even significant minority. It would be awesome if someone could share concrete numbers on this.
Something that prevents me from adopting a lot of superior modern tools is that I need to SSH into a lot of servers and other machines that don't have the tools installed. I don't want to maintain the muscle memory and knowledge of 2 separate workflows & toolchains for the same tasks on different machines.
I'd like to see something that runs locally with my aliases, keyboard shortcuts, plugins, etc. and translates the commands to a remote backend, maybe similar to VS code's remote development.
True. And here is where what people think is a virtue of a standard Unix shell (zsh or bash, say) is actually not as good as it seems ("it's already everywhere"); because shells like this don't have dependency management, you have to do it all yourself. Either out of band (make sure curl and jq is installed, which awk is this? oh and all the other little things that are buried in my scripts and functions but are not declared in a standard way). Now I have a full-on configuration management problem that I will need to integrate--just to make your shell scripts, snippets and functions work) or by bizarre horkiness in your scripts (pure-bash json libs, anyone?).
Interestingly, if all of your machines were to have Powershell core, you can actually do a lot of what you describe over SSH more elegantly with Powershell remoting.
This is what killed my experiment with an alternative shell for me: I didn't a bunch of time SSH'd to other machines trying to do things, and anything useful I learned didn't translate - whereas a quality bash function can be piped into the environment.
Now my primary interest is essentially whether through an SSH tunnel using minimal tools I can pull the remote resources back to my machine and use a real environment.
Why can't we tackle XSS in the browser, by preventing javascript from executing in the <body> (or anywhere other than <head> for that matter)? There is an old memory protection technique of designating the stack & heap (data portions of memory) as non-executable. It seems like a similar idea should apply to the web, where the DOM is effectively a "data" portion, and separate out all executable javascript into a separate section. I know this breaks things like `onclick=` attributes, but can't those be replaced with event listeners? Of course it would be opt-in by setting an attribute somewhere in the DOM (e.g. <body non-executable="true">)
This seems like a fairly obvious idea to me, but I'm not a frontend developer, so I'm looking for someone to tell me why this doesn't already exist :)
Unless you can influence an organisation at a pretty high level it is often impossible to write a useful CSP.
To take a really degenerate example, media sites tend to have so many third-party JS integrations (maps, multiple analytics providers, ad systems etc etc) that you can't write a useful, security-improving CSP :/
Which means talking to marketing about their preferred analytics tool, asking the business if they really want these ad networks etc etc.
