Determine security model for labeling plugins in UI

[danfinlay]

Our current beta somewhat punts this issue: When referring to a plugin, we name it by entry-point (which is the most secure string we can render, but is not totally human friendly).

There are other points in the UI where we'd like to more gracefully refer to a given plugin, but we need to ensure:

• Plugins cannot impersonate primary MetaMask UI
• Plugins cannot impersonate other plugins

This issue will represent a place to discuss ways of ensuring users have the most friendly and secure labeling of plugins in our UI.

A few ideas:

• During plugin installation, one permission can be "To present itself as [X] in your interface" (this could be defined by the name field in the plugin manifest).
• We could give users the opportunity to locally nickname a plugin at install time or later.
• We could deterministically generate a security background pattern that is force-rendered under all UI provided by a given plugin, along with a MetaMask-secured icon/button for getting more info about the info source.
• We could maintain a sort of name registry, which we allow for labeling.

[crazyrabbitLTC]

Off the top of my head I guess a question is, how permissionless should this be? Certainly MetaMask makes a number of assumptions about how it's run, maybe the ability to control plugin identifications could simple be another one of those.

I imagine that at the start at least the number of plugins will be relatively small. The most secure way to prevent the listed problems would be to simply keep a record of those plugins yourselves and then the UI will only load registered plugin UI labels. You could still allow for non-registered plugins, but they could get a warning like when installing test-flight apps on the app store.

This way you can allow this sort of UI sooner rather than later, but give yourselves time to grow into handling the problem for when it becomes an issue (thousands of plugins requesting access). And it should not be seen as vetting the security of a plugin, only permission to have a custom label and that label should be solely controlled by the MetaMask registry. That way it's fairly easy to review a plugin request, and it's not possible for malicious behavior.

[danfinlay]

That's a pretty acceptable approach, and may be just what we need for our initial releases, when we'll probably be permitting plugins on an as-registered basis, but we should also consider longer term solutions here.