xorcist

What constitutes an all-powerful government? It seems rife for a no-true-scotsman argument.

Would it be acceptable for a private company to own this information? Perhaps sell it to others?

It's nice that Google's AI summary always lists its sources. It's less nice that those sources more often than not do not corroborate the summary. It often seems to be a few random links thrown in there for good measure.

I have no idea why this is, but it is impossible that these links are primary sources of the data, if such things even exists at all. In which case, why list them?

It is certainly seems possible that the actual sources of the data is the output of some other LLM.

That's the thing though: We can't know that.

A tire repair shop that also hosted a the National Tire Slashing Club for free in the back?

I think it's fair to assume that would cause some reactions.

Can you seriously see no space between hosting people advertising DDoS-for-hire services and arbitrarily censoring the Internet? Is this what passes as civil discourse these days?

That's especially rich considering that Cloudflare is the actor perhaps best known for blocking access to the Internet for people who seek privacy. Have you tried using Tor during the past several years? Or just a lesser popular web browser?

Look, it's very simple. When any one of your customers is exactly the criminal you sell protection against, you drop them, otherwise you are aiding and abiding. Perhaps not exactly in the sense of the law, if you have expensive enough lawyers, but in practice.

It's been a well known story around Cloudflare from the beginning that they protect booters and other cybercrime actors just like any other (paying or non-paying) customer.

If you report the DDoS-for-hire actors that offer their services on forums where such things are offered openly, they reply with a template that freely interpreted say something along the lines that they can do nothing and who is a crimininal is .. like, just your opinion, man (checks notes) they say here they are a legit load tester operation, so nothing really we can do.

You can say they entered the scene because DDoS exploded in popularity, but you could just as easily make the argument it was the other way around. Make of that what you will but they sure made a lot of money from the same booters they protect their customers from.

The article describes a method of securely seeding private key data to newly provisioned servers. It's a bit of bootstrapping problem, and not something a PKI can solve.

You usually need some form of trusted communication with a new server until you can give it its real identity, in the form of host names and cryptographic keys. In an enterprise environment this can usually be done with some sort of isolated management or provisioning vlan. In a cloud environment, I've seen all sorts of more or less hacky solutions but since it depends a lot on specific details of your networks and APIs, bespoke solutions are fine.

It was not essential to the exploit, but that does not mean it was irrelevant. More commonly used libraries are watched harder. The exploit was made much, much, worse by its indirect use by way of systemd. Approximately nobody wanted that feature and it still went in. That's something we need to be able to discuss.

Unregulated gambling, mind you. Huge difference.

While not native, svk got pretty popular already in 2005, at a time when git was not used much outside LKML. Github wouldn't be released for a couple more years, which had a huge part in git dominance. Bazaar, darcs, Mercurial were all somewhat popular, but a pretty common question was what the killer feature really was that svn couldn't do.

Before a new currency exists, it doesn't exist. Someone has to mint it. It has to be inflated into existence, in the monetary sense. How is this done?

For a state or central bank the answer is obvious: The state or bank itself prints it.

For a private actor the technical means is perhaps less obvious, but the actor behind the currency obviously gets to decide.

For a decentralized open source project, it is less clear. You could do it so every node in the system gets a piece of every newly printed unit of currency, but if it is free to run a node everyone could just run a billion nodes and take all the currency for themselves.

Bitcoin solved the problem with Proof of Work, which is elegant because both the double spend problem and the minting problem is solved together. Every node has to prove it has run a unit of useless computation and inflation is spread evenly across worker nodes. This led to a split between nodes and miners with the use of specialized hardware, but the basic premise still holds.

Crypocurrencies in general are very different. Ethereum, the second most popular, was created by a private actor and the that actor decided to print 72 M for themselves and promptly sold 80+% before the release of the software which gave rise to the term ICO which was very trendy for several years. After the initial release inflation continued according to the miner model.

You could always keep a local svn repository and commit to that, if you really wanted to commit without connectivity. But in practice most people don't, as evidenced by the success of github, which grinds many development processes to a halt every time it is down.

It also ignores svk, which is (was?) a popular add-on to svn, which provided a convenient way to do this and replay all the commits to the central svn repository when connectivity allowed.

> ATM was superior but lost to the simpler and cheaper Ethernet which was pretty crappy in its early days (thinnet, thicknet, terminators, vampire taps, AUI, etc.)

Aren't you confusing LAN and WAN here? ATM didn't lose to thinnet. Nobody (approximately) ran ATM as their LAN.

ATM had its successor in DTM. Yes, long range ethernet won out in the end, but that was much later when it was clear all anyone wanted was IP transport and the cheaper ethernet transcievers got good enough. People ran IP over what they could get: X.25, ATM, anything else vaguely T1/E1-like.

A bit, perhaps, but not much.

At the time of bang paths, smtpd was just one of several email protocols in use. And X.400 was absolutely a competitor at the time.

A decade or two later, when it was clear that smtp had become the least common denominator between all email systems, then smtp absolutely used DNS and even had its own record type, MX.

So I don't think it is wrong to say a large part of why it won out on all other protocols was that you didn't have to mess with email routing once MX records was universally accepted.

The point was that a $100k+ compensation for a software office work is among the highest in the world. If a comparison with another high compensation area falls flat, then maybe that says something.

Perhaps another US state would have been a better comparison. It might be hard for a software developer in Montana to identify with a Silicon Valley rant about salaries being too low.

It would not cross my mind personally to complain about low compensation for my skilled work, precisely because I know my collegaues from areas with lower compensation are just as skilled and earn less. In what way would the world be better off if I was better paid? If it helped my company increase their security posture then that would say more about the ineffective ways we organize work around here than anything else.

