FaxDroid allows users to upload one or more documents to be transmitted as fax. When these documents are uploaded, third part libraries are used to modify the files into a format that is transmittable by the fax server. This introduces two major challenges:

1. Working with customer files and third party libraries without proper isolation makes FaxDroid susceptible to zero day vulnerabilities. Users might upload malicious files which could impact the system and other users.
2. Before completing the checkout process not only do users need a quote (which is based on the number pages) for the fax, but they also need to see a preview of the final document. This poses a challenge as the conversions that operate on the file before this information can be provided is consuming and keeping the user blocked on this can lead to increased bounce rates.

To build a secure and seamless user experience, a custom file handling mechanism was built for FaxDroid. The solution took advantage of running the conversions in isolated docker containers in parallel to the users flow. In the sections below the solution is explained in more details.

---

Conversions

Users can upload documents in various different formats, dimensions and sizes. The fax server used for transmitting the faxes requires the files to be in a very specific format. In order to make the files compatible various different conversions are applied to the files as outlined below:

• Conversion to A4 size
• Gray scale conversion
• Compression in case the files is too large
• Flattening in case of annotation or comments on the files
• FaxDroid accepts various file formats (csv, txt, docx, pdf, images, …). They all need to be converted to TIFF format.
• All uploaded documents need to combined into a single document

 

---

Challenges

Security

Handling customer files and operating on them using third party libraries poses a security risk. Third party libraries might have security vulnerabilities that are not patched yet. Users might end up uploading malicious files that would not only impact the server but also impact other customer files.

User Experience

The user flow for sending out faxes has several different stages:

Upload Files: Users upload their documents.

Enter Name, Email, Destination Fax Number: Users enter various different information. These are all filled out on the same page as the file upload.

FaxDroid Provides a Quote: After the previous two steps are complete, a quote is provided. At this stage FaxDroid needs to know exactly how many pages are being transmitted. This is not as straight forward as one might imagine. While it might be simple to answer for pdfs and images, but for csv and txt files they would need to be converted into pdfs first.

This is one of the places where users might be blocked by the file conversions.

Preview File (optional): Once the user reaches the fax confirmation page they may wish to see a preview of the file. The stage is optional and not all user choose to see a preview of the file before submission.

FaxDroid Generates the Preview: When the user requests a preview, a series of polling requests are made to the back end to check if the file is actually ready. It checks to see if all the conversions have completed and the final combination of all the documents is ready. Until then a loading screen is displayed. This is another place in the user flow which users might be blocked by the file conversions.

Checkout: At this point the user submits the fax for transmission. For faxes that require a payment this means the PayPal checkout has been completed.

Fax Transmission Starts: Once the user submits the fax they will see a progress bar. Whether or not the file conversions are ready by this point is not important, as users will see a progress bar in either case. Once the fax is complete an email notification will be sent out.

---

Solution

The figure below shows the solution that was taken (details explained below). In order to ensure user files are handled in an isolated manner docker containers were used. The docker containers contained images built specifically for the specific task they were being used for. Also to ensure the user experience was seamless many of the conversion events were processed in parallel as the user continues through checkout path.

 

1- Upload File: Everything starts when the user uploads their file. The file upload does not block the user immediately. The user can continue with uploading additional files and or fill in the remainder of the first page (email, name, destination fax). It is only once the user whishes to pass the first page that they might be blocked on the file upload.

2- Perform Light Conversion: A docker container spins up and performs some initial operations on the files. The initial conversions are only to get a page count for the documents. Once complete the original document is uploaded to S3 and the page count is stored on the servers database.

For the duration of this operation the user sees a spinning icon on the file upload.

Once the light conversion is complete the user will see the checkbox below:

As the conversions happen inside an isolated docker container any malicious activity will not effect the servers and other users.

3- Full Conversion Trigger: Once the above is complete, a new thread is spawned that starts up another docker container. This container will perform the full conversions needed on the file. This happens entirely in the background and the user is not (immediately) blocked on this.

4- Complete First Page: The user can continue filling in the first page as the file conversions are taking place. Once complete the user can submit the form to proceed to the next page. The user will only be blocked on this stage if the light conversions have not completed yet. The full conversions are non blocking.

5- File Combine Trigger: All files uploaded by the user need to be combined into a single file before the fax can be sent out. For this conversion to start two pre requests need to be met:

1. The user must have finished filling in the first page and clicked on “Next”.
2. The full file conversions in the previous stage must have all finished.

When both of these are met, a separate thread is spawned and the file combination is initiated. Once again this is non blocking to the users immediate actions.

6- File Preview: On the fax confirmation page the user may wish to preview the file before submitting. This is not necessarily on every users path, but some users do choose to preview the files. If the file combination is not completed by this stage the user might be blocked here. The parallelism introduced into the various operations was to minimize the wait time at this stage.

Should the file not be ready at this stage a popup will appear indicating that the file is being processed:

7- Fax Submission: Once the checkout process is complete the fax transmission will start. The fax transmission is processed asynchronously and is non blocking to the user.