Google's CardDAV server isn't standards compliant (2014)

bariumbitmap | 240 points

I can confirm just about all of this because of a recent job in this space. Whatever you do, do not do two way sync with Google's CardDAV servers or you will end up with a lot of lost data.

I wonder if they should even be allowed to call it CardDAV since you'd expect it to actually adhere to the standard.

Google is large enough not to care about this though, as long as it works with their address books on Android phones it is probably good enough for them.

Note that this post seems to be from 2014 and the situation isn't much better today!

jacquesm | 6 years ago

I think to get past such issues with providers like this, you first need to understand what it is and what it is not.

Forget the brochure, the ads and the nice tutorial, those are NOT CardDAV/SMTP/IMAP/... servers. What they are instead are ways to access their own proprietary special thing using standard protocols that your software and tools already supports, if you can't use the dedicated api.

It applies to pretty much every system for which Google has made their own thing, with their own api (contact api, mail api, ...), and then offer an alternate way to access their system by standard protocols.

And what this means is that the ruling system is the underlying one, the one which can be accessed in several ways, including that standard protocol. If their contact system discards the field "foobar" because it doesn't want it, then it doesn't matter if CardDAV says it should be kept.

Sure Google should totally make this clearer, and sure as an user I'm not a big fan, and yes I totally understand and agree with the "but as a result they break the standard, lose data and cause unexpected behavior and that's terrible", but from a purely engineering perspective it also makes total sense as to why those things happen this way, and is actually rather predictable.

You're feeding data to a special system that just so happens to have a CardDAV/SMTP/IMAP/... endpoint plugged on top of it. Of course that endpoint doesn't rule how the special system will behave.

And frankly any one who has had to build/support that kind of "api on top of an api" for some time has faced that sort of situation before.

In fact you don't need to go that far; I mean how many of your web applications take PUT or DELETE requests ? The HTTP protocol certainly says it should work and the http server you're using supports it. And let's not talk about all those sites that give a full page answer to a HEAD request.

PS: again, I am most definitely NOT saying I like that it works that way, I'm just saying ... "well no big surprise there".

nolok | 6 years ago

Quote from the DAVdroid project:

Address books, calendars and task list contain private and sensitive data by their nature. We believe that individuals and companies should be able to be in full control of their own data. This means the freedom to choose where and how the data are stored, and freedom in choice of software. CalDAV/CardDAV are open protocols and thus can be used with various server and client software.

Setting up your own CalDAV + CardDAV server such as Radicale is easy. Chances are if you are reading HN, you can do it yourself. Do it.

Tepix | 6 years ago

Slightly related: try to sync an external calendar feed in iCalendar format (also used in CalDAV) with Google Calendar.

Google Calendar will use random intervals to synchronize. Often taking more than 24 hours... which is, in most use cases, quite useless.

Sync in the same way with Facebook's event feed (same format) and changes appear within minutes.

This has been the case for years. Google Groups are full of questions about this.

I don't want to demand anything from a free product (Google Calendar is very useful in many ways). But somehow some feedback about 'shortcomings' like these would be hugely appreciated.

smhg | 6 years ago

This (good, but sad article) is actually about "How" it's different, not "Why".

Why don't they care at all about standards? I don't know; they talk a good game. At least some companies who violate standards are open about it -- Google trumpets it but often simply pays lip service.

gumby | 6 years ago

> this isn’t just a 400 Bad Request [...] Any (valid) vCard that the CardDAV server does not understand, will result in our HTTP requests timing out

That's just terrible. Why would such a thing be implemented ?

The only valid explaination I can think of, is to deter abuse. But even for that there are better solutions than this.

yosamino | 6 years ago

Relevant: The author of the post worked on Sabre/dav, an open source CardDAV/CalDAV server (linked at bottom of the post). Unfortunately, it is no longer under development: http://sabre.io/blog/2017/development-on-hold/

captn3m0 | 6 years ago

Google doesn't like existing standards, and have generally been bad stewards of their power in that place, they like to make new ones though that they expect everyone to jump on. I am wondering if the engineers and product developers are still in charge at Google?

drawkbox | 6 years ago

Ahh, the good old days of “embrace and extend” are back.

Delightful.

splitrocket | 6 years ago

In the CalDAV space a lot of people do whatever they want, so there is a standard but most people are not compliant with it.

I would imagine the same is true for CardDAV, not only at Google.

nik736 | 6 years ago

My impression is that

https://developers.google.com/people/v1/libraries

Is the current recommended solution for this sort of thing.

Libraries look to be available for

GO JAVA JAVASCRIPT .NET NODE.JS OBJ-C PHP PYTHON RUBY

and you can roll your own using HTTP.

CardDAV is not well maintained, and even the contacts API using GData is superseded with the above.

With over 1 billion active users - my guess is engineering efforts are focused on serving that customer base, especially the growth in paying customers through google apps. Not sure where strict compliance with CardDAV would fall in the analysis.

A note that actually using some of these API's through their client libraries isn't totally the nightmare described - though my experience is very limited.

privateSFacct | 6 years ago

I get the sense that Google cared about open protocols, and then Android changed that, to simply being another mechanism to lock users into their walled garden.

thrillgore | 6 years ago

Tangent: What are people's experience with Google's CalDAV support? Is it just as bad?

torarnv | 6 years ago

Embrace, Extend, Extinguish.

forgotmypw | 6 years ago

This explains why the hell I kept loosing contact info when exporting to other web clients. Always something was missing or out of place! F U Google!

remusrm | 6 years ago