Why is this not a Web application?

[AleixMT]

Lots of spanish friends, familiars and coworkers use autofirma to sign their documents. It is a nice application and works fine most of the time, but sometimes wird errors appear related with the compatibility with the OS and the JVM version that the user is using to run autofirma.

So, why should this app be a desktop application? It would probably be more user-friendly if this could work as a web page. Is this for legacy reasons, security reasons or any other functional reason?

Thank you for creating and maintaining this application.

[rldelgado]

Actually, I am not one of the developers but I was a heavy user in the old and infamous times when this application was a Java Applet. Actually, most of the issues with AutoFirma (and as a GNU/Linux user I have seen a lot of them) come from the fact that it is not a pure desktop App, but for some reason I do not understand they keep making a webpage to control AutoFirma even if it leads to lots of compatibility issues.

The main reason why this should not be a Web app is because its purpose is to allow you to sign legally binding documents (most of the times, adding digital signatures to PDF). This is not for login into an institutional webpage. Browsers have other ways of doing the last thing and, indeed, the spanish DNI-e contains two separate certificates: one for browser login and another for e-signature.

From my point of view, the simplest approach for signature would be:

1. You generate a PDF in some web. Let's say, a contract, a public form, or whatever.
2. You download the PDF from the web.
3. You read the actual PDF before signing it, as you should also do with physical signature.
4. You sign it with AutoFirma. This step could be in a different offline computer, why not.
5. You upload your signed PDF to the web.
6. The server checks that you signed the given document with a valid e-signature.

But, instead of implementing the easiest path, 10 years ago they decided that the signature process should be completely done on the web interface. Hiding the actual signed document to the user. Something that I think is a terrible idea if we are taking about legally binding documents. For this purpose, and because browsers are not intended for digital signature of external files, they developed Java applets. Hence, you had to guarantee that the Java applet, the Java virtual machine, the browser and the smartcard reader drivers worked smoothly. Too many failure points, making people to use very outdated and insecure environments just for all this thing to work. All this mess was one of the main reasons why adoption of DNI-e signature in Spain was so low in spite of the public investment: the DNI-e was not usable in real environments by non-hackers because of these poor design decisions.

Oracle killed Java applets, killing also all these "Java signature applets" for good. Afterwards, they finally decided to switch to an independent desktop App (AutoFirma) for digital signature. With the additional gain of being able to sign whatever PDF or document you need to sign. A very good thing.

However, when AutoFirma was implemented they made a second mistake: not doing a complete switch to desktop App in the way I told you before. Instead, they implemented some communication between the browsers and AutoFirma so that the old thing of hiding the actual signed document to the user is still done. You have the webpage generating a call to AutoFirma in the same way that a call to Zoom App can be done from the web. AutoFirma retrieves the PDF from wherever the browser downloaded it and sends it to the HTTPS server the webpage told AutoFirma to upload it. Everything outside of the user's control. Of course, the user has to answer the question "I have read the document" on the webpage. Very funny, since you could sign a completely different document that the one you was shown on the webpage.

Moreover, Mozilla (Firefox developers) deprecated support for the generation of digital certificates withing the browser, precisely because of security concerns and browsers not being digital signature applications. This lead to the Spanish FNMT being forced to release their own browser App for generating certificates within their users computers, something they should have done much time ago. Unfortunately, they also took the decision of making their App dependent on communication with the browser, also leading to incompatibility issues that could have been very easily avoided. All this for the shake of not modifying their old web interfaces.

The thing is that most of the issues with AutoFirma come from errors in this communication between browser and AutoFirma, whose only benefit is hiding the actually singed document. The other errors come from the fact that AutoFirma retrieves digital certificates from different sources as browsers (Firefox) and operative systems storage instead of having their own certificate storage or, at least, some way of uploading a certificate by hand. Even worst, the communication protocol with the browser would allow the webpage to fix the certificate storage. Something really stupid since it is the user who knows where is his certificate.

To sum up: this is not a Webpage application thanks to browsers not being designed for digital signature and Oracle deprecating Java applets because of, precisely, security concerns. And most of the actual issues with AutoFirma come from the fact that they stubbornly try to keep webpages controlling digital signature (AutoFirma) instead of being the user the one who control what PDF he signs.

[AleixMT]

@rldelgado Thank you so much for the effort that you put into your answer. Now I understand the reason behind it. Actually is very sad that AutoFirma still has those limitations because of a bad design decision from the past. I hope that some day an alternative is provided or the design is fixed. I will close this issue since my question has been answered.