Where does your data live? If you use Google Calendar, for example, your schedule is stored on Google’s servers. If you use iCloud Contacts, your address book is stored on Apple’s servers. The same applies to Dropbox: your files live on Dropbox’s servers. While you can access this data through apps and web interfaces, you do not truly own it. The provider can change the terms and conditions, discontinue the service or use your data for advertising purposes. Essentially, you are renting access to your own information. This is not a theoretical concern — it is how most people manage their personal data by default.

DAV protocols offer an alternative model. These open, IETF-standardised protocols let you store and manage your own files, calendars and contacts on a server that you control. WebDAV handles files. CalDAV handles calendars. CardDAV handles contacts. All of these protocols are built on the same foundation — HTTP extended with XML — and share the same philosophy: your data, your server, your rules.

What is DAV actually?

DAV stands for ‘Distributed Authoring and Versioning’. The core WebDAV protocol was first published as RFC 2518 in 1999, and was later revised as RFC 4918 in 2007. WebDAV extends HTTP with new methods and headers that transform a web server into a read-write file system. While plain HTTP can only perform GET and POST requests, WebDAV adds PROPFIND to list directory contents, MKCOL to create folders, COPY and MOVE to organise files, and LOCK and UNLOCK to enable concurrent editing. The protocol also defines a property system whereby every resource (file or folder) can carry arbitrary metadata in the form of XML properties, separate from its content. This means that you can ask a WebDAV server questions such as “Who is the author of this document?” or “When was this last modified?” without downloading the file itself.

CalDAV and CardDAV are built directly on top of WebDAV. Defined in RFC 4791, CalDAV extends the property and collection model to handle calendar data. A calendar is simply a WebDAV collection whose items are iCalendar files. Scheduling, free-busy lookups and recurring events all work through standard WebDAV mechanisms, with calendar-specific logic handled by the iCalendar format in the payload. Similarly, CardDAV (defined in RFC 6352) extends the property and collection model to handle address book data, with collections of vCard files accessed through WebDAV methods. The elegance of this design means that if you understand WebDAV, you already understand most of CalDAV and CardDAV. They do not reinvent transport, authentication, or access control. They simply define new resource types and a few new properties.

XML is the glue that makes all of this work. Every WebDAV request and response body is an XML document. PROPFIND returns a multistatus XML structure listing each resource and its properties. A REPORT request on a CalDAV collection sends an XML query asking for events within a specified date range, and an XML response containing the matching iCalendar objects is returned. Although XML is verbose and not particularly fashionable, it is well-defined and extensible, and has been stable for decades. In a protocol designed for interoperability between arbitrary clients and servers, stability matters more than elegance.

How it works in practice

Imagine that you have a WebDAV server running at dav.example.com. Your calendar app wants to retrieve your events for the week. It does not support a proprietary API. Instead, it sends an HTTP request:

 1REPORT /calendars/home/ HTTP/1.1
 2Host: dav.example.com
 3Content-Type: application/xml
 4Depth: 1
 5
 6<calendar-query xmlns="urn:ietf:params:xml:ns:caldav">
 7  <prop><getetag/></prop>
 8  <filter>
 9    <comp-filter name="VCALENDAR">
10      <comp-filter name="VEVENT">
11        <time-range start="20260617T000000Z" end="20260624T000000Z"/>
12      </comp-filter>
13    </comp-filter>
14  </filter>
15</calendar-query>

The server responds with an XML document containing a list of all matching events, each with its own path, ETag and iCalendar data. The client then parses the XML, extracts the events and displays them. The entire exchange uses standard HTTP authentication and runs over TLS. There is no API key, no OAuth process and no vendor-specific software development kit (SDK). Any CalDAV client can communicate with any CalDAV server because the protocol defines the contract.

This is the fundamental difference between DAV and the API-based model used by Google, Microsoft and Apple. Their calendar APIs are proprietary interfaces to their own backends. You can only use them with their clients, on their terms. DAV flips this around: the protocol is open, the data format is standard and you own the server.

The privacy angle

Several things change when you store your data on a DAV server that you control. Firstly, no third party can access your data unless you explicitly grant them permission to do so. Your calendar events, contacts and files are not scanned to create advertising profiles. They are not used to train machine learning models. They are not subject to terms of service that change every six months. The server sits on your hardware or VPS, behind your firewall and under your administration.

Secondly, you are not locked in. If you use Radicale today and decide to switch to Baikal tomorrow, there is no need to export or import anything — you just copy the files. Radicale stores calendars as plain .ics files and contacts as plain .vcf files. Baikal stores them in a database, but they are accessible via the same standard protocols. Your client applications do not need to change because they speak CalDAV and CardDAV, not Radicale-flavoured CalDAV. The protocol is the abstraction layer. The server implementation is replaceable.

