First and foremost, forms generated by Quik! do NOT manage, store, archive, interpret or make it possible for Quik! systems to access client data entered onto forms. While Quik! may offer software that can store data on a client’s behalf, using a Quik! form by itself via a link, API or other access method will not cause Quik! to store the form data. Quik! API’s primary function is to help customers manager their library of forms and to deliver forms to users when they need them and on the device they’re using. With this goal in mind, Quik! Forms are designed to keep data in the control of the customer and user.

If you are interested in the security model of data that a turnkey Quik! application provides, please the specific security white paper for that product. This white paper applies to the APIs and forms themselves.

How Forms Are Generated

In order to view a Quik! Form it must first be generated by the Quik! software. By always running a Quik! software component to generate the form the user will always receive the latest form version and never turn in a form that is no longer in service. The Quik! software, at its core, is like the engine of a car: it takes in fuel and creates power, or in Quik!’s terms, it takes in data and outputs a form for the user to see.

Like an engine can be used to power a car, boat, plane, truck and more, the Quik! Forms Engine is used to power websites, mobile apps, desktop software, server-side software and more. Regardless of what application is using the Quik! Forms Engine, the underlying operations are always the same, as illustrated in the pictures below.

Option 1: Install Quik! on Your System

For convenience, security and control, customers can implement the Quik! API (QuikFormsEngine.dll) directly within their application.

Option 2: Use Quik! as a Web Service

For customers who cannot implement the Quik! software directly within their application, a web service can be used instead. The Quik! Forms Engine web service is the same QuikFormsEngine.dll hosted by Quik! and works essentially the same way as the software but is accessible via SOAP and REST methods.

Process Flow Explained

The Quik! software is provided with data to prefill onto forms (DLL or Web Service) and run.
The Quik! software calls the Quik! Environment to retrieve the requested forms
The forms are sent back to the customer application, populated with the customer data
The customer application serves the resulting Quik! form in HTML format to user's browser
The forms display prefilled with data
The user enters data and completes the form
The form can be sent back to the customer application for further processing, signature and storage.

Form Security Detail

The Quik! architecture ensures the customer’s application and the end-user are in control of the data, not Quik!. Quik! provides the underlying forms architecture for applications via a single interface (the Quik! Forms Engine).

With this architecture in mind, the data security for forms is easier to understand and identify.

In steps 1 through 3 of the architecture diagram, the customer application is the start and end point of a round-trip to the Quik! server. The transaction starts at the customer application to ensure the customer application controls the data provided to the Quik! Forms Engine to populate on the form. There are two methods in which the Quik! Forms Engine can be run and both methods are discussed from a data security standpoint:

Installed Software (QuikFormsEngine.dll - .NET Framework)
Web Service

Installed Software

When installed inside an application, the data provided to the Quik! software will go straight onto the resulting Quik! Form (step 3). No data is sent to the Quik! server (step 2), only the customer’s credentials and the form request is sent so Quik! can validate the customer’s rights to generate the requested forms.

Web Service

The Quik! Forms Engine web service method is slightly different than the diagram above in that the actual Quik! Forms Engine software (i.e. the QuikFormsEngine.dll) is hosted on a Quik! server instead of in the Customer Application. This method is optional and often chosen by customers who need a cloud-based solution.

When using Quik! via the web service method, the data provided to the web service is sent to the Quik! web server with the following security protocols:

256-bit SSL encryption (standard encryption used for internet traffic)
Data received on the Quik! server is loaded into the Quik! Forms Engine software residing on the Quik! server (just like in Step 1) and used to create a form (step 3) that is returned directly to the client application.
The Quik! server:
- Does NOT store, write to disk or archive the form or related data in any way – the generated form that includes any data to prefill onto the form is held in random access memory (RAM) for the duration of the request only and is immediately released after the form is returned to the calling application.
- Does NOT interpret, access or read the data for any logical operations – the data is simply placed into the form as requested.
- Does NOT enable any person, including potential hackers, to view, access or retrieve data on forms in any manner through the Quik! server.

In step 4 of the diagram, the customer application delivers the form output (HTML) directly to the end-user’s browser. Since the customer application is in control of this step, the customer is responsible for the security method. For example, the customer will most likely:

Deliver the forms from within the customer’s domain (e.g. https://www.CustomerURL.com)
Deliver the forms via SSL security (i.e. “https://”)
Authenticate the user before a user can generate a form and view it (e.g. some kind of login or user authentication)
Control whether or not the form is written to the customer’s own computers (e.g. web server, local drive, network, etc.)

In step 5 and 6, the end-user is viewing the form in their web browser. By virtue of how web browsers work, the entire HTML output from the Quik! Forms Engine is downloaded by the web browser to the end-user’s machine in order to be displayed. This ultimately means that the user’s device has the HTML, inclusive of any prefilled data, locally resident on that device’s drive. How the user configures their web browser and secures their device determines how secure their data is.

Note: Data on a form is not at the same level of risk as an entire database or organized records. Even if a user’s device is compromised, the form data is not managed or organized in a way that is meaningful or valuable to a hacker, nor is there more than a few records at any given time.

Finally, in step 7 a user can choose to print, submit and/or sign the form depending on the customer’s configuration of the Quik! form. These three options create different avenues for data.

Print

Printing a form will send the form data to the Quik! server for the sole purpose of creating a PDF that is returned to the user. When the print routine is run, the data is sent securely to Quik! and immediately turned into a PDF that is returned as a response.

The form data sent to the print service is sent with the following security protocols:

256-bit SSL encryption (standard encryption used for internet traffic)
Data received on the Quik! server is converted into a PDF form that is returned directly to the client application.
The Quik! server:
- Does NOT store, write to disk or archive the PDF or related data in any way – the PDF that includes any form data is held in random access memory (RAM) for the duration of the request only and is immediately released after the PDF is returned to the user’s browser.
- Does NOT interpret, access or read the data for any logical operations – the data is simply placed into the form as requested.
- Does NOT enable any person, including potential hackers, to view, access or retrieve data on forms in any manner through the Quik! server.

Submit

If the submit button is enabled on a form, the customer must provide a URL to submit the data to. That way when the submit button is clicked by a user the form will send the data directly to that URL. Since this URL is not hosted or controlled by Quik! in any way, the security of this URL is determined by the customer. Quik! recommends using SSL with 256-bit encryption on a secure server.

Sign

Depending on how customer chooses to implement e-signing, clicking the Sign button may send the form data to the Quik! server for the sole purpose of creating a PDF that is used with the e-signing service. When the sign routine is run, the data is sent securely to Quik! and immediately turned into a PDF that is used in the signature process.

The form data sent to the sign service is sent with the following security protocols:

256-bit SSL encryption (standard encryption used for internet traffic)
Data received on the Quik! server is converted into a PDF form that is returned directly to the client application or loaded directly into the e-sign system.
The Quik! server:
- Does NOT store, write to disk or archive the PDF or related data in any way – the PDF that includes any form data is held in random access memory (RAM) for the duration of the request only and is immediately released after the PDF is returned to the user’s browser.
- Does NOT interpret, access or read the data for any logical operations – the data is simply placed into the form as requested.
- Does NOT enable any person, including potential hackers, to view, access or retrieve data on forms in any manner through the Quik! server.

The sign button does require the service of a third-party e-sign vendor. Each e-sign vendor is responsible for their security protocols and Quik! recommends doing diligence on each vendor before choosing one. The e-sign partner(s) Quik! works with are well-established companies with a proven track-record of strong security.

WHITE PAPER: Quik! Forms Security

Quik! Forms Security Model