mac sierra 10.2, hijacking and security of app downloaded from the internet (must be signed with a Developer ID certificate)

Gatekeeper Path Randomization

Gatekeeper is a security feature that has already been in place for several years. When enabled, Gatekeeper checks whether an app downloaded from the internet has been signed with a Developer ID certificate, which third-party developers such as Rogue Amoeba purchase from Apple. If the app is Developer ID-signed, then Gatekeeper allows the app to launch. If the app is not signed, then Gatekeeper will refuse to launch the app.
In 2015, security researcher Patrick Wardle discovered a vulnerability in Gatekeeper called dylib hijacking.
 https://reverse.put.as/wp-content/uploads/2015/11/vb201503-dylib-hijacking.pdf
Wardle determined that if a Developer ID-signed app loads resources external to its app bundle via a relative file path, an attacker could package the app together with malicious external resources in order to work around the Gatekeeper protection. The app would pass the Gatekeeper check and be allowed to launch, after which it would load the malicious external resources. Wardle found that a number of popular apps, including some of Apple’s own apps, could be used as a vector for such an attack.

Gatekeeper Path Randomization is an attempt to avoid this vulnerability. It works by mounting a read-only disk image in a temporary path in the file system, copying the app onto that disk image, then launching the app from there. With the app bundle’s path thus changed, it will no longer find any external resources where it was expecting them, and thus the loading of malicious resources is prevented.

https://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/

The problem with Gatekeeper Path Randomization is that copying applications to a read-only disk image will break functionality in many, if not most, existing applications. Perhaps most notable, features like automatic software updates (via Sparkle or similar mechanisms) will no longer work. Apple may not view this as an issue, given that GPR will be disabled once the user moves the application out of the Downloads folder. However, many users run applications from the Downloads folder, never moving them. This is especially common when a user is trying out an application prior to purchasing it, and an app that doesn’t work as expected due to GPR seems certain to lead to lost sales. Worse, even if the customer moves your app to their Applications folder, it may continue to be broken, depending on how your app is packaged.

Example with ImageJ

macOS 10.12 (Sierra) introduces a security feature called Path Randomization that can cause ImageJ to not work as expected. Path randomization is in effect if the “ImageJ home” path shown in the Image>Show Info window starts with “/private” and plugins are not installed in the Plugins menu. You can disable path randomization by moving ImageJ.app (the icon of your application) out of the ImageJ folder and then copying it back. If the ImageJ folder is in /Applications you will need to hold down the alt key while dragging ImageJ.app out of the ImageJ folder.
https://imagej.nih.gov/ij/docs/install/osx.html

ImageJ cannot use the plugins.

ImageJ is designed to look (every time it runs) for the plugins directory in the same folder where ImageJ.app is located. If you want to override that, you can use the command as you have found, or you can edit the Info.plist file that is inside the ImageJ.app folder.
Right-click on ImageJ.app and select Show Package Contents.
Open Info.plist (if you have Xcode it will be the default to open that file) and append to the Java->VMOptions line the location of the plugins folder you want to use, for example:

VMOption -Xms256m -Xmx3000m -Dplugins.dir=/Users/me/myplugins

If the directory you specify doesn't exist, it just reverts to the default of looking where ImageJ.app is.