Thirdly, you are immune to the kind of supply-chain disruption that I wrote about in the context of AI models. No government can ban your calendar. No company can deprecate your address book API. IETF standards are published, reviewed and stable. The reference implementations are open source. Even if all commercial DAV vendors disappeared tomorrow, you could still run your own server and synchronise your own devices because the protocol is documented and the code is available.

The three siblings

WebDAV is the oldest. It solves the simple problem of mounting a remote directory as if it were local. On Linux, davfs2 lets you mount a WebDAV share at /mnt/dav and use it as you would any other file system. On Windows, WebDAV is integrated with Explorer. Finder supports it natively on macOS. You can drag and drop files, edit documents in place and share folders with others, all via a stable protocol dating back to 2007. WebDAV is also the foundation for many tools you already use. Joplin uses it for note synchronisation. Zotero uses it for storing attachments. Standard Notes uses it for backup. Rather than inventing their own sync protocol, these tools chose WebDAV because it is well understood, widely implemented and easy to self-host.

CalDAV solves calendar synchronisation issues. Before CalDAV, there were essentially two options: using Exchange ActiveSync (which is proprietary and controlled by Microsoft), or using a vendor’s cloud API. CalDAV provides a third option. You can run a server — such as Radicale, Baikal, or Nextcloud — and any CalDAV-compatible client can then read and write your events. On Android, DAVx⁵ integrates CalDAV with the system calendar provider, meaning every app can access your self-hosted calendar as if it were a local account. On desktop, Thunderbird natively supports CalDAV. The protocol supports the full iCalendar specification, including recurring events with complex rules, alarms, attendees and time zone handling.

CardDAV is the newest and simplest. An address book is a collection of vCard files. CardDAV enables clients to query, create, update and delete these files using standard WebDAV semantics. The same DAVx⁵ app on Android syncs contacts into the system address book. On iOS, CardDAV accounts are natively supported in Settings. On desktop, both Thunderbird and Evolution speak CardDAV. The vCard format dates back to 1995 and has undergone several revisions, with the latest version, vCard 4.0, being published as RFC 6350. It can handle names, phone numbers, email addresses, photos and custom fields, providing everything a contact manager needs.

Running your own

The simplest entry point is Radicale. It is a single Python package with no external dependencies other than Python itself. Simply install it, create a configuration file with a path to your storage directory and run it. It supports WebDAV, CalDAV and CardDAV straight away. Authentication can be as simple as an htpasswd file. Storage is in the form of flat files on disk — each calendar is a directory of .ics files and each address book is a directory of .vcf files. This makes backups straightforward and allows you to easily examine your data. You can use the grep command to search your calendar data. You can version it with Git. There is no database to corrupt and no opaque binary blobs.

If you require a web interface and additional features, Baikal is a PHP application that uses either MySQL or SQLite. It provides a user interface for managing users, calendars and address books. Although it is slightly more complex to set up, it offers a more polished experience. Nextcloud is much larger and includes CalDAV and CardDAV servers as built-in apps, as well as offering file sync, document editing and more.

The client-side landscape is healthy. For Android, DAVx5 is a one-time purchase app that integrates CalDAV and CardDAV into the system. Thunderbird has supported both protocols natively for years and is available for desktop. In terms of file access, davfs2 is supported on Linux, while the built-in WebDAV client is supported on Windows and macOS. There are also countless mobile file managers that support WebDAV. The ecosystem of protocols is mature enough that you can go fully self-hosted for files, calendars and contacts without sacrificing convenience.

Why this matters now

The tech industry operates in cycles. In the 2000s, open protocols such as HTTP, SMTP and XMPP were commonplace. However, in the 2010s, walled gardens and proprietary APIs took over because they could iterate and monetise more quickly. The pendulum is now swinging back, partly due to privacy regulations and growing distrust of big tech, and partly because people are realising that paying to access their own data is a bad deal. DAV protocols were developed during the initial open-protocol era, remained largely unchanged during the walled-garden era, and are now more relevant than ever.

They are not perfect, though. XML is verbose. The multistatus response format is tedious to parse. The property system can be confusing. There is also no standard push mechanism for real-time synchronisation, with most clients relying on periodic polling or server-specific extensions. While these are real shortcomings, they are engineering trade-offs rather than fundamental flaws. The protocols prioritise interoperability, simplicity and long-term stability over efficiency and modernity.

The battle for digital privacy is fought on many fronts. On one front, people develop proxy applications and alternative clients to mitigate the worst effects of centralised platforms. On another, they advocate for regulation and interoperability mandates. However, the most effective approach is also the most personal: choosing to store your data on infrastructure that you control and using protocols that guarantee your independence. DAV protocols offer this option for three common types of data: files, calendars, and contacts. They have been doing so for over twenty years. They will probably continue to do so for another twenty years.