it seems like if these statements that were part of the grants were 1FA protected then they should not have been part of the grants in the first place. since having 1FA protected statements in the grants allows the government to compel speech by favouring grants that make approved statements in the same way they can suppress speech by targeting grants that include disfavoured statements. people were previously claiming certain buzzwords needed to be included in order to hurdle the grant process. of course this is probably completely unworkable in practice since you need some kind of description of the grant and almost anything could be seen as some kind of speech that might be favored or punished for political reasons.
What do you mean by 1FA? It reads like your saying "Grants should not include first-amendment-protected statements," but that is not how the first amendment works. It's passive; speech is protected by default.
The games are on github (https://github.com/kennethpayne01/project_kahn_public/blob/m...) which might give better context as to how the simulation was run. Based on the code the LLMs only have a rough idea of the rules of the game. For example you can use 'Strategic Nuclear War' in order to force a draw as long as the opponent cannot win on the same turn. So as long as on your first turn you do 'Limited Nuclear Use' then presumably its impossible to actually lose a game unless you are so handicapped that your opponent can force a win with the same strategy. I suspect with knowledge of the internal mechanics of the game you can play in a risk free way where you try to make progress towards a win but if your opponent threatens to move into a winning position then you can just execute the 'Strategic Nuclear War' action.
From the article:
> They also made mistakes in the fog of war: accidents happened in 86 per cent of the conflicts, with an action escalating higher than the AI intended to, based on its reasoning.
Which I guess is technically true but also seems a bit misleading because it seems to imply the AI made these mistakes but these mistakes are just part of the simulation. The AI chooses an action then there is some chance that a different action will actually be selected instead.
i think the use case for setHTML is for user content that contains rich text and to display that safely. so this is not an alternative for escaping text or inserting text into the DOM but rather a method for displaying rich text. for example maybe you have an editor that produces em, and strong tags so now you can just whitelist those tags and use setHTML to safely put that rich text into the DOM without worrying about all the possible HTML parsing edge cases.
i'm not sure if Dtrace interpreter was safer than EBPF. I guess in theory it should be because a JIT is just extra surface area but I'm not sure in practice. Both EBPF and DTrace had bugs. Also, I always thought EBPF JIT was just a translation to machine code and it didn't do any kind of optimization pass so should be very similar to how DTrace works. They both ship byte code to the kernel. But I guess the big difference is EBPF relies more on a verification pass while I think most of DTrace safety verification was performed while executing the bytecode. I remember there was a lot of stuff in EBPF where the verifier was meant to be able statically determine you were only accessing memory you were able to. I think there was a lot of bugs around this because the verifier would assume slightly different behaviour than what the runtime was producing. But this is also not necessarily a JIT problem you could have an interpreter that relied on a static safety pass as well.
There might be health problems associated with these drugs but they need to be compared to the next best option. I think for a lot of people on these drugs the next best option is continuing the status quo which has a lot of negative health outcomes as well.
I can't imagine what would happen if federal agents killed someones son, wife and dog in a firefight when executing a warrant based on a crime that looked like entrapment while a Democrat was in office.
for phones its a bit difficult because i don't think you can egress out ip traffic without root or jailbreak on iphone and iOS. but i guess on desktop this should be possible
like its similar to connect or socks proxy except it is using SSH as a transport layer instead of TCP as a transport layer and its doing it transparently without having applications to be written to use the proxy. but if you are just converting TCP packets into a datastream and then sending them somewhere else where you convert them back to TCP packets then this is what this TCP RTT strategy is fundamentally meant to detect. i suspect the TCP only RTT thing works because of the delayed ack behaviour of most operating systems and this will still happen with sshuttle unless you are explicitly using quick-ack. also, quick-ack just works around the TCP-RTT issue and not the differences in timing between TCP and TLS or other higher protocols. i think if you are testing for other RTT differences then quick-ack would make them more obvious.
also, if you have an sshuttle proxy this site cannot detect it may be due to how close the server is to the client. i have a CONNECT based proxy it is able to detect around 5% of the time (maybe only that often due to a bug) but this is because there is probably less than 10ms latency between the proxy and the client and probably around 50ms latency between the proxy and the server for some reason (?).
i would say the c-code is broken because the queue push method has undesirable behaviour when capacity is reached. for example if you push onto a full task queue then it just leaks a task without any feedback to the caller that something very bad has happened. you don't even need to look at the method body to see there is something weird going on. because its a fixed size task queue with a void return on the enqueue method. though, i guess its possible the task queue could be resized in the body.
probably, the push method should return a boolean indicating whether the task could be enqueued and if the capacity is reached then the task is not enqueued. but this is c so its very easy to write buggy code :) also, in this case the caller has no obvious safe way to check whether the queue method is safe to call so the author can't claim its up to the caller to verify some pre-condition before enqueuing a task.
