On the secure delivery of regular information

Why

This blog post was triggered by a discussion on Twitter (which seems to become a habit these days…). The problem statement is simple and probably well known to most adults in “digitalized” countries: regularly (e.g. every month, quarter, year, etc.), some service provider (banks, credit cards, mobile network operators, various utility providers, etc.) need to send updated information such as bills or statements. Due to lack of standardization since good old paper letters, every provider has evolved their own way of doing it: some send an email with all information included (plain text or ZIP/PDF encrypted with some short, static password like your date of birth), some send an email notification with deep links to download the information, some send an email notification only telling you to log into their service, and other just assume that everybody will regularly log into their web pages anyways. And of course there’s an increasing percentage of “mobile first” providers that try to handle everything through their smart phone app. Needless to say, most of them are hard to automate, and manual effort spent for filing these regular updates keeps increasing. Since this seems to be a particularly poor way to spend personal life time, we should be able to do better.

How

The web should allow to do this much more easily and in a (pseudo-) standardized manner. I’d like to propose that “callback URLs” are an appropriate way to deliver these updated information snippets with semantics similar to the well-understood paper letters. As you would register a postal mailing address with a provider, logging into their web interface to register the web equivalent does not compromise security:

• Provider account login can be secured in their own specific manner as before, including all variants of 2FA
• An archive of information updates (statements etc.) can still be available for access through the provider site
• Only users with valid login credentials can change the callback URL

However, now providers can easily and securely send the updated information (usually a PDF, ideally structured data like CSV, XML, JSON, etc.) directly to their users as they would a letter, but with minimal cost and better security. Users no longer have to log into a myriad of different provider sites, each with their own idiosyncrasies. but can instead have their own automation to deal with received updates.

Technical Proposal 1

Note: This is only a first proposal and should be considered work in progress. It is the most naive approach that still seems to preserve security properties of postal mail (actually better because of transport encryption instead of just assuming mail not to be opened).

WebDAV PUT-only drop URLs

WebDAV allows to upload arbitrary files in a standard manner. If the callback URL registered with a provider actually provides the “PUT” command and disables all others (GET, POST, DELETE), it only allows to upload now files, but not download or modify existing content. While the backend handler for this URL could do arbitrarily complex operations for automatically filing the incoming updates, a simple file share backed by a directory is already immense improvement over the current “state of the art”.

Example: Nextcloud shares

Without any further implementation effort, such shares can easily be created e.g. on an existing Nextcloud instance. Simply create a new directory, create a link share (ideally with a share password set), and enable this to support uploads but disabled downloads. Such a public link will be automatically accessible through WebDAV as well. The corresponding URL is https://<nexcloud server fqdn and path>/public.php/webdav with the link ID (the string after the last slash in the regular share link) as WebDAV username and the share password as WebDAV password.

Using e.g. curl, files can be dropped into that URL, but nothing can be downloaded or changed:

# curl --user '<share ID>:<share password>' -T <filename> 'https://<nextcloud server>/public.php/webdav/'

Indeed, downloading through the WebDAV URL is blocked as it is with the standard share URL:

# curl --user '<share ID>:<share password>' 'https://<nextcloud server>/public.php/webdav/'

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\MethodNotAllowed</s:exception>
  <s:message>Only PUT is allowed on files drop</s:message>
</d:error>

Nextcloud is also smart enough to accept the same filename again and internally append a number. That is, anybody in possession of the upload-only WebDAV URL, username, and password will still be unable to even discern if a file with that same name has already been uploaded before.

With an installed Nextcloud client, those newly dropped filed can automatically be synced to the client for further processing. For better separation, I would recommend to create a unique directory/share per provider. They will be distinguished with different, auto-generated share IDs (WebDAV usernames), but use the same base URL for WebDAV PUT. If this became a de-facto standard, it could even be registered e.g. through well-known URLs at the receiving end and make callback URL entry for the provider slightly shorter. Another form of specifying a single URL including username/password is the shorthand https://<share ID>:<share password>@<nextcloud server>/public.php/webdav/.