Although that's pretty rare, it's a security vulnerability that we're more wary of nowadays due to supply-chain attacks. You still have to check new releases, but it would be even worse if old, widely used code were modified to mine crypto or something.
Go ran into a similar problem because 'go get' would import directly from source control systems. For GitHub that's mostly fine, but other hosts are sometimes less reliable. They solved it with a indexing proxy server. You can still turn it off and download directly from source control, or swap in your own proxy server, so it's less centralized than jsr.io.
In practice, most people use the default proxy server, so on most days, jsr.io should work just as well as Go's solution. But it's nice to have alternatives.
For example:
`import { assertEquals } from "jsr:@std/assert@1";`
could be:
`import { assertEquals } from "jsr.io/std@1/assert";`
With this deno could assume https, as well as follow configs/redirects to get the correct import, then lock those correct paths using import maps (the logistics of this would need hashing out, but it doesn't seem impossible considering they do it with the "special" `jsr:` specifier).
It seems like this would maintain the same pros while avoiding the "special" specifier hard coding that exists now (seems to only be for npm: and jsr: right now; no github: for example).
[0]: https://github.com/denoland/deno/blob/8c2f1f5a55a2a9bb9e04c1...