Supporting free speech doesn't mean that you support absolute free speech without any limitation. We all have a lot of rights, and exercising those rights can impinge on the rights of others. Why would freedom of speech be somehow special and trump every single other right?
I don't know in English, but in French we have a saying: the freedom of some begins where the freedom of others ends.
I assume it would be obvious, but perhaps I'm mistaken.
Free speech in the USA is (supposed) to mean the freedom to do political speech without state ramifications (I'm not sure how well this constitutionally works for private companies). This obviously doesn't count credible threats, telling people to riot or be violent, etc.
Basically you have a right to offend people short of targeted harassment.
*This is obviously an oversimplification but I'm giving the HN the benefit of the doubt here, however misguided that may be.
> Free speech in the USA is (supposed) to mean the freedom to do political speech without state ramifications
I hear this a lot, and it's not actually true. That's what the first amendment means. The first amendment protects freedom of speech, but it does not define the concept of free speech as a whole, it just protects a form of it.
It annoys me when people assert that being silenced by a private entity doesn't actually limit freedom of speech, because they argue that the freedom isn't being restricted unless a government is doing it. I'm not necessarily for unrestricted free speech (because it often ends up being loud and obnoxious, and often silences other speech when it becomes a shouting contest, especially on the internet), but this very specific interpretation that the US Constitution's first amendment actually defines free speech has always bugged me as something logically unsound.
Ignoring the abhorrent treatment of women in Iran, using the current protest as a measure of popularity would be as faulty as using the Occupy Wall Street protests as a measure of popularity, or in Canada, the Convoy Protests.
Unfortunately, as far as most of what I can find on the subject, most Iranians (who live in Iran) are either indifferent or opposed to the people currently protesting in Iran and Iran has a majority population that is highly religious and loyal to the current government.
It's mostly in the big cities, like Tehran or Shiraz where the protests enjoy support and the population is more liberal, but outside of the big cities in more rural areas people are much more religious and supportive of the regime.
I am certainly welcome to be corrected on this though.
I don't think it's unlikely that there's more people in the big cities in Iran than there are outside, and that the people inside those cities should get laws that they agree with, well, even if the people outside the cities disagree with them
> I do not understand why homotopy type theory posts are so popular on this website.
It's easy. When you don't know a lot of math beyond college, but you see a post like this one, voting it up lets you pretend that you're in-the-know. "Oh yeah, I'm competent enough to upvote this. I know math." You may even end up fooling yourself into believing it. Same thing happens with physics, chemistry, linguistics... posts.
Both are non-mandatory, but the first carries the connotation that this is something the government thinks you should be doing, but the latter is more like a suggestion of something cool you may want to do, like visit the Vasa museum next time you're in Stockholm.
Yes, they are both voluntary, but the nuance is quite different. That ambiguity in nuance is a problem, given that "recommendation" is the strongest wording for a non-legal mandate the Swedish government will use.
> but the first carries the connotation that this is something the government thinks you should be doing
Unfortunately that distinction was deliberately obfuscated by the UK Government during the COVID crisis. They would issue "guidelines" that you could be arrested for violating. As I recall, they began as real guidelines, and morphed into legal mandates without ever becoming laws.
If I understand you correctly, the issue is that the Swedish government used jargon masquerading as a common word, and as a result people didn't understand the meaning. That's another example of jargon being a problem!
Yeah. The deeper problem is that the government needs more precision than common words offer.
Just as programmers invented programming languages to unambiguously express an idea, the legal system uses legal jargon to unambiguously express an idea. Getting rid of jargon means you need to express specific meanings some other way. The Swedish government chose overloading specific meanings to ambiguous words, which is really strictly worse than legal jargon.
Using fewer words introduces less cognitive load and drives your point better.
For example, you wrote "The advice [...] seems somewhat pointless to me." Well, are you saying that it is pointless, or not? I don't know you, so I don't know what your scale of pointlessness is. I don't know what "somewhat pointless" corresponds to. Is it a tiny bit pointless, is it a medium amount of pointlessness, something else? I don't know, but I have to think about it because you wrote a meaningless word in your sentence. And even once I have understood the sentence, I am left thinking: "well, if it's only somewhat pointless, maybe it's not pointless after all!"
The same thing happens with "key stakeholders": now I have to think about a hierarchy of stakeholders. What scale is being used? Who's key, who's non-key? Does the sentence apply to all stakeholders, only some of them?
Multiply this by a hundred occurrences in a long document, and you obtain something that will be more difficult to read. But government documents have to be readable by everyone: people whose native tongue is not English, uneducated people who have trouble reading simple texts, etc. And for what? Sugarcoating your text so that it's less assertive? Showing literary prowess?
This is not the reason jargon exists. What made you say that?
> It's the reason that the speaker used all of the tech jargon (launching a website). If they didn't do that then we would think they didn't know about websites.
Ostensibly it's to increase precision and allow experts to communicate quickly with each other. However that explaination can't explain phrases like "Ring-fence", "Let's take this offline", "360 degree feedback". All of those phrases have better simple English translations.
Jargon exists because specialists in a subject want to communicate quickly among themselves, instead of paraphrasing all the time. I'm a mathematician, if I had to use plain-English words instead of jargon in my papers, I would go insane. But my papers aren't meant for the general public (although they're welcome to read them), they're meant for a specialist audience. This is not the case of government websites.
Your not recognising jargon from other fields. All of those phrases have precise technical definitions.
For example "360 degree feedback" is when a manager's direct report is asked to give feedback about their manager. In other words you give feedback about your boss, often to your boss.
It doesn't really make sense as a phrase or metaphor. It should really be 180 degree feedback because if you turn 360 degrees you're facing the same way that you started.... But that makes it even better jargon. It signals that you've been on some management training courses.
Some government websites are intended for a specialist audience. I think it's great that the site for paying my car tax is very simple but I would not expect the instructions for using a government data API to be written in the same way.
I don't think anyone is saying otherwise. It's clear that the discussion is about general public-facing government websites. Something for which the intended audience is a large portion of the population.
I'm tired of installation instructions that consist of "curl | sh". Especially since this one just tries to detect the platform and downloads the correct installer for me. I know what platform I'm running, and I don't want to pipe the internet to my shell. In the end this is unpacking a tarball in ~/.rustup, I don't need the risk of running some bespoke script for that.
To be honest, the course suggests using apt since that's an easy security-approved way to install things on our computers (see https://en.wikipedia.org/wiki/GLinux).
I'll be happy to update it to suggest using rustup like "normal". Could you make a PR for that?
Since the ultimate objective is to run a binary blob that you just downloaded off of the internet, piping a script to your shell over HTTPS adds no additional attack surface.
And kibwen's point is that if you're in a situation where you're running potentially hostile binaries from a remote host, the fact that you used `curl | sh` to obtain said binary is not the pressing problem.
And where is this trust supposed to come from? I downloaded the thing manually, looked at the scripts, ran the binary in a sandbox, it seemed to be OK. Right, I'll recommend that everyone just curl | bash's it ...
I think the worst thing about this is that Rust is fashionable, so encouraging inexperienced devs think that these dangerous practices are just fine. Look around at how many n00b projects now suggest doing exactly the same thing. It's simply irresponsible of the Rust crowd to keep promoting it.
The bash timing exploit makes everyone focus just on how cleverly evil it can be, and forget the big picture that it's about trusting the Rust org not to screw you.
(BTW, you can run `curl | sh` in a VM or with a modified bash to intercept the code and catch the bash script in the act, so it's not actually as sneaky as people believe).
If you think the Rust org is going to pwn you in a clever sneaky way, then you can't use Rust or any Rust-containing products.
In the end, you're pulling hundreds of MBs of binaries that you won't review, they're compiled from over 15 million lines of code that I don't believe you'd ever review either. Reviewing just the first 10 lines of code gives you nothing. A smoke test in a sandbox is also worthless, since a binary could detect being run that way, or delay the attack, or attack by specifically miscompiling your code (see Reflections on Trusting Trust).
In the end, you have to trust the Rust org, all of it.
(Is it that you don't know of any yourself? Or that you think I can't provide examples? In what world is what I said even slightly controversial? Type checking is just catching on now, decades after it was invented and implemented. C'mon.)
"Trusting the Rust org not to screw you" is one part, another part is trusting the Rust server operators to defend against server compromise by any third party. So trusting the intentions is not sufficient.
The same thing applies to any binaries downloaded from their site, so unless you you've got signed binaries (that use an independently obtained/verified chain of trust), trusting the server is your your only option. Even with signed binaries, you're still trusting the entity that holds the signing key.
In real world trust is not so binary. In a risk assessment I'd be interested evaluating the level of assurance there is in the supply chain of how you get your binaries and artifacts. Some of it can be done using crypto like you say, some of it could be eg published audit reports from a reputable evaluator or other credible information about the processes.
piping to the shell might be somewhere in the middle but node's npx is just asking for trouble. You type `npx cmd` and it downloads cmd. Which means any typo could be death
You meant a binary blob in your distro's repository, so one that was checked, tested, approved and verified with a hash. Which is wildly different than downloading and running random binaries or scripts for that matter off the internet.
No, it's hardly random, it's an official binary provided the Rust project from an official domain managed by the Rust project. If you don't trust it, then you shouldn't trust the Rust source code either.
In this case, the Google internal course explicitly does not trust that random shell script, even if it came from rust-lang.org, while their internal apt repository is trusted. See https://news.ycombinator.com/item?id=34092187
When I'm installing package from the repository, it's signed with GPG. Hopefully in a more secure place than WWW server. May be even at offline server with HSM (one can hope!). When I'm running code downloaded from HTTPS, all it takes is compromising this WWW server (or AWS Cloufront for this particular sh.rustup.rs example). HTTPS adds additional attack surface.
Checking the hash isn't relevant here. The content is served via HTTPS, you either trust the host or you don't. A host can easily serve you a malicious binary, as well as the valid hash of that malicious binary.
Which is why many people choose to only install software from their trusted distro maintainers who add a layer of vetting for random software packages, often built from source so messing with the package isn't possible without leaving some kind of trace that can be detected later.
Indeed, by all means, prefer to trust your distro if they package a version that's new enough. Alternatively, prefer to build from source if you like. But if you trust the Rust project to be competent enough and benign enough not to include malware in the compiler itself, then it's not a stretch to trust their official toolchain juggling tool downloaded from their official website. Focusing on the curl | bash aspect is a tired meme at this point.
Your distro's overworked maintainer isn't reviewing 15+ million lines of code included in Rust.
Most likely they get the precompiled rustc binary just like rustup, and LGTM-YOLO the package. If they try to be diligent, they maybe take extra 150K lines of mrustc code they can't reasonably carefully review for backdoors either, and then use it to bootstrap the several sets of 15M lines of code they won't look at.
The one thing you may get in using your distribution is protection for the case that the rustup.sh website has been temporarily pwned. But I agree that focusing on curl | sh is nonsense.
I get what you are trying to say here but I could also make the argument that you actually doubled it because now you have to trust two things rather than one.
Depending on how you want to consider trust in a wider sense too it may even be worse than “double” because I do not have the same amount of trust for the package I am ultimately installing and the script I am using to install it.
> now you have to trust two things rather than one
No, you're still trusting one thing: the host itself. You're downloading both the script and the binary from the host. Both could be backdoored, and of the two, the binary is far easier to hide a backdoor in.
As for not trusting curl, you still need to fetch the resource somehow, so you're going to be trusting some tool to do it for you. That's not relevant to increasing the attack surface.
I’m not actually in the Rust ecosystem at all and only just discovered the domain belongs to the official Rust project.
That clearly changes the trust calculation in this scenario.
I had assumed it was some 3rd party project which would have put it in a different category of problems entirely.
But the entire conversation is kind of pointless then. “There is a secret backdoor in the official Rust binary” is not a useful part of any reasonable threat model.
> You're downloading both the script and the binary from the host.
Technically, if you don’t read the script, you don’t know the binary is from the same host.
That doesn’t matter, though. The chain of trust is deep, including the tooling that produced the binary, your CPU, the internet, etc.
Downloading the first file basically says “I trust this site to give me this tool and nothing else”. Where it then gets that stuff from shouldn’t matter, even if it is from a shady site. You trusted them not to do that, just as you trusted them not to open up their own site so that hackers can replace files ont it.
On some distros you can install rustup directly, e.g. NixOS or Arch. For Ubuntu, it's sadly not in the default repositories, but there is a snap for rustup uploaded by the rustup maintainer.
This is because people are tired of figuring out seventeen (hundred) different package managers that may or may not work and that may or may not accept your package into their repo?
I don't know in English, but in French we have a saying: the freedom of some begins where the freedom of others ends.