Counterpoint - every real world crypto algo needs to do somewhat content aware padding or the crypto is much easier to break. Either that, or go so overboard on randomness that it adds a lot of overhead.
When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
> Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
Such a shame the US didn't switch at least some of the fleet to electric years ago when it had a chance. Total stupidity. Even to this day my local MAGA town balks at solar panels and just laughs at people who install them. Reality will smack them in the face sooner or later. Right now they are blaming the democratic governor because they only provided a tiny bill credit to citizens to help reduce rates but totally ignoring how the Republican promised nothing.
It's much easier when they release huge PR whitepapers about how many felonies they've committed recently, I think. Makes the civil suit much more straightforward in my opinion.
Except some of the TVs try to connect to unprotected hotspots, or piggyback through ISP's routers' hidden secondary SSIDs. Which even opens people's data and ambient conversations finding their way to the manufacturer or advertisers through war-driving.
Ok, I don’t understand your point, then. If a device works locally then you can firewall it and block any nasty stuff phoning home. If it runs everything through the manufacturer’s servers then you can’t firewall it without disabling it entirely.
I’m completely lost. I’m not talking about safe, I’m talking about how routing everything though a server gives a lot more control to the manufacturer and they’re loathe to give that up.
I’m pointing out that has literally nothing to do with LAN or Wifi. It’s a problem with having literally any (unfiltered) network access at all. Though even filtered, you’re susceptible to bypass attacks.
Notably, a device can even route all command and control through a cloud service, including sending copies/hashes of all accessed content AND also serve just local (as in physically connected) media/content, if it has a network connection.
This has been an issue since BluRAY at least, where players have the capability to check physical media licensing and deny/brick BluRAY media based on network updates of the keys, and could run Java apps which had network access. So at least 20 years? It is a big reason why there was resistance to BluRAY vs DVD, as DVD was a relatively dumb player.
The only way to prevent that is to firewall off or physically disconnect any network access. Which is getting harder to do with cheap LTE modems.
In this example, for instance, I bet these LG TV’s will happily send all this info even if no one is using any network or app based media streaming at all.
And if everything goes through the manufacturer’s servers then you have to give it internet access for it to work at all. If it works over then LAN then you at least have the option to block it without disabling the functionality.
Again with the ‘works over the LAN’. What do you think that actually means, because I keep explaining that doesn’t mean what you seem to think it does, and then you keep repeating it in a context which doesn’t make any sense.
It means that my device at e.g. 192.168.123.45 can be controlled by my phone or computer at 192.168.123.46 on the same LAN without any of the traffic going over the internet. And since none of the traffic goes over the internet, the device can be completely blocked from internet access without disabling the ability to control it.
I'm not really sure what the disconnect is here. This seems like the obvious meaning of "works over the LAN" and it means, by definition, that you can control the device without letting it access the manufacturer's servers.
You’re saying ‘works behind a firewall’, or ‘works without an internet connection’. Maybe ‘works on a fully isolated LAN or VLAN’?
A LAN (or WiFi) typically has routability to the Internet (though doesn’t have to, of course!) which is why what you are saying is confusing. It has for at least 20 years, and is especially true in residential, but also true even in commercial.
Those some IP addresses could also be NAT’d, and often are.
Most modern products have also spent significant R&D figuring out how to bypass NAT and firewalls and even hide from packet inspection (tunneling DNS and command and control over HTTPS, for one example).
Very few people are able to handle or setup actual air gapped LANs now (or isolated VLANs), but anything besides that is risky in these scenarios.
I was replying to “Manufacturers just need to realize that LANs exist and allow their devices to be used with the Internet turned off.” If it took you this long to figure out what I was talking about, I don’t think it’s really a problem with my description.
So weird, it’s like you refuse to read my comment and keep
replying with the part of your comment which ISN’T that part, and then act like I’m the problem when I point out you aren’t making any sense.
Your comments consist of two parts. 1) telling me that I’m wrong because you insist on not understanding what I’m saying 2) a bunch of irrelevant stuff based on not understanding. So yeah, I’m replying to part 1 and ignoring part 2.
So what, praytell, does LAN have to do with your comment. Since I was pointing out, that it was the ‘turn off the internet’ part, not the LAN/Wifi that mattered. And that was the part that you kept ignoring.
What does LAN have to do with my comment about why companies don’t like to let their devices talk directly to my phone/computer when they’re on the same LAN?
Do we need to prove that any given problem is unsolvable, or is it enough to remove broken tasks from the training pipeline?
I understand the broken benchmark task in the HF incident was conceptually like: "Exploit vulnerability 0042 in vulnerableDecompress() to obtain the flag".
The same kind of problem with broken tasks exists in the training pipeline, and we presumably reward workarounds and hacks that tamper with the grader, rather than rewarding the correct output that the task is not solvable.
The problem is that in the event an exception is the failure case being checked, and the output itself is not important (since any output that isn’t an exception is ‘success’), that is a perfectly acceptable use case.
It’s why this is a fundamentally hard problem. Some heuristics might catch 80% of the cases, but the rest?
How do you even know what the real situation is, if the agent/employee/whatever you send to find out is as likely to cheat as not?
When you look at the details underneath more crypto, there is a lot of ah hah - and ‘doh’ - moments due to implementation realities.
reply