Recently, a news article popped up condemning the Rust programming language - citing "Significant Privacy Concerns" over the inclusion of build paths in production binaries. Unfortunately, while the spirit of the article may have been well meaning, and there are situations where the stated issue is a concern, the piece totally missed the mark.
The Real Issue
This piece outlines a convention that has existed for decades in virtually every native build system. Most compilers, including Microsoft's MSVC, the Golang compiler system, and many others also include absolute build paths by default, in order to enable other tools (such as debuggers) to work . While this could be an issue in certain situations - not the least of which being information leakage in some automated CI systems - options to resolve it have existed for years. While this is certainly less than optimal, and can definitely result in significant privacy considerations, it is evident that the original article's author did no research at all on the topic; not only did he miss the mark on the bigger problem (e.g., this isn't a "Rust problem" as much as it is a "conventions in compiled languages" problem), but he created a sensationalist piece that massively over blows the issue, and unfairly damages Rust's brand as a safe language.
If the author of an article about how terrible the inclusion of absolute paths in binaries thinks something like that is a big deal, wait till he learns that Microsoft has been baking build tool fingerprints into binaries for decades, or that some settings in languages like C++ can inadvertently leak detailed information about class and namespace hierarchies, or that other popular languages, such as Java or C#, feature enough reflection data that they can effectively be decompiled in many cases; not mentioning things like symbol data that many compilers also bake in! Does this mean we should cease using them? Absolutely not! It really means that, just like every other aspect of software development, understanding the tools used and default settings (along with security tradeoffs) is critical.
Why This Matters
Tech bloggers and journalists should focus on real issues. This seems obvious, but even within the space of "open source" and "programming languages," there is more than enough happening within the greater context of the community that poorly-researched fluff pieces like this strike a bit of a sour note.
Not only does this unfairly damage the public discourse around Rust (which is bad enough), but the article's author has a big enough platform that these sorts of publications have the ability to cause disproportionate damage to the language's image, and also muddy the waters around valid security concerns in general - especially given that the chief complaint here has also existed in virtually every other compiled language for decades.
While there are certainly valid concerns around using nascent languages (even though Rust, is now a few years old, it still falls roughly into that category when compared with its peers), not the least of which being tooling and ecosystem maturity, it is irresponsible to publish an overblown article about a relatively minor issue without even doing enough research to understand how it relates to the rest of the ecosystem at large; rather than being a general "privacy concern" across a bevy of languages and toolchains that has a very limited impact to most users, it blows up the issue - making it seem like a huge problem - and shifts the focus (inappropriately) to a single language/toolchain.