[1]

I think that's what you mean by digest, but maybe you just mean `type` = `magic number`

Though, in fairness, that is /kind of/ like transmitting it---in the sense that it impacts the message that is returned. It's more akin to sending a checksum of the magic number, rather than the magic number itself. But conceptually, that is just an optimization. The desire is for the client to ensure the server is using the same magic number, we just so happen to be able to overload the signature to encode this data without increasing the message size.

It seems like Horton Principle just says "all messages have ≤1 meaning". If a message signed by key X must be parsed using the canonical encoding, then aren't we done?

There is still room for danger. e.g., You send `GetUserPermissionLevel(user:"Alice")` and server responds with `UserNicknameIs(user:"Alice", value:"admin")`. If you fail to check the message type, you might get tricked.

Maybe it's nice if it was mathematically impossible to validate the signature without first providing your assumptions. e.g., The subroutine to validate message `UserNicknameIs(user:"Alice", value:"admin")` requires `ServerKey × ExpectedMessageType`. But "ExpectedMessageType" isn't the only assumption being made, is it?

You might get back `UserPermissionLevel(user:"Bob", value:"admin")` or `UserPermissionLevel(user:"Alice", value:"admin", timestamp:"<3d old>")`. Will we expect the MAC to somehow accept a "user" value? And then what do we do about "timestamp"?

Maybe we implement `ClientMessage(msgUuid: UUID, requestData:...)` and `ServerResponse(clientMsgUuid: UUID, responseData:...)`, but now the UUID is a secret, vulnerable to MITM attack unless data is encrypted.

It seems like you simply must write validation code to ensure that you don't misinterpret the message that is signed. There simply isn't any magic bullet. Having multiple interpretations for a sequence of bytes is a non-starter (addressed in the post). But once you have a single interpretation for a sequence of bytes, isn't it up to the developer to define a schema + validation logic that supports their use case? Maybe there are good off-the-shelf patterns, but--again--no magic bullets?

> So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages. Most technologists who work with PGP don’t understand it at a low enough level to see what’s wrong with it.

without citation. Such a writing choice makes me pause.

> NASA’s initial instinct was to cover up the problem.

to at least warrant a link.

It makes sense after you understand, but I had to read the headline several times before it parsed.

I do have concerns regarding the proposals for scaling personalized medicine. They mostly boil down to "how do you scale the skill set required to operate in high-noise-low-signal domains". In my experience, these are places where poor data/incentives/critical-thinking can easily overshadow the signal; e.g., compelling stories outnumber correct stories.

There seems to be a trade-off: you can walk a bit further than others by keeping the probability distributions for low-quality results in your head, but go too far and everything starts getting overwhelmed by noise. It seems like the FDA's heavy gatekeeping is one way to solve this problem. If you forgo that gatekeeping, then you probably need to deal with the cascading quality issues that result.

Personalized treatments will probably be much harder to evaluate. At least a black-box algorithm that maps `situation → suggested treatment` can have statistics applied to it. But how do you evaluate "individuals made their own decision; here's the list of `situation × outcome`"? Or is the idea that there's currently a wealth of good-solutions, and that we should be relaxing regulations for a while?

Or perhaps we just want to push the regulator burden from "before small trials" to "before medium trials"? Then, these will be treated as case studies: good for experts to pull ideas from, but not high quality evidence for proving anything the third parties? I notice that your diagnostics were numerous, but the treatments were sparse and more sequential than parallel. If that's the norm, then maybe fairly usable data will emerge.

Or do people just have a moral right to seek out their own treatment, regardless of footguns that may be lying in wait? For myself and my loved ones battling cancer, I deeply agree with these:

> Maximize survival instead of the current practice of minimizing liability to the practitioner

> Parallel treatments wherever reasonable, we don't need to know what cured you

But I'm also glad that daily medical decisions are highly standardized and quality-controlled. It makes it easier to trust my doctor (or my loved ones' doctors) without independently investigating each recommendation.

I'm a fan of PR #2 "be less evil"

> If we were using this in some kind of automation, the last thing I want is it to blow everything away by accident. Probably should fixup the sql injection one too...

  -  "/dev/null; rm -rf /\*; echo",
  +  "/dev/null; touch /tmp/blns.fail ; echo",

When you run VS Code, it spins up a local language server that is capable of making code changes. That is how refactoring python works in many editors (including VS Code).

A website that you're browsing could potentially send requests to this server asking for code to be inserted that fully compromises your device. What keeps us safe?

- maybe the website is only allowed to send GET requests, not PUT requests, and maybe the language servers that you're using are all "hardened" so that they will never permit mutations via any get requests, and never have a misconfigured CORS header

- the website has to guess the correct port and the correct language server with a known vulnerability

- any website doing this on a large scale would likely get the language server patched and the website on a block list

- there might be other safeguards that I'm not familiar with. For example, I believe that Chrome disallows this by default

