Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product.
There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running runs completly in a segregated zone/container/sandbox that will prevent, even in the presence of defects, its exploitation to leak data that is important to me.
I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.
As an end-user I care much more about security than I care about defects.
> However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.
Sure it can. It actively prevents certain type of errors (buffer overflows, integer overflows), which are prime security exploits. Less exploits == more security.
Risk analysis is typically done including both the probability of a problem and the impact of the problem. Not including the former in an analysis will result in spending vastly disproportionate amounts of effort on exceedingly rare problems, e.g. the consequences of a 1000ft tsunami hitting New York would be huge, but we don't build massive sea walls because it is also ridiculously unlikely. This applies perfectly well to digital security too: reducing the probability of an exploit is just as important as limiting impact if it does happen, which is why (for instance) Mozilla is doing both.
I don't think I want to get into what is or is not security, but what I will say is that rust's security does not interfere with safety net features, like sandboxing.
I've found that sandboxing rust is quite easy, as easy as C or C++. I find it much easier than Java/ Python, which have runtimes that can often make things difficult (you certainly would not want to use seccomp in either).
Take a look at DropBox's Brotli - it's a great example of this. It makes use of seccomp, but seccomp is not available on all platforms, so it also relies on rust's safety.
Defects can heavily affect the security of your assets though - just preventing buffer overflow is a huge win there. It just isn't a full solution to the problem of security in general, and I don't know that any such thing could exist, whether at the programming language level or otherwise.
> I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.
To me it seems like this is more of an implementation detail and not language-specific.
There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running runs completly in a segregated zone/container/sandbox that will prevent, even in the presence of defects, its exploitation to leak data that is important to me.
I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.
As an end-user I care much more about security than I care about defects.