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.
But note that the general sentiment about at least the indie devs about the whole Exchange system is “meh” at best, even with all the improvements made this past year.
Perhaps that’s partly about un-discoverability that’s addressed in XD’s plugins “front and center” approach.
Totally understand. While more improvements are coming down the pipe for the Exchange overall, in-app plugin discovery is an area we’re investing heavily in, starting with XD.
But note that if XD simply gave us access to even a hashed Adobe User ID (unique to each user, but non-identifiable), that would be enough for us to hang a whole homegrown licensing scheme on.
As it is, we have nothing that isn’t trivially wiped out (e.g., by uninstalling and re-installing).
But note that if XD simply gave us access to even a hashed Adobe User ID (unique to each user, but non-identifiable), that would be enough for us to hang a whole homegrown licensing scheme on.
Ari (@afuchs), Kerri (@kerrishotts), any update on this? It’s going to be critical in the near future for us.
@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.
That’s an idea I’ve considered, but it doesn’t solve the problem of someone installing XD on two alternately-used computers.
If Adobe provided the uniqified but anonymous user ID, then we’d know it was the “same” user and thus would have no licensing problems with the second machine.
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).
I would not want this feature unless it gave the user full control of what info to share with the plugin.
My use case is for where someone purchases a license for a plugin at an external site and to verify the purchase the purchase email is compared to the Adobe user email or something along these lines.
And with both the anonymous or non-anonymous option is to make the Unique User ID specific to the plugin.
Meaning each plugin would be able to receive a unique user ID that is specific to their plugin or vendor so that it means nothing outside of the plugin.
Can’t commit to dates, but XD plugins tied to user accounts is something we’re going to be working on for post-MAX.