News for hackers. Stuff that matters.
Re:Introducing chrome.scripting by jolux on Tuesday June 08, 2021 @09:59PM (#27443383)
> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not?

In a purely ethical sense, absolutely yes. But we're coming up on 30 years of people using the internet, and it's been clear for a while now that you simply cannot teach people what is safe and what is not in an absolute sense. Even highly technical, experienced users still make mistakes and install malware sometimes. Informing users is not effective, to a first approximation. System designers have a responsibility to protect the users of their systems.

> If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.)

These overrides should exist, but making them too easy will just lead to malware tricking people into triggering them. And some doors are so frequently abused or fundamentally vulnerable that they probably should be closed entirely — most people don't think we should still be embedding Java and Flash in webpages these days.

Re:Introducing chrome.scripting by ROARosen on Tuesday June 08, 2021 @11:19PM (#27443857)
The problem with closing the API is that for even the most advanced users, it will now be impossible to get the (very useful) functionality these extensions provide.
Re:Introducing chrome.scripting by jolux on Tuesday June 08, 2021 @11:39PM (#27443965)
I believe it was tptacek who once commented half-jokingly that the ideal thing to do would be to leave the API open to uBlock Origin exclusively and kill it for everything else. The privileges required by that extension and others like it are indeed very powerful and often abused. This is not a problem with an easy solution, your suggestions are essentially the status quo and the industry is beginning to move on from it.
Re:Introducing chrome.scripting by the8472 on Wednesday June 09, 2021 @04:02AM (#27445402)
The issue with that approach is that the next addon developer who comes up with something as useful as uBlock will not be able to develop that. Legacy carveouts protect past innovations but not future ones.
Re:Introducing chrome.scripting by skybrian on Wednesday June 09, 2021 @02:56AM (#27445040)
Hmmm. I’m not implying anything here, but I’m wondering how we know we can trust uBlock Origin. How is its security vetted?
Re:Introducing chrome.scripting by ROARosen on Wednesday June 09, 2021 @09:15AM (#27447491)
Hmmm. You're invited to vet it yourself here: https://github.com/gorhill/uBlock
Re:Introducing chrome.scripting by skybrian on Wednesday June 09, 2021 @06:32PM (#27454151)
This doesn't help if it gets sold to someone else, as many extensions have.
Re:Introducing chrome.scripting by jolux on Wednesday June 09, 2021 @10:47AM (#27448501)
It’s open-source, and the author has a long history of supporting his product for free as an ethical good, even while some of his collaborators have went commercial and cashed out, once even taking the project name.
Re:Introducing chrome.scripting by pmontra on Wednesday June 09, 2021 @12:45AM (#27444308)
Mozilla went that way on Android when they broke all extensions about one year ago except a few blessed ones.
Re:Introducing chrome.scripting by shock on Wednesday June 09, 2021 @04:32AM (#27445578)
There is now a way to enable any extension in Firefox Nightly.