So now, here's my frustration: these two statements seem hugely at odds with each other:

> I'm ok getting pwned every few decades if the tradeoff is never worrying about this shit.

> (i will say putting a device not running open source software/firmware or something very locked down like a phone on your LAN is insanity, i could never)

I'm ok with a person who makes either statement. I'm also ok with a person who makes the first statement, and also wants their LAN locked down. However, I do not feel as though the a LAN ever needs to be locked down unless a person in running a server on the LAN network. Personal devices (like laptops and phones) are plenty capable of resisting malicious networks by default (coffee shops, university wifi, etc). What else is on a LAN?

> mind virus it's the paranoia all security people get

I generally agree with you, but I feel as though I am the one who has accepted that personal laptops need to handle malicious networks, and I'm generally comfortable with that. I don't worry too much about putting IoT devices on the same network as my personal laptop, nor about connecting to coffee shop wifis.

> I know this may seem trivial for many here but how can regular people easily check and debug their network for stuff like this?

"Stuff like this" is very vague.

- If there is a device on your network that is occasionally sending requests to the internet, then it generally isn't hurting you. That's why security is weak here, because the person buying the device is not harmed.

- If you're worried about the device sniffing your local network, then "normal people" are typically safe. Computers that you use are typically safe from malicious devices on the network, and you're in no more danger than working at a coffee shop, hotel, or university network.

- If you're knowledgeable enough to be a danger to yourself, and need the local network to be safe to protect yourself, then there is definitely a longer conversation to be had.

Responding point by point (before I realized that you were asking for yourself, and not the average person):

> Regular people download shit all the time though?

This is fair, though on macOS, most people download apps from the App Store (macOS makes it difficult to run apps downloaded from the internet and not signed by a registered developer).

> Especially now with GPT, everyone is a programmer pasting code into command line.

I am trying to reference a group of "regular people" who definitely do not fit this description---something like "the average citizen in the developed world". My parents definitely are not writing code with AI and pasting it into the command line. Although this was not crystal clear in this comment chain.

> And how many people have IoT devices that they have to connect to WiFi? That’s total blind trust.

My point was these devices do not endanger things that regular people care about. Their computers are still just as secure as when they visit a coffee shop or connect to their university wifi.

> Every time I ask this question nobody is able to give me a solid answer :/

for stuff like this?

I've heard that releasing these sorts of data sets help competitors do market research, and thus mitigates "winner takes all" forces. NYC also tends to be fairly pro-public-datasets: https://data.cityofnewyork.us/browse?%3BsortBy=most_accessed...

https://blog.xlab.qianxin.com/kimwolf-botnet-en/#network-pro...

That article has a more technical lens. It focuses primarily on the size and detection evasion methods of Kimwolf, rather than some notable (and definitely not unique) method of spreading.

Without looking too deeply, I'm going to assume that this is a successful botnet because it managed to get into product supply lines at big box stores and in app store games, rather than some clever virus that is spreading across the world.

I hope someone will correct me if I am mistaken!

Just don't run code you download from the internet or put your passwords to important accounts into cheap devices and you'll be fine. Normally people don't the the former, but sometimes do the latter.

edit: To be clear: the bitterness in this comment comes from how many developers assume loopback is secure. However, most website are allowed to send requests to local ports on your computer (IIRC) so that assumption is basically completely false. This is forgivable, except in a world where every developer runs tons of extensions/scripts/open-source apps, and have next-to-zero blast-radius-reduction methods, it makes me sad.

If the Yankees hit a practice ball out of their stadium and into my house, causing bodily harm to a loved one, I wouldn't be satisfied with any of the reasoning in your comment.

More generally, people are allowed to take on risk as per their own appetite, but legal liability allows risk-hungry individuals to be incentive-aligned with everyone else.

Safetensors is supposed to be the successor for distribution. I believe that it's the "safe" subset of pickle's data format.

  I_ACKNOWLEDGE_THAT_THIS_CODE_WILL_PERMANENTLY_BREAK_ON_2022_09_20_WITHOUT_SUPPORT_FROM_TEAM_X=1

  _AND_MY_USER_ID_IS=""

  | Distance | # of Sensors |
  | 1        |            1 |
  | 3        |            9 |
  | 5        |           25 |
  | 10       |          100 |
  | 25       |          625 |
  | 50       |         2500 |
  | 100      |        10000 |

It seems like, due to the inverse square law, the main issue is how close you can get your eye to a LIDAR sensor under normal operation, not how many sensors are scattered across the environment. The one exception I can think of is a car that puts multiple LIDAR arrays next to each other (within a foot or two). But maybe I'm misunderstanding something!

Also, I think that some strategies, such as “comfort asking a parent for help navigating a situation” are timeless defenses against strategies like blackmail. There are probably some street smarts that change and some that stay the same.