In Spain the high speed network is separate from the traditional network too. There is some inter connectivity to allow for high speed trains to call at traditional stations, but the high speed network is for high speed trains only.
Yeah, the planned Czech high speed trains (VRT) have the same gauge but are expected to be used by the high speed trains almost exclusively, with a limited number of normal-speed passenger trains and AFAIK no cargo traffic at all.
In engineering the simple solution is often the best solution. Creating a demand-side network of devices is not that.
Plus, such a system would provide even more ways for nefarious actors to sabotage the grid, by influencing the demand side. For example, setting every appliance to run its load at the same time. The grid would be fucked.
I don't disagree with your broad comment but it's not hard to fix by slightly dispersing the control/responsibility.
1. Electricity moves for 5/10 min clearing intervals with defined caps at either end (currently in Western Australia it's simply 2 intervals, peak & off-peak).
2. Expose the pricing/market data via API
3. Develop existing home automation frameworks/tools/device IOTs/routers to access that.
4. End user grants permission/configures it on their smart phone when they set their dishwasher and washing machine on set up ("would you like to enable this smart-go button by connecting to Wi-Fi? It could save you $150 per year").
No control ceded to third parties to turn on equipment whenever they want, just allows the end user to cue jobs for when the PowerCo anticipates lowest prices.
PowerCo not any more of a honeypot for attack, at least not more than they are now with control over critical generation/tx/dx infra.
If the devices are accessing a 3rd party API over the Internet to get this info, that control is still ceded, and attackers can still exploit vulnerabilities in all of these devices to attack large swaths of the network at once.
> While the data itself is encrypted, notice how the values written by the first and third operation are the same.
The fact that Intel and AMD both went with ECB leaves me with mild disbelief. I realize wrangling IVs in that scenario is difficult but that's hardly an excuse to release a product that they knew full well was fundamentally broken. The insecurity of ECB for this sort of task has been common knowledge for at least 2 decades.
Google "intel sgx memory encryption engine". Intel's designers were fully aware of replay attacks, and early versions of SGX supported a hardware-based memory encryption engine with Merkle tree support.
Remember that everything in security (and computation) is a tradeoff. The MEE turned out to be a performance bottleneck, and support got dropped.
There are legitimate choices to be made here between threat models, and the resulting implications on the designs.
There's not much new under the sun when it comes to security/cryptography/whatever (tm), and I recommend approaching the choices designers make with an open mind.
I agree with the sentiment but I'm struggling to see how this qualifies as a legitimate tradeoff to make. I thought the entire point of this feature was to provide assurances to customers that cloud providers weren't snooping on their VMs. In which case physically interdicting RAM in this manner is probably the first approach a realistic adversary would attempt.
I can see where it prevents inadvertent data leaks but the feature was billed as protecting against motivated adversaries. (Or at least so I thought.)
Fair point, my ECB remark was misguided. But I think the broader point stands? I did acknowledge the difficulty of dealing with IVs here.
It's the same issue that XTS faces but that operates under the fairly modest assumption that an adversary won't have long term continuous block level access to the running system. Whereas in this case interdicting the bus is one of the primary attack vectors so failing to defend against that seems inexcusable.
This is a very standard part of responsible disclosure. Hacker finds bugs -> discloses them to the vendor -> (hopefully) the vendor communicates with them and remediates -> both sides publish the technical details. It also helps to demonstrate to the rest of the security world which companies will take reports seriously and which ones won’t, which is very useful information to have.
>They provide third party API's to use APPLE's RCS-Service. The alternative would have been to support registering alternative RCS-services as default on the OS (and then, allow the user to choose a service).
RCS messaging is carrier-controlled and configured via carrier bundles in iOS. Apple doesn't run a "RCS service". TelephonyMessageKit [0] in iOS 26+ exposes a standard interface to the carrier SMS, MMS, and RCS services, as applicable, allowing for 3rd party applications to send and receive carrier standards-based messages.
In 3GPP standards, RCS is just another service using the IP Multimedia Subsystem (IMS) framework. Carriers can either run their own RCS service in their IMS core or use a 3rd party service (as many do with Google's Jibe).
The EU has already figured this out with the recently passed instant payments regulation [0]. As of 2024 are 5,304 banks in the EU [1], so the number of banks really isn’t an excuse. The US banking system lags the rest of world by a mile, because there is no will to force modernization.
FedNow is a technological solution for instant payments, not a regulation. It’s a voluntary system for the banks to join. Further, banks are not required to offer instant payment services to their customers. The analogous technological solution in the EU is TIPS [0], which has been operational since 2018.
The IPR is a regulation that requires banks to support instant payments and offer them to customers.
reply