- HKEY_CURRENT_USER\Software\MozillaPlugins\@docu-track.com/PDF-XChange Viewer Plugin,version=1.0,application/pdf
- HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@docu-track.com/PDF-XChange Viewer Plugin,version=1.0,application/pdf
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\@docu-track.com/PDF-XChange Viewer Plugin,version=1.0,application/pdf
If you visit https://panopticlick.eff.org/ and run the test, you will see that querying the web browser for a list of its plug-ins is one method of fingerprinting a user. While Adobe Reader is very common (probably the most used PDF viewer), PDFxchange Viewer (or PDFxchange Editor) are far fewer in number of users which means anyone using PDFxchange <whatever> will have a bigger fingerprint. When the user configures PDFxchange Viewer to not display PDFs within the web browser, the plug-in is not used so it does not need to be registered which exposes it through the web browser to sites that query what plug-ins are available.
Display PDFs in web browser = enable: use the plug-in (so register it when enabling this option)
Display PDFs in web browser = disable: don't use the plug-in (so deregister it when disabling this option)
I realize the old scheme was to register a plug-in even if it is not used. The author provides a plug-in and expects users want to use it. However, if users elect to display PDFs outside the web browser then the plug-in is superfluous and so is its registration in the registry as a plug-in to the web browser.
If PDFxchange Editor works the same way then this request (to deregister the plug-in when "Display PDF in web browser" is disabled) also applies.