This comes off as slightly on the entitled side. Yearly salaries at $100k+ is very high by Western European standards. I can only imagine what our Eastern European colleagues would feel about it. If you can live a comfortable life and send our children to school well fed perhaps broaden the horizons a bit before ranting off about how much better the world would be if you could be paid a bit more.

The proof of concept exploit is just that. It is meant to demonstrate one attack vector only. There are many others. If your goal is to prevent the conceptual exploit only then there are many easier ways to accomplish that, such as blacklisting, that does not make you safer.

With this vulnerability you can manipulate the page cache. You could also manipulate ld.so to hook into arbitraty system calls, or set your uid to 0, or any of another dozen or so ways to elevate your privileges.

Mount points have nothing to do with this, even if is always a good idea to disallow suid in user writable areas and prevent reading suid files, but that's for other reasons. NixOS does nothing to fix this and is just as vulnerable as everyone else.

Just socialize losses and all is well.

What could possibly go wrong?

There is no way to do what you ask for without having a local CA. And once you have it, any existing caching proxy will work. Now you have moved all security to the proxy, but for some applications it is worth it.

Your question is why we have http servers and http middleware at all. Running an application directly on an endpoint makes sense for embedded application, but for everything else you will end up with a separate http terminating layer for a number of reasons.

It makes maintenance so much easier, when you can scale request backends independently of request frontends. It makes sense that the application doesn't have access to TLS keys and can't bind end user facing ports directly. The day you want a separate access log from the application log, and separate instrumentation of the frontends because of some hard to track down bug you will be thankful it is there.

So, you want to deploy some sort of proxy. Will you run FastCGI, SGI, WSGI, uWSGI, plain http, or a number of proprietary load balancer protocols? If you choose http you have to take care to wash your headers and be very careful with pipelining so front and back end expect the same behaviour (which is true for several of the proprietary protocols too). Otherwise there can be catastrophic security implications.

It is probably true that FastCGI was designed as a persistent CGI. But as soon as you have persistence, the http server needs to forward transactions to the persistent backend, and what you have built is a proxy. There is no way around it.

The mystery is why uWSGI isn't more widely used. Perhaps the name does not help. It has little to do with WSGI just as FastCGI is unrelated to CGI.

It is a tiny binary protocol, with frames just as FastCGI. The reference server works with several languages, I've used it over the years mostly with Python but also Ruby and Perl. It is a small C executable with all the practical features one need for web hosting: Draining backends, autoscaling, logging, chrooted backends, everything.

Very few FastCGI servers are this mature. Unlike FastCGI, it has been extended to support websockets and async.

I have used it in production at several places for many years and have nothing but praise for it. It feels like this weird unknown secret for web operations. Unfortunately, it sees lesser use now in the cloud era, and development seems to have all but stopped. It still works and is still reliable but the writing is probably on the wall. However nothing comes close in terms of speed, simplicity, and features.

I don't think that is how it happened. Yes, there was a SCGI/FastCGI chism, but it was mostly the Python ecosystem that used SCGI and the rest of the world was on FastCGI. Unless you were PHP, in which case you were on mod_php because it was an unmovable juggernaut.

Apache had a FastCGI module early on, but it received little love and was not that widely used. For many people, FastCGI was synonymous with nginx and lighttpd because these webservers came with support out of the box (nginx later got modules just as Apache).

When PHP finally got PHP-FPM, that gigantic ecosystem slowly started moving, sometime in the late 00s, and then FastCGI really took over. Almost. Because at the same time, the cloud era started and brought the "just use HTTP bro" mindset. Amazon has always used HTTP internally since the 90s and I would guess that probably carried over to AWS?

So nowadays, PHP still being a silent juggernaut, is now mostly on FastCGI, while most other have moved to cloud era standards and use HTTP. Go, for example, matured at this time and all the tutorials use straight HTTP proxying.

Yes, FastCGI is the much more robust standard, but you will encounter friction if you use it on your cloud native application. For regular servers and VMs it is still common.

They had a product that interpolated untrusted data into trusted SQL strings, but being told about it (and many other vulnerabilities!) was all that was required to make them watertight.

I would be very happy if you right about this.

Whitelisting is usually easier than blacklisting, and not devloping brittle features where errors have security implications is usually easier than spending money on security after the fact. However not developing features is not something we as an industry is good at. Github Actions perhaps being the most recent example of this.

And every time some company got hacked and embarrassed, the same refrain is played out in the comments: "Those cheapskates, they invest too little in security!".

Spend all you want. Buy the most advanced products, and then most expensive services to manage them. I have never seen a company that improved their security by buying it.

That's not "math". That's a "wild guess", or baseless extrapolation at best.

Is that a serious question? Providing for education possibilities, legislating against noncompete agreements to hinder workers to start out on their own, challenging illegal decisions, the list goes on.

Those are inappropriate examples because they are all deterministic. The whole reason behind the AI movement is the move from deterministic processes, and exact descriptions, to handwavy descriptions and stochastic processes.

Of course there are people who do maths after the introduction of the calculator Just like there are more people who program after the introduction of the electronic computer.

Software is blueprint. Can you really become a decent civil engineer if you never created a buleprint for anything?

Will large scale construction projects ever be started with AI made blueprints?

There's probably more to the whole engineering discipline, soft- and hardware, than you give it credit for here.

So, spam?

This is public data so the big guys could absoltely crawl it. But we should not underestimate the size of the PKI industry, several large actors make good living from the existing web PKI and they will not change unless their very existence is threatened.