1271663 - Extension uuid is currently used as the messages and ports sender.id

Status: RESOLVED DUPLICATE of bug 1258360

(WebExtensions :: Untriaged, defect, P1)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

In our WebExtension internals, the sender.id of the messages and ports exchanged is currently set to the value of the extension uuid (which is generated locally when the addon is installed and it becomes part of the "moz-extension://" url) instead of the extension id (e.g. the one that is accessible to the addon through the "runtime.id" API property)

The extension id is present in the sender property, but it is named sender.extensionId.

In the current scenarios, which don't include any message that is coming externally, it has not been an issue, but with the upcoming onConnectNative, onMessageExternal/onConnectExternal features, it seems that it could start to have an impact, because the receiver cannot be able to check who is the sender of the message based on the uuid.

This issue is going to be used to track:

- the addition of the sender.id/sender.extensionId in the list of the current chrome incompatibilities
- the discussion related to the impact this issue has on the native and external messaging, and the impact that fixing this incompatibilities will have on our internals
- the review of patches which are going to fix it

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

During MozLondon we've briefly discussed this issue, and the other existent/potential issues related to the more general "extension uuid vs. id" issue.

Follow some notes about the topics discussed, which are just a starting point to discuss these issues further, and it is going to be probably integrated or fixed in further comments if something is missing or wrong from the point of view of the other participants of the meeting:

## uuid is used as the origin of the moz-extension url:

this can create a fingerprinting issue: 
the extension uuid is generated locally when the add-on is installed for the first time (and currently it will be the same uuid even if the addon is uninstalled and re-installed on the same profile, because the uuid is generated and added to a map saved in a preference and it is never deleted), and it can be used to recognize a new user profile from an already seen user profile.

On the other hand, in some cases a webservice could prefer to know the origin of a WebExtension in advance, e.g.:

- some webservices could want to use the origin which has originated the request to detect when the request seems to be originated by their own addon installed on the browser side.
- some webservices wants the oauth token callback url to be registered in advance by the developer

a potential workaround/solution mentioned during the meeting was to use for the web_accessible_resources a different scheme and the per-addon id as the origin (or something generated from the addon id if the addon id is not a valid origin, e.g. when the addon id is in the old email-like format).

### onConnectExternal / onMessageExternal

it has been mentioned during the meeting that, besides the issue described in the summary of this issue, by including "chrome-extension://id" urls in the manifest (e.g. in the permissions?) has an effect on this feature.

The above seems to be an undocumented feature, it needs to be double-checked (e.g. if exists on chrome then: how many important add-ons are actually using it? how it works exactly?)

### add-on id and transition existing addon to WebExtension

Given that the extension id is now optional in a WebExtensions add-on (and that the generated one is in a format which is completely valid as an origin), the only WebExtensions add-ons that cannot use their current add-on id as a valid origin are the existent add-ons that are going to transition from a legacy add-on to a WebExtension add-on (because they need to be recognized as the same add-on so that the new WebExtensions add-on is able to upgrade the old add-on).

Comment 2

[nhopper]

+1 - some webservices wants the oauth token callback url to be registered in advance by the developer

Comment 3

[Andy McKay]

Based on the chat in the WebExtensions meeting this morning we spoke about moving forward with making these ids deterministic, or the add-on id. Andrew raised the question of how what we would do for old WebExtension add-ons that depend upon this uuid and pointed out that we might have to keep the old mapping code around for a long time to provide a decent deprecation plan.

Andrew also said he'd take this bug on, so assigning.

Comment 4

[Andrew Swan [:aswan]]

Yep, at least off the top of my head, there are two things we need to resolve:
1. What do we do for extensions that have a "something@domain" style id?  My naive assumption is that plopping those into moz-extension:// urls is going to confuse the URL parser into thinking the URL has an embedded password.  We could hash the identifier and make it look like a uuid but then we have a problem that I could find a popular extension and register an extension with the hashed uuid.  AMO wouldn't know enough to consider it a collision (though we could add that logic to AMO) but the two extensions would collide locally (ie, my extension could see storage created by the original extension, receive messages meant for it, etc)

2. What do we do for extensions that have existing uuid mappings?  If we're ripping this out, ideally we could avoid maintaining the mapping code forever but extensions that were installed with a mapping will have storage etc. keyed by their mapped id.  I'd like it if we could migrate to unmapped, we could store an "identity" mapping in the uuid mapping preference in case somebody upgrades to a build that does the migration then downgrades back to an older build.

