Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> perhaps a restricted selection of reviewed code could be available from a trusted service

again though, you've literally just described the Apple app store.

who do you imagine will do this review, they're probably going to want to be paid, right? Maybe we could impose an industry-standard 30% cut of the revenue and give that to the company who does the app review and hosts the authenticated code for download.

what do you imagine will happen if third-party apps are allowed to evade app review? Facebook was literally already caught using its dev credentials to get people to install a spyware version of the service... and if they had ever been allowed to do so officially, they would have instantly blocked the web version and forced you to download the spyware version. So we can't allow people to install third-party app stores to bypass review or else everyone bypasses app review and the app review process is trivially circumvented.

oh, wait, those are the two things people hate about the app store, so your service sucks too. why are you suggesting this "locked-in walled garden" garbage!?!? /s

walled-garden walls aren't for keeping you in, they're for keeping danger out. Everyone has always been able to leave the walled garden whenever they wanted - you can leave at any time you feel the balance of apple services vs google services has shifted. And the price of bypassing app review has always been $99 for a developer credential that lets you build and run your own apps.



> again though, you've literally just described the Apple app store.

I'm more describing debian repos. A non-mandatory trusted source for JS libraries. Perhaps the browser creators would like to fund it.

> walled-garden walls aren't for keeping you in, they're for keeping danger out.

Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".


> I'm more describing debian repos. A non-mandatory trusted source for JS libraries. Perhaps the browser creators would like to fund it.

No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?

Serious question, why would you even think that's an option? Why does Mozilla want to pay for doing code review for Facebook?

> Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".

as stated, if such a "couple of button presses" mechanism exists, the worst offenders will instantly demand that you use it and bypass app review/permissioning for them. Facebook and Netflix and the like have "network effect" to get away with it, if you want to use facebook to talk to your friends/family you will do this, or else you won't use facebook. We could certainly start unwinding some of these monopolies so there is no longer such a network effect - but I'd absolutely want to see that happening before we even talk about loosening app review protocols, not just "loosen app review, step 2: a miracle happens".

User choice already exists - the optional trusted source is you build the app on your PC and deploy it on your phone with developer credentials. But the mere existence of a broad-spectrum mechanism by which publishers can publish un-reviewed code guarantees its usage. Show us that you aren't stealing our movies, or else you don't get to watch movies. It has to be a user-driven thing - and that's exactly what exists.

And again, as I already said - this isn't a hypothetical, Facebook already has been using its developer credentials to get users to install spyware that they couldn't get through the app-review process. They already are exploiting the "user-driven mechanism" beyond the allowable bounds, if you hand them the blanket ability to deploy third-party software that bypasses app review, that's essentially curtains for the concept of app review.

Your magical fantasy world where everyone is a good actor and nobody malicious will ever just demand that users push the button to bypass app review is just that - a naive fantasy. In the real world, widespread sideloading is antithetical to the concept of app review, period the end. Sideloading has to be gated significantly enough that a typical user won't want to go through the hassle - like requiring a $100/yr dev credential to do it.

Let me put this in perhaps a different context: how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government? There are a lot of people for whom WeChat is not an option, it's just the "facebook of china" and everybody communicates over WeChat. It's not going to be very nice when you hand WeChat the ability to demand that you root your phone for them, or else you just don't get to talk to your family.


You seem to have gone off the deep end. I'm talking about being able to limit browsers to a known-good JS code repo, just as we often do with operating system package repos at the moment.

> No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?

I don't write javascript or target browsers, I'm looking for ways to protect myself (and others) from people who do, without just throwing out the entire ecosystem. As such that seems a lot like other efforts that browser-makers take on.

I don't know why you're jumping on to apps, root access to phones, sideloading or any of the other weird topics you seem to want to drag into the discussion.

> how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government?

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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: