1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.
2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.
3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.
4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.
Because, between all of these expenses, it is the one the customer controls. The customer chooses what card to use, but the merchant pays the associated cost.
Then what about a toilet cleaning fee? If you as a customer used the toilet during your shop visit, then you get charged a toilet cleaning fee on top of your transaction.
To me, surcharges should not be allowed. The sticker price the customer sees when they decide to buy ought to be the price. This makes comparisons much easier, and enables more competitive pricing.
So you want everything to be labeled with a cash price and a visa price and Mastercard price and discover price and Amex price? Labeling it with just the cash price seems fine, you can go to an atm and get cash if you don’t like the surcharge.
> labeled with a cash price and a visa price and Mastercard price and discover price and Amex price?
of course not. That's absurd.
I want a single price, regardless of my choice of method of payment. The cost should be built-in to the price. If the cost of providing one type of payment method is too high, i want the business to take out out to make their price more competitive (balanced with the amount of people unwilling to shop there without said payment method).
Merchants and payment providers compete to provide payment methods at as competitive rates as possible, because they needs to compete with cash handling (which isn't hard at all), and the consumer doesn't think about "cost of payment method" - they merely need to think about the cost of the item displayed.
This doesn’t make any sense. So the price should include potential transaction fees for the most expensive method of payment? Or you want the cheap payment method to overpay and subsidize the expensive payment method?
There’s also usually a flat fee plus a percentage, how do you bake that into the advertised price when the flat fee may be spread across multiple items? Should every item increase in cost by $0.30 or whatever?
This is just stupid. Advertise the cash price. You can go to an atm if you don’t want pay the fees associated with your preferred payment method.
This is the age old problem with proving correctness. You can (sometimes) prove that two programs have identical behaviour. One of the programs can be slightly simpler in that it is only concerned with what the correct result of a given operation is, not how to get there. But this doesn't fundamentally change that the complete specification is almost as complicated as the program itself.
Yeah, this very much gives the vibe that the original plan was to design a CPU, then suddenly AI AI AI happened, and they squeezed some matmul units into the design at the last minute in order to please the higher ups.
The power density has been steadily increasing over the years, and then going from CPU to GPU makes it even bigger. This wouldn't be such a big issue if they actually took the time to build the infrastructure. But nobody has time, so it is gas turbines and evaporative cooling, and that makes a horrible neighbour.
I suspect you are right, but it is getting really difficult to tell the difference between AI and someone who simply don't know what they are writing about.
Nah, "selling shovels" is mostly a metaphor, the amount of iron that went into mining equipment was insignificant, beyond some local demand peaks. The majority of the business was consumables.
A key thing to understand about the gold rush is that it was not a major economic event, or at least nowhere near as big as the participants thought it would be, hence the tradegy.
The AI gold rush is different in that there actually is a mountain of "shovels" large enough to flood the global market quite severely.
You "suspect", but your suspicion comes with a unit of energy, which simply does not make sense in the context. The rest of us are talking about effect.
First thing missing from this "article" is a number indicating how many people don't want AI datacentres anywhere. You can't claim that someone is a NIMBY if their stance is that the damned thing shouldn't be built anywhere.
1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.
2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.
3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.
4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.
reply