If I'm reading the actual court documents correctly:
1. This wasn't an appeal. They had to make their motion to both the federal district court and the circuit court.
2. This was a motion for a temporary stay, not the actual case.
3. The rejection acknowledged the likelihood of economic harm to Anthropic but weighed it against the impact to the DoD. This isn't shocking and is how stays are meant to work: it isn't primarily a test of who is likely to prevail, it's primarily a test of what the risk to both parties is.
Well no, I asked a mod how the guidelines are meant to be read, and shared how a user could see a particular one as somewhat ambiguous.
If mods categorically had the ability to make every user fully and equally understand the nuance and meaning of all of the rules then being a mod would probably be a much easier and rewarding job.
It shouldn't matter how many lies a guy tells, or how he runs his business. People shouldn't throw molotov cocktails at his house, and people shouldn't act like his behavior is potentially justification for people throwing molotov cocktails at his house.
Anybody whose perception of Sam Altman was "he deserves for me to throw a molotov cocktail at his house" is a horrible person. I don't care if Paul Graham says he's a tough guy.
Explicit condemnation is only hollow if you don't mean it.
To be clear I'm not saying any of it is justified and generally agree with everything you wrote. The fact that happened to Sam and his family is indeed horrible.
That said, please don't twist my words. I think there's utility in understanding why people feel and act the way they do.
Otherwise, everybody just takes the de facto stance of "those people are intrinsically bad people, and not good people like us!" which is pretty useless and typically just leads to more escalation.
You could also spare me the one-line zinger at the end.
I didn't mean it as a zinger; I meant it as a rebuttal of the line from your comment. If you felt zinged by it, maybe it's worth considering why.
You keep writing comments where you try to wiggle between it being really important to think about the context in which people commit crimes and the context in which people are OK with crimes being committed based on not liking the victim, but also you keep clarifying that you don't condone what they're doing or saying.
What is your actual point? The best I can try to pluck out, the summation of the above is that the people throwing molotov cocktails, and the people saying it's justified, are bad people but they're bad for understandable reasons?
>I didn't mean it as a zinger; I meant it as a rebuttal of the line from your comment.
Fair enough.
>If you felt zinged by it, maybe it's worth considering why.
Conditioned response from years of defending comments against immediate pedantry, of which I'm probably guilty of myself. Not saying that you were being pedantic.
>What is your actual point?
Originally dang seemed pretty burnt out from moderating this thread, so I just wanted to pitch in with my two cents saying that he's dealing with a tidal wave of larger negative public sentiment that's perhaps beyond his control.
I think there's an important distinction to be had between whoever threw the cocktail (fuck them), and the folks expressing what I termed callous indifference.
People are allowed to not give a shit and say as much, and while that might be bannable I don't think it's particularly productive to take that route.
Moreover, I thought it was important to note that some people here (like dang presumably) actually know Sam personally, so it might not be appreciated that it comes off as extra ghoulish to them when they're reading said callous comments.
At the same time, if your only source of information about the guy is recent press, it's easy to understand how someone arrives at that position; anti-AI sentiment is gaining popularity rapidly.
That's it. That's my point or stance if you will, I don't think it's that unreasonable; just trying to highlight what I see as a disconnect.
This is the waffling again. You made the pitch earlier that explicit condemnation felt hollow. Your comments here (and the many from other people saying similar things) are what look hollow to me.
When you say things like "it's easy to understand how someone arrives at that position", you're laying the groundwork to justify why what you class as "callous indifference" is just a logical and natural state that we should accept.
We shouldn't. The people who are celebrating or ok with molotov cocktails being thrown are also bad people. To borrow your language: fuck them, too.
>When you say things like "it's easy to understand how someone arrives at that position", you're laying the groundwork to justify why what you class as "callous indifference" is just a logical and natural state that we should accept.
I didn't say it should be accepted nor was I laying groundwork for justification, be it implicit or explicit.
Rather, only stating that such indifference does logically follow in those circumstances.
Quoting my prior comment:
>>Most people's perception of Sam was shaped in recent years, by press coverage that tends to treat him as the face of AI, with sentiment that usually goes something like: "hey, this guy's stealing all your water so he can take your job too, and by the way he lies a lot."
People's reaction here isn't exactly shocking when taken in that context.
That was my attempt at rephrasing a sentence to be more clear in response to an accusation of waffling, I think.
Suffice it to say, point-by-point rebuttal exchanges/slap fights tend to not lead anywhere good, let alone in a comment section that's emotionally charged and personal from the outset.
In retrospect, I should've just left my original comment stand by itself rather than panic and dive into a detailed follow-on explanation which snowballed from there.
I was genuinely trying to post in good faith for positive effect while taking a middle tack that still condemned violence while perhaps humanizing some of the anger.
It didn't quite work out, but I do very much understand where the opposing positions were coming from now.
And, my apologies for swearing.
---
You brought up a dynamic in the second incident's discussion touching on essentially redundant condemnation, where normal people don't bother because it's universally assumed that violence is bad.
Having closely watched the comment section unfold there, I see what you meant by that: it ends up being negative space for what you termed countervailing sentiment to expand within.
I think that was actually the first time I was happy to see a thread taken off the main page early, for everyone's sake.
This feels like a pointless semantic trap. Everything is "waffling" or "wiggling". I don't see the parent saying anything in a disguised manner. It's just that reality is complicated. In the immediate wake of violence, it's exceedingly easy to paint any sentiment aside from "this is horrible" as disrespectful or weasel-worded. That's cheap (as I mentioned elsewhere, it's like the way conservatives refuse to talk about guns in the wake of gun violence).
When your comment is about how you can’t take your counterparty seriously and they’re a joke, you’re incentivizing people who disagree to just downvote and move on.
The signal you’re sending is that you are not open to discussing the issue.
So today, most of the vulnerabilities being found by these tools are in code written by humans. Your hypothesis is that down the road, most of the vulnerabilities will be in code written by LLMs.
What seems more probable is that the same advances that LLMs are shipping to find vulnerabilities will end up baked into developer tooling. So you'll be writing code and using an LLM that knows how to write secure code.
It's staged shocking also - cows first hear beeping / buzzing, followed by mild shocking - less than a regular electric fence, then a greater shock.
It also reduces physical fencing costs and adds the ability to herd by "moving" the virtual boundaries so that cows can be moved from pasture to pasture.
The RSPCA (Royal Society for the Prevention of Cruelty to Animals, Australia) is still reserving judgement on this, so far in seems that in "normal operation" animals recieve less shocking than with trad roll out electric fence lines (which are mostly a visual bright white tape cue that often are unpowered once animals "learn") .. BUT there's also a question of "how bad can this get in fail conditions".
Sure - save for the "live updates of boundaries" part -
the worst case fail situation here is likely a boundary being broadcast that was on the opposite side of the planet ("a simple error of plus/minus sign") and the entire herd is constantly(?) being buzzed and shocked.
A good chunk of the reports are false positives (slop) per the researcher's own admission in his talk. I have no issue sharing the bug reports either; the bugs are better fixed.
What I take issue with is that they have basically released the weapon first without thinking about the consequences. And again, if you watch the talk, you'll see how he literally calls others to action to fix the problem. They made a problem and are asking you to fix it, and it will also cost you money, which conveniently goes to them. Any industry with even a semblance of regulation would find this very disturbing.
A very shallow dismissal of my point. Is there no room for depth in your logical analysis?
First of all, we don't know whether this particular bug was already being exploited in the wild. We do know that there is a community of experts looking at the Linux kernel and reporting bugs. Yet this bug had never been reported until now. So either nobody ever looked there (unlikely), or they did and didn't find it. Conversely, the LLM found it with a prompt that even a 5-year old can type. That significantly lowers the effort for the attacker, so much that it changes the game. It is, to use a crude analogy, like deploying firearms in a field traditionally fought with sword and shield. So yes, that's the weapon, and these guys released the stuff to the public with no oversight. That should get some people thinking.
Certificates provide extra features, like revocation.
However, if you do not need the extra features provided by certificates, using SSH-generated keys is strictly equivalent with using certificates and it requires less work.
TOFU is neither necessary nor recommended, it is just a convenience feature, to be used when security may be lax.
The secure way to use SSH is to never use TOFU but to pair the user and the server by copying the public keys between the 2 computers through a secure channel, e.g. either by using a USB memory or by sending the public keys through already existing authenticated encrypted links that pass through other computers. (Such a link may be a HTTPS download link.)
When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels.
> secure channel, e.g. either by using a USB memory
Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc.
Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.
Just to make it clear: this does not mean that it is fine to blindly accept the message on first use.
The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?
Like I have said the secure way requires the secure copying of both keys before the first connection attempt
The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server.
When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown.
You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match.
You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client.
When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client.
The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client.
By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.
Sure, I just wanted to make sure that nobody would understand "TOFU is neither necessary nor recommended, just ignore that message and say "yes" when it appears".
Both ends need to be sure of who is on the other end, and there are different ways to achieve that. The way SSH works is that if you haven't copied the server public key locally, it will explicitly ask you to verify it the first time.
I am not sure that "SSH does TOFU". SSH asks you to verify. The human who YOLOs it and approves it without checking is the one doing TOFU, and this is not really secure.
> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels.
That is not the case, and is a major advantage of certificates.
What you say is extremely wrong and this misconception is very dangerous.
When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible.
The 2 pieces of information may allow direct reciprocal authentication, i.e. the client may have the server certificate and the server may have the client certificate.
It is also possible to have indirect authentication, e.g. the server sends the server certificate to the client and the client sends the client certificate to the server during the initiation of the connection.
However, for indirect authentication, both the client and the server must had been previously paired with a server hosting the certification authority.
This means that the root certificate of the CA must have been transferred through secure channels to the client and to the server, and also that the client certificate and the server certificate must have been transferred through secure channels to the CA for signing and then back to the client and the server.
So setting up the computers for indirect authentication through certificates requires significantly more transfers through secure channels than setting them up for direct authentication.
The advantage of indirect authentication appears in an organization with a great number of computers, where indirect authentication reduces the number of secure pairings that must be done from N*(N-1)/2 to N.
However this has nothing to do with certificates. Indirect authentication can be done without certificates, like in Kerberos, or like in SSH if you have a management computer that you pair by copying the public_keys with every computer in the network. Later, whenever you want to enable some client to connect to a SSH server you use the management computer to copy securely the corresponding public_keys between the server and the client.
So no, there is no advantage of certificates related to reducing the number of transfers that must be done through secure side channels, like copying through a portable memory.
Certificates provide other features, like temporary validity and revocation, which can be useful in an enterprise context.
What misconception? You essentially admit that I'm right in this comment but surround it with a bunch of other unrelated words.
If you use SSH certificates, then you have to put the SSH CA cert on each server once, and you have to give signed certs back to each client once each time you sign a cert (which can be once per client or once per connection or anywhere in between).
You do not have to copy anything new to each server when you sign new client certs. Likewise if you sign host keys, you don't have to copy a new host key to your client when you add a new server.
Sure, you could get the same kind of trust relationships with other tools. But SSH certificates provide them and are an advantage of SSH certificates over traditional SSH public key auth.
It honestly feels like you're just dropping this thread into an LLM and asking it to write a disagreeing response.
Not just your ISP. If an attacker slipped a device onto your LAN and also you happened to be sshing to a new box for the first time then TOFU poses a problem. But that's an awfully limited attack surface. It's similar to the difference between leaking a fax while it's sent versus leaking years old emails that are just sitting there on an internet accessible server.
As for your ISP I think you should never rely on TOFU over the public internet. If you really don't want to do ssh certs it's easy enough to make the host key available securely via https.
reply