It has been done. It is no longer done because it is not efficient.
Yes, it was not "object storage", but Git can be served from a dumb http server as static files. Now someone figured out that object storage can also serve static files via http. Wow!
> XML is mature and supported in all languages with code generation its more or less transparent to the dev.
No, XML is still not mature. They still need to fix the security issues everyone reimplements every time such as local file disclosure via DTDs, exploding documents due to entity expansion and so on. It basically doesn't handle untrusted input well, like SQL built from strings without parameter bindings.
I hope this is reasonable and doesn't use XML Security or similar extensions that add a whole stack of other security issues on top that everyone reimplements when adding SAML support.
> They still need to fix the security issues everyone reimplements every time such as local file disclosure via DTDs, exploding documents due to entity expansion and so on.
Who is doing this reimplementation? You're supposed to be using mature, battle-tested libraries for parsing these formats. Writing your own parser for just about any format is a fool's errand when good implementations that have already addressed these issues exist. Even a simple format like JSON is not immune to performance, safety, and correctness pitfalls.
XML is not perfect, but it is mature. It has been the same for a very long time, all the warts and gotchas are well known. You need to be careful about the same things in 2026 as you did back in 2006.
Nuclear isn't as cheap as you present it. It needs heavy subsidies for insurance and waste disposal.
Most nuclear power proposals are just LARPing as "cheap" as they pretend subsidies don't exist.
In addition you have to shut nuclear power plants down in summers due to lack of sufficient cooling. That means you need to plan alternative replacement power generation.
> Apps are not infected with NetNut. This is just Google abusing their monopoly position to hurt its competitors.
If apps ship with stealth backdoors to sell access to the user's internal residential network, that's malware. I doubt any users want app providers to sell access to their private file server and anything else on their local network.
It doesn't seem like monopoly abuse to exclude such malware from application stores, just like key loggers or apps intercepting other apps network traffic without the user being aware of it (say the banking app's network traffic and password entry).
>sell access to the user's internal residential network
That is not what the SDK was doing. The actual code in the SDK protects against this (simplified to take less space):
if (addr.isSiteLocalAddress() || addr.isLoopbackAddress()) {
LogUtils.e("PopaTunnelAsyncThread", "Hacking? The Host Resolved Ip is " + addr + " on tunnel id:" + tunnelId);
throw new IllegalArgumentException("Hacking? The tunnel host resolved ip is internal");
}
Local and loopback addresses like 10.0.0.0, 172.16.0.0, 192.168.0.0, and 127.0.0.0 do not work. It will not connect to people's private file servers on their network.
It'll still connect to IPv6 addresses and bypass any firewalls.
Also users might become part (victim?) of a police investigation because of illegal actions that seem to originate from their local residential connection.
So still good to take down such backdoors. Would be nice to go after the botnet operators as well...
Instead require app developers to explicitly call out this monetization method. This is neither designed to be a backdoor, nor a botnet. These are harmful classifications which can encourage people to try and target them like malware, when they are essential tools for privacy, bypassing geoblocking, and being able to collect public information from sites. The average person is not going to be involved with a police investigation. That has a tiny probability of happen and trying to blow it up to such proportions is dangerous to the existing of this important tool.
You don't need prepared statements. The fix is parameter binding: submitting parameters separate from the SQL statement itself, separating code from (user) data.
> The analogous mitigation for agents is to have fixed behaviors they can perform, such as “read repo 1” “read repo 2”, etc., and the user input is used as data to select which of these fixed behaviors to execute.
No, that only deals with some special issues. It also doesn't separate code and (user) data, so it's not the same issue.
Having only limited actions is akin to using more restrictive database permissions. That also makes SQL injection no longer relevant: only SQL statements can be executed that the user is allowed to run either way.
And even then, it's just sampling. Much of what we "see" is a prediction, and there are plenty of optical illusions out there premised on that (plus VR techniques like foveated rendering that take advantage).
LSP is a function call protocol. So that is already done?
reply