Whitelisting of instances / don't default to "Access your data for all websites"
Closed this issue · 2 comments
Background
I do my very best to avoid installing addons that request blanket "access your data for all websites" permissions.
For the small set of convenience features this addon provides, it really isn't justified to default to that permission-set.
Proposed solution
Ideally, this addon would install with permissions for a few gigantic instances (a few with ≥250,000 users, like mastodon.social …), and allow you to white-list additional instances as you visit them.
A good example of this behaviour is refined-github; even though you can use it on any domain (GitHub Enterprise installation), it doesn't ask for that permission up-front — it dynamically requests it once you attempt to use it on that GHE instance.
I am unsure whether that is possible, IIRC in the past host permissions could not be requested optionally, but given your example and what the docs say it seems possible.
The thing to consider here is rather the UX. So you want the user to enter the URL of all instances:
- with which they are going to interact, i.e. which they surf to?
- and whose, where they have their home account? (That is IIRC not technically required, as we don't need to inject code here.)
Remember that when they don't do this, the extension can do nothing, i.e. not even show an error or prompt the user to whitelist the instance when they surf upon one and desperately try to click the follow or other buttons. That means:
allow you to white-list additional instances as you visit them
The "as you visit them" part is not possible. This extension can only trigger if it has permission or if a part of the extension (like maybe a button or so - that is the active_tab permission it could have) is interacted with.
Ideally, this addon would install with permissions for a few gigantic instances (a few with ≥250,000 users
From what I know these are like literally seven instances/domains. That is is…
Given that the Fediverse is actually well distributed it may be obvious this would be very cumbersome as you would have to first whitelist an instance before you can interact with it:
- >= 100 000 users are 13 instances, which is not really better
- >= 10 000 users would result in 110 instances which would be way too many to ship and maintain
So where to draw the line? When is an instance "popular enough"?
There are many reasons against that I could quote, e.g. not getting into Fediverse politics (some instance admins may complain etc. about an unfair disadvantage), maintenance (the list and the add-on would need updates) the biggest hurdle IMHO stays the UX for the actual user. Even if we were to do that, the user:
- would potentially have to approve the add-on updates each time that list gets updated and approve random domains they may not even know
- to judge whether a list of like 50 or 100 domains is safe for the extension…? (actually Firefox AFAIK abbreviates that anyway in the permission prompt then)
Now the only trick that I could think of that may help a bit would be to whitelist e.g. whole TLDs like *.social that is very popular for Mastodon instances. But really? Is that a way? I mean it's not like all instances are in there and what about the missing ones? If you enter .social in the search for the instances with >= 1000 users here you find only 28 out of these have that TLD apparently, so we have not gained a lot. Also TBH, if I'd personally saw such a permission prompt I would feel ridiculed, like that TLD is not the property of Mastodon… 🙃
The big difference to refined-github I see is that that extension is like 99% for users of github.com and the ones having GitHub Enterprise are a niche and additionally likely also technically more inclined and … after all… all this is what we don't have.
For UX reasons, the extension has to work out-of-the-box and as for the reasons outlined above. I guess we have to accept the fact that the Fediverse is distributed across many domains and instances (as it is supposed to be, after all) and this cannot work…
After all, why would you even want this?
The thing about trust
The thing is, if there was a way that may work to get a permission for all "Mastodon instances" I would have done that, of course. But it is just not feasable, so I have to earn your trust in another way.
This extension – like all my extensions – adheres to a strict privacy policy, which you can read in detail on https://addons.mozilla.org/addon/mastodon-simplified-federation/privacy/.
Furthermore, a detailed explanation of the permission this extension requests and why they are requested can be found on https://github.com/rugk/mastodon-simplified-federation/blob/main/assets/texts/en/permissions.md.
Also, in general, all add-ons are verified by Mozilla partly in an automated or manual way, see https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/#post-submission-review for details about that.
And finally, as for this extension, you can be sure it is not malicious, because you can also check it's source code and even confirm it is the one you download on AMO as WebExtensions are in essense just ZIP files.
So there is unfortunately not more I can do, and I hope you understand that it is just not feasible and would result in a huge UX disadvantage if that were implemented. The extensions aims to work semingless and in a way, so you can forget it is even there. As such, thanks a lot for that feature request, but this is not going to happen, unfortunately.
I agree about almost everything you said — whitelisting instances does indeed seem A. political and messy, and B. technically challenging and maintenance-heavy. Non-starter.
(Well, unless you implement the below, and just include “those 7” as a starter-pack, but ¯\_(ツ)_/¯ no strong opinion on that one.)
I do want to push back on whether it's valuable to be able to operate that way — “click the menubar button when browsing a new instance” is, absolutely, a jankier U.X. than the one currently implemented; but I do truly believe it's not that bad. Very do-able, for the folks who care about their privacy and security.
That said, one last comment is that this may not be the extension in which to deliver that alternative implementation — perhaps it'd be a good place for a fork. That also removes a 'configuration option' and/or additional onboarding-flow for “insecure users” — it puts that decision up-front, when browsing the AMO, and then the decision is encoded into which of the two installed extensions they have installed …
(An aside: I really appreciate your in-depth reply; that's fantastic OSS behaviour, and impresses me immensely with your dedication. (Also, makes me more comfortable using your extension until/unless someone has time to fork a 'more locked-down' version, haha.)