> I don't know or care, because that's not within the scope of my suggestion, which is to have a default limit on where browsers pull javascript from.

Look, app review is a great model of the idea you're trying to think your way through - your idealized solution would look a lot like signed libraries and browsers would refuse to accept code that didn't come from a signed/trusted repo (the Library Store). This is no different from the App Store - it has been observed that the browser is evolving towards being an OS and the sites/libraries are the applications, and that's exactly what you've described, The App store for the web.

A lot of people find this model to be offensive towards user freedom, and allowing a mechanism to trivially bypass this essentially makes the exercise pointless, because then people just get conditioned to hammer the bypass button 20 times a day. Again, this has already been broadly explored by browsers - people rapidly learn not to pay attention to things like invalid certs if the mechanism to bypass them is obvious/trivial. Sites then learn that they don't have to care, because people will bypass them anyway, and the whole thing is an exercise in futility. Big red banners that say "you are about to sell your firstborn to Zucc, are you really sure???" do nothing, especially the 20th time you see them that day.

In your example: facebook would just tell you that if you want to use facebook, you need to add their repo. Done, no need for offenders to get library review ever, just need to have enough network effect to push the user to do it.

I'm not the only person who sees this similarity either, here's the previous comment in the chain:

> Nanny-state walled gardens like the Apple App Store?

Yep, precisely, you are proposing The Library Store. Mandatory library code vetting, only running code from the trusted Store repository. And it suffers the same weakness: if you allow a trivial bypass mechanism, it will be trivially bypassed, routinely. If you don't allow bypass, people think you're Turbo Stalin and accuse you of "nanny-statism".

Mozilla and the others doing this vetting still need to be paid too... so, is there some revenue they can get a cut of, for vetting code for all these random third-parties?

And if you want all of this to just be enforced best-effort on the honor system... I believe NPM already exists?

The "apt repo" model largely only works because there's no large player with a financial incentive to break it. Probably the closest thing is GPL-incompatible code where things can't get into kernel, and so they publish their own repos to get around it... if in your model the "kernel" is the "library store", your trustworthy source of "reviewed, clean code" and the reason the other stuff is incompatible is because it's shady anti-user code that's bordering on spyware and the apt-repo is resulting in malware getting onto user PCs then yeah, in that case, allowing "apt sideloading" would break the trust model there too. You might think "oh well, the user is boss" but you might have code like Facebook that is extremely peopular that people "have to" run even if it's unapproved for very good reasons, and as soon as you open this alternate mechanism you've instantly undone all your work on the review side. So restricting what developers can do actually results in an improvement in user freedom - GPL vs BSD/MIT in a nutshell.

> You seem to have gone off the deep end.

By the way, this is really uncivil. Yes, I have a very distinctive voice thanks to years and years of arguing on the internet. Think of it as Linusposting, hopefully funnier and less assholish, but bombastic, and it tends to leak through unless I make great effort to compress and filter everything I say. I do my best. You still have a responsibility to engage with the ideas moreso than how they're said.