[lblume]

The difference being that a client can be malicious, while e.g. a local file is assumed to behave with the same intent as another. Programs that run on one computer can always be statically verified, while the task is harder for server-client applications — the client could always be an untrusted impersonator!

[sophacles]

A local file can be "newly local" and have recently been saved from the network or via a usb drive, etc.

And assuming a file is going to behave with good intent, or even the same intent as another file of the same format, is bad. It's how we get jpeg/png/etc parsing errors. Its how we end up with PDFs that are also valid executables, and 1000 more issues.

[munchler]

This happens with local files also, and was originally called “DLL hell”. The mismatch isn’t malicious, but the effect is the same.

[JadeNB]

> The difference being that a client can be malicious, while e.g. a local file is assumed to behave with the same intent as another.

I'm not sure what it means to assume something about the behavior of a file, presumably thought of as a static piece of data, but I'd certainly disagree that a modern computing system is entitled to assume that all local apps behave with the same intent as one another (except to the extent that it assumes that all local apps behave maliciously).

[denkmoon]

What does that have to do with type safety though? If anything, type safety improves whichever piece of the puzzle you do have control over by reducing the likelihood of you accepting malformed data.