> However, since the automation of our software is a common operation that has been used in malicious ways, we chose to prevent that. Thus we are improving the security of our software.
You are not improving security of your software. You are violating Windows standards that had been in place for decades. Numerous thousands of Windows applications had been and still are using this functionality with the same expectation: that the application starts, prints, and quietly goes away - starting with notepad.exe. Now comes Adobe who "unlike our competitors we CARE about security!" - said competitors apparently being the whole other universe, since nobody else came up with this idea. Do you think Microsoft should patch notepad.exe to be "more secure" by staying on the screen? The same malicious code that would strive to print on users' printers without their knowledge, might use Notepad, web browser, or any other print-capable application - all of which do conform to the standards and quit. You can't imagine that anybody would print by anything but Adobe reader?
So let's see what is the result of this "improved security". The result is that every your customer who is using this feature is frustrated, and looking for a workaround, which is evidenced by the dozens of posts in all places, all about the same - how to make acrord32 window close after printing. The result is that programmers write the special code that finds acrord32.exe process and kills it. Is this more secure? No, it's 1,000 times more arrogant and counterproductive. Your users naively think that this is a bug that you just don't care to fix. It can't even cross the mind that the design as counterproductive as this might be a conscious design. And certainly, nobody is taking advantage of this increased awareness, so the whole effort is moot.
Of course, half of the users found another solution - they switched to another pdf reader, like Foxit or Sumatra, both apparently so unconcerned about the security that they work as everybody expects.
Show us one soul who congratulated you for this "security" mitigation. Show one who has agreed that this helps. Show one who even understands how to use the fact that reader's window is on the screen. You won't. But you don't care, because apparently you know better than everybody else.
Speaking of security, do you know how an application that stays on user's computer uninvited and unsolicited is called? It's called a virus. And yes, half of the viruses claim that they are there to protect the user, and half of those actually believe that it's true. Apparently, the distance between arrogance and malice is short.
But the problem is not only in the fact that the window stays. The problem is that the reader that stays on the screen, does not operate as expected.That is, after running the following code:
Dim pr As New Process()
pr.StartInfo.FileName = "c:\myfile.pdf"
pr.StartInfo.UseShellExecute = True
pr.StartInfo.Verb = "print"
pr.Start()
pr.WaitForExit()
Reader's window stays on the screen. If we now try to open another pdf file by double-click in Explorer, it won't open. You now can open it only from Reader. I guess, this is another security measure?
Regarding helpful advise to use the API - regardless of the API, you install your product with the standard verbs "print" and "printto" available to shellexecute. If so, then these verbs should perform as expected, because this is industry standard. If you think that it's bad idea and you don't want to support them, then you should remove those verbs from the system. Leaving there when they don't work as they should, is standards violation, however noble are justifications.
We hope that Adobe will finally listen to your customers and do what they expect. We heard your concern, but we don't appreciate it.
16
Replies
AdChoices