Is there a way to hardcode a path to a directory of images without using the picker?
If the images are part of the plugin’s data folder, plugin bundle, or in a temporary folder, you can use
getTemporaryFolder, which won’t require a picker. Access outside of these locations, however, does require a picker at this time.
If you only want the picker to show once during a session, you can store a reference to the picker globally, and the access continues for as long as the document is actively open. (Plugin global state is maintained).
@shawn IIRC there’s a set number of persistent file references an application can use (on OSX? or Windows?). I had not heard of this before but if plugins need to keep their own file references that uses up the total allotted file count for the application.
@kerrishotts Do you know how this works? Should we open a feature request for plugins to keep persistent file references (between application close and open).
I think persistent file references without a security layer are undesirable: When a reference can “easily” get stored, it can also get manipulated by a plugin. This would allow for bad things again (if a developer abuses it) and therefore create a security risk (which we’ve already debated about in Run External Application from XD Plugin ).
Instead, I think XD plugins could use a permission system (similar to how mobile apps handle permissions). It could then include all those “tricky” things like access to the whole file system (without explicit permission by a user), running external applications and so on (later, when technically feasible, leaving the editing context, etc.). With it, things like hard-coded paths wouldn’t be a problem anymore since the user got warned before that the plugin wants to access stuff that might be harmful (if the developer cannot be trusted). Therefore, it would be up to the user to decide him- or herself what the plugin is allowed to do (resolving the issue of plugins being able to do stuff that could be potentially harmful silently).
All in all, hard-coded (and therefore maybe “saveable” paths) aren’t something I’m against (quite the opposite, in fact). I want to propose creating a security layer like a permission system for it beforehand to not make it the fault of plugins in general (and therefore harmful for all developers) if there should be a black sheep distributing malware (undetectable by Adobe’s review) at some point in time.
I guess I’m thinking of internal use more than creating a public plugin. I do a lot of scripting for AE and PPRO and I’m able to hardcode an internal folder structure for assets.
I understand the security risk for a public plugin but it would be nice to have the ability to do both.
Well, if you install the plugin it’s inferred that you at least read the description. People aren’t wildly installing plugins. There’s no drinking game where if you get a question wrong that you have to install a random XD plugin. Second, if you know what the plugin does (Export a layer to a GIF plugin)
and then in the plugin dialog there’s a button that says “Choose an export folder” it’s expected that if you want to export again in the future you don’t need to keep choosing that same folder.
Having said that I like having a permission system similar to what the browsers are using. The site runs fine up to point and when it requires a privileged system, for example, if it wants to give you notifications, the browser pops up a permission dialog for that privilege. You can grant it that specific permission and later at anytime you can revoke it.
The app world permissions on the other hand are mostly awful when you have to grant all permissions at install. It’s especially awful when you have something like a drawing app that wants GPS, network, and microphone access. Uh no thanks. I’ll use pen and paper. A per privilege permission system would fix apps like these. In a perfect world desktop, mobile and browsers would have per privilege permissions.
However, if my intentions were malicious, I wouldn’t say so in the description. There are many mobile apps, browser extensions etc., which claim to do something different (and also do that), but do other, not so nice stuff in the background. As you’ve stated:
If there hadn’t been a permission system, no one would have known what this app does access. Therefore, I agree that a permission system would be necessary (may that be the way apps do it or the way a browser does it doesn’t matter too much to me – needed privileges can be explained in the description and if they aren’t, that’s the developer’s fault when people don’t install the plugin).
Especially as long as there isn’t a full-fledged review system for plugins in place (in which plugins with other intentions than what they claim can get “called out”), broader permissions without a (very strict) permission system are simply too much of a security risk – at least to me.
Especially in the field of design, where NDAs are a common thing and trust is a really big “issue” (or at least can be), it is vital for plugins to not have the ability to do “everything”. Also, things like saving the XD file can already be problematic (just imagine a plugin first deleting everything, then save the file and somehow crash XD). I’m not accusing anyone here to do something malicious with plugins, but where there is an opportunity, there will always be those who’ll use it. Therefore, with all these things that could get abused by plugins, I strongly suggest implementing an infrastructure protecting users before implementing such things – users’ trust is extremely hard to get back once harmed (which would critically damage the image of plugins for and even of XD itself). It’s better to be safe (and wait for a good implementation of things like this) than being sorry…
How to load an ImageFill from the plug-in package?
I’d like to add an example to my argument to show what I mean :
“Only” because I’ve implemented an (as anonymous as it gets) analytics solution for my plugins, an article recommending the plugin amongst others had already warned about using the plugin when there’s an NDA or something like this. I then contacted the author and he kindly added a comment by me about what data does and doesn’t get submitted to the description.
I’m not saying they aren’t right about adding a note about it (in fact, I rather like it since I myself am very privacy-oriented and try to be as transparent about it as I can). However, the fact that a completely transparent and “as anonymous as it gets” analytics solution already causes trust issues amongst the target group proves that we have to be extremely careful here – I don’t want to imagine what would happen if there was something actually malicious. As the article proves, trust is a big issue in this area and I want to emphasize again that if a plugin is open about what it does (as I’ve been by contacting the author), those things can get resolved (as in my case), meaning I don’t say something like this shouldn’t get implemented at all, but only that a trustable system has to be in place first.
That’s it there. People don’t know what info is being sent and to who and what it could be used for. They don’t know if you only want to see installs.
So right now there’s permissions in phones that show an icon in the menu bar when the GPS was used and it shows by what app. We know the data sent is (in the least) the location and the app using it. There’s nothing like that for apps using the network or other common privileges.
In a perfect world, if you choose to install someone elses software on your computer / device you should be able to see the data it wants to send and the location and allow or deny that privilege. It would obviously encrypt that data before sending it. It could then show you a list of apps sending or receiving data like the GPS history.
Can you elaborate more on your use case here? Once you have access to a
Folder, you can iterate over anything within it, so you can still work with multiple files and such. Furthermore, if you request
getDataFolder, you’ll have access to a writable folder specific to the plugin in which you can do anything you want. (You could also use
getTemporaryFolder for a similar case.)
Granted, this doesn’t address holding on to entry references across document sessions – we’re thinking about what we can do in this case, but even so, it’s critical that we be cognizant of the user’s privacy here.
For internal uses, you could perhaps explore symlinks to an accessible location without requiring a picker? That wouldn’t be useful for publicly distributed plugins, but it could be an option for internal workflow plugins.
@kerrishotts - So essentially, I can do everything I need as long as I use the file/folder picker right? I guess I can work with that.
Based on my understanding of what you’ve mentioned thus far, I think you should be able to do what you want with the existing file APIs as long as you use a folder picker. Let us know if there’s anything you run into problems with though.