Wouter Verhelst :wouter Reporter
	Description • 7 years ago

Now that bug 1357391 is merged, I've been working on providing a WebExtensions version of my "Belgium eID" add-on [1][2]. Adding the PKCS#11 module works flawlessly (at least from the POV of the add-on; we haven't updated our installers yet to write the manifest files). Additionally, I've updated the add-on to use the notifications API to tell the user when the module can't be found, rather than a browser notification bar as before.

[1] https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/?src=ss
[2] https://github.com/Fedict/eid-mw/tree/master/plugins_tools/xpi/new-src

In order to help the user debug issues when authentication failed, I wanted to additionally also add a content script to allow page scripts to talk to the add-on, and get information from the add-on, such as the result from the isModuleInstalled() and the getModuleSlots() calls.

Unfortunately, it would appear that adding a content script for ["<all_urls>"] triggers a permissions request for "Access your data for all websites", which is more than what I wanted to do, and would most likely trigger some red flags with some users (as in, "what kind of big brother stuff is the government doing that requires them to access all my data?").

Obviously the description of the permission is correct. If an add-on has access to the DOM of all pages that are loaded into the browser, then it can indeed access all data on all pages ever. But if all the add-on wants to do is use the window.postMessage() API to talk to content scripts (as in my case), then having the permission say you're accessing all data seems suboptimal.

It would be great if firefox had a way for page scripts to talk to an add-on without triggering this permission request; either by having a more constrained version of DOM access that allows window.postMessage and the onMessage event, or by having a different API that does not require DOM access at all.

	Wouter Verhelst :wouter Reporter
	Comment 1 • 7 years ago

This could be provided if something like chrome's externally_connectable stuff would be implemented, but the rumour mill tells me that this was looked at and discarded as not a good idea.

Not sure why, can't immediately find any references to it, either.

	Wouter Verhelst :wouter Reporter
	Comment 2 • 7 years ago

I might be interested in implementing this (although it would be after hours this time around, rather than during billable time), but would need some guidance as to what would be an acceptable way of doing so... anyone? ;)