System Call Access for UXP

Adobe XD UXP Plugin API
1

There’s been a lot of discussion about this already, so thought it would make sense to add a topic for it:

Basically, a lot of our tools make system calls (with system.callSystem() or childProcess.exec() in Node.js) to add functionality that wasn’t previously available in CEP or Node.js libraries. Since UXP won’t include Node.js, I suspect we will have to use even more system calls to add back in the functionality npm modules gave us. Far as I’m aware this isn’t currently possible in UXP.

One objection that @pklaschka brought up here is the security vulnerability with giving system call access to UXP panels. One possible solution to this could be requiring the user to grant access to plugins as they’re installed, in the same way the Apple/Android app stores do when you install a phone app.

If this functionality isn’t added when CEP is discontinued, dozens of our tools are going to die or lose a lot of their features. Thanks!

2 Likes
2

Would this be the same as calling a native process or command? I have a case where I’d like to call a command and if possible get standard out.

On granting access I have issues with app permission system where they pop up a screen asking you for all permissions before you install. IMHO it should grant access as needed and plugins should run whether you grant access or not. Some features would be disabled but that’s how browsers work. The web page prompts you for the permission as you need it. You can choose to enable them later.

So if app wants to export to disk it pops up a permission the first time you export for write access permission.

2 Likes
3

Yes, native process or commands like you would run from Command Prompt / Terminal is what I’m referring to. I use these all the time in my tools for certain functions that aren’t built-in to ExtendScript or CEP/Node.js.

Regarding permissions, I know what you’re referring to the way websites work with this like asking permission to use your webcam or mic. This seems kind of clunky though to have the user agree to several permissions during use of your tool. Honestly I think this could just be disclosed in your EULA when the user installs (as they would with a normal application), but if it has proven to be a security issue for people in the past, I think one confirmation screen for the user would be sufficient and the least intrusive.

4

The permissions would appear once the first time they were used. There has been some discussion on this here.

The reason for a per permission system is manifold. But after reading the privacy policies of numerous apps and looking at the track record consumer data protection I believe it would create a more secure ecosystem. I don’t know of anyone else who reads the EULA and even if they do they are often filled with jargon.

For example, if you install a marble madness like game app, and it requests accelerometer, but if it also requests mic access, network, and userid it might be selling your data. Unsavvy users, like grandma, have typically “granted all” permissions right at install without knowing what they were for.

Now imagine, grandma has 4 freemium games that are downloading video ads after every minute of game play. A lot of people all over the world have limited bandwidth. So she uses her bandwidth up in the first few days. So her nephew comes over and explains the situation. She says it’s ok to turn off video ads for 2 of them but the other 2 she wants to allow them to gain gems. So he turns off network permission for those 2 games.

1 Like
5

@justin2taylor

The problem is that people usually don’t read EULAs. With that being the case, it could be very problematic to have “black sheep” in the current plugin infrastructure since with no rating features, review section in the plugin manager and things like that, there is no real way to call a plugin out for doing malicious things (except reporting it to Adobe, where it would take time for something to happen, in which other users install the plugin and begin to have their doubts about the plugin ecosystem).

