I know we’ve discussed this briefly over on the Adobe-Dev Slack (thanks, Kerri), but I’d like to bring it up here for visibility.
If we’re going to monetize plugins, we’ll need some way of “registering” a plugin on its first use, and thus we’ll need some unique ID for the Xd user.
I realize access to the Adobe ID (which is also an email address?) is fraught, but perhaps the plugin API could just provide a unique identifier (the internal unique ID for the Adobe ID itself, or some transformed version that’s still unique)?
Hi @cpryland we’ll be adding support for commercial plugins in the future, though the timeline is still TBD. First step will be linking plugin acquisition to the user’s profile automatically - we do this already for other CC extension types through the Adobe Exchange. This will also ensure that users who install a plugin see that same plugin install on any other device they might be using.
@cpryland I’m not sure if this could help you but you could generate an UUID yourself (eg. using https://www.npmjs.com/package/uuid-random) and store it in the file system, then use that “installation id” to authenticate your users server side while bootstrapping the plugin.
May I ask what the Use-Case of this would be? I can go along with a unique identifier for users (for licensing implementations), but I don’t see why user details would be necessary in a lot of cases:
it’s clearer for users what data gets processed by the plugin if they have to enter it in the plugin manually (instead of just clicking Allow for the sake of getting a plugin to work)
if user details are relevant for a plugin’s feature, that could probably get achieved with OAuth? (again: making data exposed to the plugin more obvious to users)
In my opinion, the one thing required, as stated in the original request (and your first bullet point) is an anonymous “derived” unique user id. It is required because it can’t be solved by plugins in another way.
User details, on the other hand, can get solved in other ways. It is not the case that plugins require “automatic access”, in a sense, to these details to work. If a plugin needs these details, users can explicitly enter them. This, then, makes it much clearer than a popup Plugin XY requires access to your user data to work which data actually gets processed by the plugin. In my opinion, the manual way, in this case, is the better way. Too big would the implications for user privacy be if access was just one click of a button away.
Playing the Devil’s Advocate for a bit: The knowledge (that’s not far away with user details) that a user (with a known email-address or something like this) is
using XD version X
from country X (in most cases traceable by the IP address of the HTTP request submitting these details to the attacker’s database)
speaking language X (one of the languages detectable by application.systemLocale
using plugin XY
opened a document at time XY
(optional:) the user’s name is X
probably subscribed to the Creative Cloud (at least the “targets of interest”)
would be retrievable by a plugin getting “easy” access to user details (e.g., the email) and could make for a pretty convincing phishing email attack (considering a user probably doesn’t think too much about clicking an Allow button regarding such access).