I don't understand how businesses could trust cloud LLMs going forward with this ongoing "safety" paranoia. Building dependence on them doesn't feel like a sane strategic decision for users.
Because this effectively hinders 0% of people. I understand why people don't like it but day to day this is nothing. If you're using it for coding, it won't stop you. The pearl clenching here and over reacting is predictable and sad. If you are working for a large organization and you were going through the vendor procurement process, questions like Can this produce pornography? Can this tell my employees how to break the law? are normal and anyone wiht half a brain knows that this is the case. Before people jump on that, I understand people have access to the internet. Your question "how businesses could trust cloud LLMs going forward" is absurd and you know it. There is an extremely small set of edge cases that effect 0% of people day to day. You can trust them just fine.
It's not paranoia. Cyber attacks have gone up massively in the past few months even with the weaker models we had so far. And Claude Mythos 5 scores even higher than the unreleased Mythos Preview on ExploitBench. If you made this capability publicly available you would see another acceleration of cyber attacks.
This isn't even about cyber attacks. This is just LLM development which is increasingly just called software development. And at least for cyber it says "Sorry I can't help with that"!
I mean, a slow, deterministic, latency focused network standards sounds a lot like ISDN and ATM(Asynchronous Transfer Mode) standards... there were such lost competitors to Ethernet, HTTP, HTML, etc.
STUN/TURN is basically icanhazip for WebRTC. STUN gives you your public IP:port. TURN is the same, but the returned IP:port is the one that had been dynamically allocated to you at time of querying, rather than the actual ones.
WebRTC clients take that STUN/TURN response and send to peers through out-of-band, through e.g. a lobby server chat mechanism, to set up the connection. This allows NAT table entries to be created as if they are outbound connection at both ends.
You can't make P2P connection with STUN/TURN alone. STUN/TURN is just a tool required for WebRTC.
TURN is the last resort and isn't just signaling. It carries the traffic as well.
If you can make all the STUN servers fail from the perspective of the clients, you could hypothetically force them to use TURN servers that are more centralized and easier to spy on. STUN negotiates pipes n:n. TURN is closer to n:1.
> force them to use TURN servers that are more centralized and easier to spy on
Webrtc traffic is encrypted as it travels through the TURN servers, isn't it? Sure, you get some which-ip-contacted-which-using-what-service metadata, but any active middleman able to mess with STUN traffic already has that.
It could just be that someone's fucked up a setting somewhere. I mean, the reason WebRTC has loads of options for 'interactive connectivity establishment' is because it's common to see users behind NAT, users whose NAT cant be traversed with STUN, IPv6 being broken, UDP getting blocked, TCP ports other than port 443 getting blocked, etc etc.
If a country's ISPs use CGNAT to avoid giving users precious IPv4 addresses, and world events made the ISPs turn the security settings up to 11, STUN just stops working.
> TURN is the same, but the returned IP:port is the one that had been dynamically allocated to you at time of querying, rather than the actual ones.
I don't know you mean by this, but I think you're confused. I have implemented STUN, so I know how it works. AFAIK, TURN doesn't reveal an address/port any different from that revealed by STUN, and cannot, because its discovery feature is STUN. (Also, a typical home user has only one internet-facing address, not a dynamic one plus another one.)
Rather, TURN provides a STUN address/port discovery service and a data relay service. The relay is for cases where two peers wishing to connect are both behind difficult NAT, meaning there is no quick and reliable way for them to directly connect even when they have their STUN results. So instead of connecting directly, they communicate through the relay.
I admit that I only have rudimentary understanding, but: my understanding was that TURN uses a modified STUN format that returns the address/port on the peer facing side of the TURN server, a la address of a hotel room or PO box, of querying user. My point is that STUN/TURN(especially STUN) are not encapsulation protocols for WebRTC, but just means to determine(or get assigned, so TURN sort of is encapsulating, by being a transparent proxy) client's own public IP/port because there is no way to do so than by asking someone with a global IP.
At least touching Unicode strings in wrong locales only mildly corrupts the strings. Plenty of Win32 apps would crash if the system locale is in UTF-8.
I mean, UTF-8 string handling is language (of the given bitstream, not necessarily the system) dependent, e.g. Turkish lowercase I, Chinese Hanzi vs Japanese Kanji at same codepoints, etc etc...
The difference is that films had better performances than digital equivalents in some areas for a long time. It isn't/wasn't just nostalgia.
The imaging device used in electronic camcorders before the transition to CCD had visibly gray whites. They weren't so great by any standards. Hence very few chases it, with nostalgia being the sole reason to do it.
reply