Kris, you already have a ni? on this bug but re-ping with the above questions.  And of course if there are other things to think about here, now would be a great time to raise them.

Comment 5

[Andy McKay]

(In reply to Andrew Swan [:aswan] from comment #4)
> 2. What do we do for extensions that have existing uuid mappings?  If we're
> ripping this out, ideally we could avoid maintaining the mapping code
> forever but extensions that were installed with a mapping will have storage
> etc. keyed by their mapped id.  I'd like it if we could migrate to unmapped,
> we could store an "identity" mapping in the uuid mapping preference in case
> somebody upgrades to a build that does the migration then downgrades back to
> an older build.

We could allow a developer to store a id in the manifest to give them access to the old storage and gradually deprecate the old mapping. But that would run into the problem you've outlined in step 1 where you could use someone else's id.

Comment 6

[Bob Silverberg [:bsilverberg]]

(In reply to Andrew Swan [:aswan] from comment #4)
> 1. What do we do for extensions that have a "something@domain" style id?  My
> naive assumption is that plopping those into moz-extension:// urls is going
> to confuse the URL parser into thinking the URL has an embedded password. 
> We could hash the identifier and make it look like a uuid but then we have a
> problem that I could find a popular extension and register an extension with
> the hashed uuid.  AMO wouldn't know enough to consider it a collision
> (though we could add that logic to AMO) but the two extensions would collide
> locally (ie, my extension could see storage created by the original
> extension, receive messages meant for it, etc)
>

It sounds like it would be a requirement to prevent an add-on from being added to AMO or even signed if it has an id that conflicts with the hash of an existing add-on. If that were in place it would eliminate the issue, though, wouldn't it?

Comment 7

[The 8472]

(In reply to Andy McKay [:andym] from comment #3)
> Based on the chat in the WebExtensions meeting this morning we spoke about
> moving forward with making these ids deterministic, or the add-on id.

Does that affect web-accessible resources? If the UUID is constant for all machines couldn't web-content probe for the presence of the addon through known URIs?

Comment 8

[Kris Maglione [:kmag]]

For UUID-style IDs, let's just remove the braces. For email-style IDs, we should probably just do what we're doing for storage keys, and replace '_' and '@' with '_' and a character code.

Comment 9

[Andrew Swan [:aswan]]

(In reply to The 8472 from comment #7)
> Does that affect web-accessible resources? If the UUID is constant for all
> machines couldn't web-content probe for the presence of the addon through
> known URIs?

We could potentially leave web accessible resources out of this, but they pose a problem either way.  If we use the original ID then yes, as you say, content can easily test for the presence of an (enabled) extension that has web accessible resources.  But if we keep the current behavior, then any time content gets a handle to an extension resource, it gets trivial browser fingerprinting for free.

Comment 10

[The 8472]

how about treating them like blob uris and binding the lifetime of the uri returned by runtime.getURL() to the window object?

Comment 11

[Andrew Swan [:aswan]]

Dusting this one off again, the suggestion from comment 10 seems like a good idea but I'm concerned about overloading moz-extension: urls to refer to both mapped objects (ie web accessible resources) and unmapped objects (eg background page, popup pages, etc).  Even if we convince ourselves that there is no danger with ambiguity and that we can do lookups reasonably efficiently, this will simply be confusing for everybody (extension authors in particular)
Thoughts?

Comment 12

[The 8472]

Hard to say, there seem many small buts to adding yet another scheme, e.g. how their principals would interact or that the same resource might be exposed under two schemes and how relative URLs that worked before might not work now.

But I don't have a strong opinion on that. If having separate protocol handlers provides higher security benefits then maybe those complications might be worth it.

Comment 13

[Shane Caraveo (:mixedpuppy)]

My read on this is that the primary issue is the generated uuid.  I've used applications.gecko.id in the manifest to force a consistent moz-ext url, and have used that for testing oauth as well as in a mochitest where I needed a known url to access.  The only downside to this is that I have to run the addon (with id in manifest) and dump the url to get the generated url.  If the web-ext tool could output the generated url, and AMO would validate the id in the manifest (during signing?), is there a problem here?  We've always had an id in addons, is there a reason to not use an id in the manifest?

Comment 14

[Andy McKay]

Need info-ing to comment on this bug, but taking off the 57 tracker.