Live data from Hacker News

Mozilla shouldn't copy Chrome's permission prompt for extensions

palant.de

41–50 of 77 posts

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#41
post #19

Earlier quoted context omitted.

I think the biggest trouble is that the vast majority of useful browser extensions need to read and/or modify the content of web pages. Often both. So the ability to "Read and change all your data on the websites you visit" is a really common use case for extensions in general. I'd love to see some user controls on extensions. A great many ad blockers have a feature built in that allows you to disable them on particu…

That's a great idea. The implementation could look similar to how Firefox handles plugins today, offering the option to "Always activate", "Ask to activate", and a way to say "Always allow for this domain". Other permissions could still be handled with the iOS or Android approach.

It's also old news. This kind of URL-based whitelisting approach is exactly what Greasemonkey does.

The problems with Greasemonkey come down to the same answer you'll find any time you're discussing extensions: the Firefox team is seriously underinvested in the ecosystem. Greasemonkey today is about as rough to use as it was years ago and almost has the smell of an unmaintained/abandoned project.

The point is: this isn't exactly an unsolved problem so much as it is nobody taking up the effort or interest to apply a solution.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#42

Chrome's permissions are not a panacea, but this article doesn't provide a convincingly better alternative. "code review" doesn't scale, especially at the level of a nonprofit, when users are submitting their own add-ons. It may be that code review has a role (it's a compelling argument), but knowing exactly what an add-on is doing is really important. One way in which it could be better: instead of "internet access"…

Mozilla Corporation has over 1000 employees and the same kind of perks and accoutrements of other Bay Area tech companies. The amount of revenue they've received through business partnerships is measured in the billions of USD. They sponsor events at hip venues with open bars and party-like atmospheres.

The picture of an overworked and frail non-profit has been out of date for nearly a decade now.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#43
post #19

Earlier quoted context omitted.

That's a great idea. The implementation could look similar to how Firefox handles plugins today, offering the option to "Always activate", "Ask to activate", and a way to say "Always allow for this domain". Other permissions could still be handled with the iOS or Android approach.

It's also old news. This kind of URL-based whitelisting approach is exactly what Greasemonkey does. The problems with Greasemonkey come down to the same answer you'll find any time you're discussing extensions: the Firefox team is seriously underinvested in the ecosystem. Greasemonkey today is about as rough to use as it was years ago and almost has the smell of an unmaintained/abandoned project. The point is: this i…

My understanding is that user scripts allow you to match based on the URL. It would still be a predefined set of URLs (or URL patterns) with a binary option for the user (install and accept everything, or don't). That's essentially what extensions do today.

zeta0134's approach would be to put the user in charge of building this white- or blacklist. Following the way plugins are currently implemented, this would allow you to say "I always trust this extension", "I don't trust this by default, ask me every time" and "I trust this extension for example.com".

This would definitely need some security UX testing, but it seems like a reasonable approach to me.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#44

Earlier quoted context omitted.

More like building a much more powerful, standardized, extensions API that is backwards compatible with chrome extensions (which offer relatively limited tools) It isn't copying, all the browsers want a standardized extensions system and they have agreed on using Chrome as a starting point.

More powerful? I though chrome's API was stupidly limited which is why firefox had better extensions (all of which they want to throw out).

That is not the case. Chrome's API is just a base. The proposal is to be able to handle most of Firefox's add-on ecosystem IIRC. The code would have to change, but the functionality would be the same.

There is a lot of misinformation out there about Firefox's switch to web extensions. Existing add-ons aren't going to be obsoleted immediately ; rather new apis will be added first, and then they will be asked to switch.

Currently Firefox add-ons often hook directly into the browser, which is hard to keep secure and makes it hard to evolve the browser.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#45

I once asked a Mozilla developer why does Firefox display "Adobe Flash plugin blocked on this page" notification when the page apparently doesn't use Flash at all and choosing either option (allow/block) doesn't impede its functionality or change the appearance whatsoever. The developer replied there are Flash cookies being set and it's possible an attack could come through them. When I asked if he knows about any su…

>what is the purpose of bothering the user about an attack vector if the attack is merely theoretical?

It helps keep the attack theoretical.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#46
post #45

I once asked a Mozilla developer why does Firefox display "Adobe Flash plugin blocked on this page" notification when the page apparently doesn't use Flash at all and choosing either option (allow/block) doesn't impede its functionality or change the appearance whatsoever. The developer replied there are Flash cookies being set and it's possible an attack could come through them. When I asked if he knows about any su…

>what is the purpose of bothering the user about an attack vector if the attack is merely theoretical? It helps keep the attack theoretical.

In what way?

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#47

Earlier quoted context omitted.

couldn't we just give adblockers an api for filtering network requests, that they could just decide to allow or deny requests? And then give them no other internet access? This seems like an API failure that common jobs for extensions can't be done without scary permissions.

The problem is, many adblockers also have a feature to disable certain DOM nodes inside websites, to avoid embedded ads or remove anti-adblockers. So you'd also need an API to filter out certain selectors... And the list of specialized APIs could continue on and on.

Apple kind of solved this problem with the Content Blocker API - all of this is defined in a 'static' list which is used by Safari to block certain things.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#48
post #31
post #22

Having spent some time looking at the code of popular Chrome extensions recently I was left really shaken about whats happening under the hood. Google's position seems to be, if a website can track you and monitor your behavior when you are on the page, then an extension should be able to do so too. But the extensions have a whole lot more capability. They can look at my history, bookmarks, all the fucking tabs I hav…

> At install time there is no reason Google can't say this extension uses Google Analytics to track where you are clicking etc and what data and how much data is being sent off everyday to god knows who. Let's say Google started to do this in a way that causes people not to want to use such extensions. Why do you think extension authors would stop using analytics as opposed to use some other analytics provider (that…

Then the extension would have to similarly say, on install, that it sends analytics to .

Which would make the user want to use them even less.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#49
post #3

Earlier quoted context omitted.

> It's safer for an ad blocker to read and modify a page if it has no method of exfiltrating the content. The problem is that being able to modify the page is a method of exfiltrating information - e.g. you can add an img tag triggering a GET to an arbitrary URL. I suspect it would be surprisingly tricky to try restricting page modification in such a way that information can't be sent anywhere the page wouldn't have…

couldn't we just give adblockers an api for filtering network requests, that they could just decide to allow or deny requests? And then give them no other internet access? This seems like an API failure that common jobs for extensions can't be done without scary permissions.

Chrome has an API for this, IIRC. They still need to connect to the internet to update their rule lists, though.

Re: Mozilla shouldn't copy Chrome's permission prompt for extensions

#50
post #48
post #31

Earlier quoted context omitted.

> At install time there is no reason Google can't say this extension uses Google Analytics to track where you are clicking etc and what data and how much data is being sent off everyday to god knows who. Let's say Google started to do this in a way that causes people not to want to use such extensions. Why do you think extension authors would stop using analytics as opposed to use some other analytics provider (that…

Then the extension would have to similarly say, on install, that it sends analytics to . Which would make the user want to use them even less.

There are self-hosted analytics solutions, and worst case, you can always reverse-proxy to Google Analytics. So the extension will say "MyExtension needs to comunicate with MyExtension.com" and nobody will know why.

(Unless you have a manual review process, of course.)

Post reply on HN