In all honesty, if it is clunkiness that’s required for better protection of users (who often have to be extremely careful due to NDAs etc.), so be it :wink: – I get your point, but I think that when weighing both sides of this, a system of “xy wishes to access feature xy, allow this time, allow always or disallow” simply has so much better protection of the users that it outweighs inconvenience (also, with single permissions at the correct time, designers under NDAs and such things can rest assured that nothing happens without their consent and that it is, therefore, safe to use plugins in all situations.

Also, having it split means users can agree only to the aspects needed for what they’re using the plugin for. Take the Twitter app for phones, for example. I’ve given it permission to access network stuff (for obvious reasons), but I’ve never agreed to let it access my camera and microphone (because I simply don’t use the features that need that). This allows for user control over what they need and want and for us as developers to explain why we need something. With the Twitter app, for example, it would be unclear to me why it needs to access my microphone when installing the app, but when I want to start a live stream, it’s fair enough that it requires such permissions.

See my example with Twitter above – sometimes, permissions might seem malicious out of context. It might be an idea to let the user decide how they would like to control permissions (per-request or all at once). This way, users who want or need that control have it while folks who just don’t care (for whatever reason) can “blindly” accept everything. That way (when something bad happens), it isn’t the plugin ecosystem’s fault when something happens and it, therefore, wouldn’t affect all other plugins as badly.

All in all, I can absolutely see how you think about it, but being the ethics-in-technology-oriented person I am, I simply have to say that at least for me, the risks outweigh the benefits of a “simplified” permission system and users should – in my opinion – have such control when something they install comes through a “simple” app-store-like plugin manager where they can’t be sure about the source. Don’t get me wrong here: I’m not saying you’re wrong, I’m just adding my opinion to this to hopefully get all of us to a solution that’s best for all of us (developers and users)…

A small proposal for how permissions could work:

try {
  app.getPersmission(PERMISSONS.RUNEXTERNAL, 
                     'to analyze the picture') // Throws if permission doesn't get granted
  // Do stuff with the permission
} catch (e) {
  // Handle "permission not granted"
}

This could then show a dialog like this:

The plugin “My plugin” requires permission to run external apps to analyze the picture.
Don’t ask me again
Allow – Disallow

This would allow us as developers to explain why our plugin requires a – otherwise potentially malicious-looking – permission. Depending on the user’s preferences. He/she could also get asked if he/she wishes to allow all of the permissions needed (specified in the manifest.json) when installing the plugin to be unintrusive if a user prefers that.

PS: Sorry for the long message – it’s just that I love civilized discussions about such things (especially when it comes down to user privacy and security) and this community is just great as it “allows” for civilized discussions (instead of taking things personally etc., which happens in many other online forums) :wink:

4 Likes
6

@pklaschka @Velara you guys both have totally valid points, however, this conversation is getting completely derailed from the proposed topic. Probably best to start a topic on permissions and continue this conversation there.

My main point is that any type of permissions solution (be it one screen, agree-as-you-go, etc) can work in this case and doesn’t stand in the way of integrating system call capabilities into UXP, a feature that is used in tons of CEP panels at the moment and will need to be addressed before CEP is discontinued.

3 Likes
7

While I agree that this isn’t the place for a dicussion solely about a permission system, it – to me – is an important aspect of this feature request, since it basically means that I “vote” for the request under said conditions for a permission system associated with it. Therefore, while an extensive discussion about the implementation of such a system would be out of place here, I tend to disagree that the conversation is getting completely derailed from the proposed topic – this simply is an integral part of such a feature and therefore (in my opinion) does – to a degree – belong here (especially since a permission system is only relevant in conjunction with features like this and therefore isn’t a feature request by itself) :wink: .

The thing is that I absolutely agree that such a feature is required for the API, but potential risks, ways around those risks and other aspects of such a feature do – in my opinion – belong here (and therefore also the permission system discussion).

Getting to another aspect of this: When should a plugin be allowed to make system calls?

What I mean is: Should those calls only get executed by plugins during the “editing timeframe” (i.e. the time when the plugin may also do changes to the scenegraph)? This gets especially important when panels “become a thing” in UXP and therefore, the question about when a plugin executes gets less and less “black and white”. One way to add a security layer (the question is whether this restricts this feature too much) would be to only be able to execute those requests on explicit user interaction (i.e., running the plugin) like we currently have for scenegraph manipulations.

If – however – such a restriction were be too restrictive (I – of course – don’t know all the use-cases), I think it would be wise to have an additional required permission of “running system resources from the background” (or something similar) to add transparency for users.

2 Likes
8

OMG. When this come into Photoshop… Thanks god I am working in private sector so I can use custom .exe installer same as now and run external app in different ways. And skip all these security things if needed. I think that I will prefer work for private sector than for publicly sell plugins to everyone. There is so many pros.

1 Like
9

Systems commands are an absolute need.
On InDesign thev’e been available for the past 20 years, PS too.
Calling libraries like imageMagik, ffmpeg and custom commands is basic and essential stuff.
Please don’t kill off the scripting community by tying their hands so much.
The answer to all these security issues is permissions

3 Likes
11

External processes would have their own system permissions, so security should not be an issue.

Running processes and passing data back and forth is essential.

1 Like
12

Hey all,

Thanks for all the great discussion thus far, and I look forward to lots more discussion in the future.

Do note that we’ve never said that there would be no option to access external processes. What we do need to be careful about are these things:

  1. Security and Privacy. A trusted ecosystem is a win for everyone involved – Adobe, customers, and developers alike. The safety and privacy of the user is paramount. Users shouldn’t have to worry whether installing a plugin can harm their machine – intentional or not. Now I understand that we can’t be perfectly secure and accomplish actual work, but security and privacy are things about which we must address, and which we must address carefully. To ignore the potential for abuse or misuse is to misplace the trust of all of our users (yours and ours). Once a user is burned by one plugin, they may elect not to to trust other plugins. That would be disastrous for everyone involved.

    Also, we’re not raising security and privacy just because we fear malicious actors in the ecosystem. The truth is that it’s trivial to do bad things by accident. The history of computing is littered by all sorts of apps that in certain edge cases managed to delete all the files on a volume. Making that a little harder to do by accident is not a bad thing.

  2. User Experience. How many times have you launched, say, Visual Studio Code or Chrome, or some other app, only to have a million “Helper” processes sucking the life out of your computer? This isn’t a great experience for anyone involved, and we need to think carefully about that. Arbitrary processes that are outside the host’s control make it more difficult to ensure a consistently good user experience. We have to carefully think about how to make it hard for a developer to end up in a bad state where they can’t terminate a process they started, for example. This means thinking very carefully about the API design itself.

  3. Cross-platform and OS version capabilities. Yes, not everyone will want to write a plugin that works on every supported platform, but I think it’s pretty amazing that all but two Adobe XD plugins in the Plugin Manager work on both Windows and macOS, and every supported version as well. Obviously this is also possible with a web browser and even Node, but once you start executing external processes, you’re at the mercy of the operating system itself and how the user has configured it. Apple loves to remove common utility functions on a whim, which means you can never quite be sure your external process will actually work. (A slightly different but not unrelated issue is that of spawning your own processes from binaries bundled with the plugin – you know these exist, but you also have to compile them for each platform.)

All that said, the capability of launching external processes has never been off the table. What we’re considering is the best way forward that doesn’t compromise the user’s security or experience. Furthermore, where the current practice is to launch an external process to do something around, say, licensing, we think maybe there’s better ways to accomplish that by providing a better API. What we want to do is to make a world-class API surface that makes it easy to create amazing and compelling experiences for all of our customers. UXP has never been about taking things away. It’s about providing a great API that empowers developers to do amazing things.

Okay, so what is the ability to launch an external process apt to look like? Well, we don’t know yet. We’re thinking about it, and even working up UX ideas about how that might look, and that’s why we value these discussions.

Lastly, it may seem like we’re missing critical APIs that CEP provided, but this is version 1 of UXP. UXP isn’t done growing or maturing. We’ve got lots of ideas planned for it in the future, and we want it to be a vital platform that leads to amazing things, but we also want to make sure that the platform has a stable foundation as well, and that means thinking carefully about every brick we place.

8 Likes
13

Will y’all do any post-MAX thinking about this? It’s pretty important.

14

We’re working on a permissions API that will enable the launching of external apps and documents. That should be out early 2020 (a fast-ish-follow).

2 Likes
15

Fantastic news! Thanks for giving this some priority.

16

Hi :wave:

Is there any progress on this topic? A UXP API that would allow launching external apps?
We would like to execute an optimized C++ algorithm - ideally a common solution for XD and Photoshop.

Thanks

2 Likes
17

Is this effort dead? :frowning:

I’ve developed extensive plugin for our team that massively helps with our workflow and automates tons of actions. Of course, it relies heavily on 3rd party scripts / encoders / applications.

The team has migrated to M1 chips and surprise surprise, the CSXS plugin is no longer supported. The only option is to use Rosetta version with 50% performance loss.

At least you could have enabled some debug mode or something for internally developed (trusted) plugins. Really, nothing after 2 years? :frowning:

What exactly is UXP good for besides hiding and naming layers?

1 Like
18

Would like to bump this issue as well.

I know we can launch external apps and communicate with them via WebSockets, but this does require a fair amount of extra work that’s not typically needed for interacting with an external command line tool like FFMPEG and others. Are there any plans to support system call access for UXP? Thanks!

1 Like
19

so? Is there no progress on this issue? It took three years

1 Like
20

bump

Seems like there was a lot of effort and momentum behind this. Would love to see this conversation continued.

1 Like
21

A note on the permissions thing.

Based on modern permission trends it would go like this:

  • app is installed no special permissions requested or given
  • when you need a special permission an dialog is presented where you can ask the user for permission. the user can grant permission or deny it and they can change it later in the settings window
  • the plugin receives an event with the results of the request.
    a user can see when a permission is needed and grant it at the time it’s needed once or for all

now the additional descriptions are from browser land:

  • when you use the special permission an permission disclosure icon appears in the browser title bar. if you grant video access the video icon appears when it is being used. this is for the sake of the user. the same should be available for any permission granted. in the web inspector tool, cmd+shift+i, when a request is sent you can see the request in the network monitor and what is being sent.

this sortof approach seems the way apple, google and browser makers have been going

1 Like