Hacker News new | ask | show | jobs
by matusfaro 1016 days ago
> Chrome's profiles are actually superior due to ability to have different extensions and history per profile

Interesting attack vector I haven't thought about which could leak information out of a network-locked Firefox Container. It would be under an assumption you have either:

1. A malicious extension installed (you have a much worse problem in this case)

2. A side-effect of an existing extension that leaks information to the outside world. (e.g. translate a part of a page, lookup a word in a dictionary, pre-fetch some images...)

> Firefox's containers are only useful if you want multiple logins

I think there are valid use cases for both Containers and Profiles. You can go down the list to have more and more isolation as needed:

- Grouping tabs to stay organized, no isolation

- Firefox containers, same browser window, shared history & extensions

- Chrome profiles, almost complete isolation within same browser (different processes)

- Separate browser instances

- Separate devices

1 comments

On extensions, for example, I use LanguageTool [1], which is similar to Grammarly. It could be configured with a local server, although I have a “premium” account which sends data to a 3rd party server. I trust this extension to verify my messages on HN, but I can't trust it to have access to my banking account. This is an example of a really useful extension that I'll never be able to fully trust because it has access to all websites, and it sends all that I write to another server.

In fairness, Firefox's advantage has been that Mozilla has a trustworthy manual review process for the “recommended” extensions.

[1] https://languagetool.org/

Note that languagetool doesn't need to request <all_urls> as a required permission, it could request hosts in optional_permissions (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...) or (likely better) it could use activeTab permissions since it really shouldn't have access to your HN page until you invoke it anyway. The MDN docs even bring this up as an example scenario:

> The extension may need host permissions, but not know at install time which host permissions it needs. For example, the list of hosts may be a user setting. In this scenario, asking for a more specific range of hosts at runtime, can be an alternative to asking for "<all_urls>" at install time.

What we're waiting on I think is for Mozilla to get rid of the ability for extensions to opt out of this system, because I think one thing we've learned from extension permissions is that most devs are lazy and will just request the broadest permissions allowed if they have the option to do so.

One thing I'd really like to see extended is for "trusted extensions" that have gone through manual review to have a harsher standard applied to them by reviewers about what permissions they really need to request. I would love to see Mozilla pushing back a little on extensions like Languagetool and having reviewers ask "why aren't these permissions optional?" I feel like it's a little bit irresponsible for Mozilla to put its signal of approval on extensions that are over-requesting access beyond what's necessary even if those extensions aren't currently abusing that access.