Google's CardDAV server isn't standards compliant (2014)
evertpot.com
evertpot.com
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!
They also operate "SMTP servers" that violate the applicable RFPs, have done so for many years, and are not concerned about the potential damage that can result: https://lee-phillips.org/gmailRewriting/
If you’re going to complain about the standards-compliance of other people's services it’s important to understand the standard first.
“ The MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy.“
Generally MSAs are permitted to do almost anything. Your reading of the RFC which requires MSAs to merely reject instead of modifying messages is not backed by any of the language in the RFC. Essentially, you seem to misunderstand “may” “must” and “should” as used in these documents.
The meaning of the whole section is clear, and I stand behind what I wrote.
There are only 5 MUST NOTs in 6409 and there are zero SHOULD NOTs. The standard permits the MSA to do pretty much anything it wants to do. I think you should begin by reading 2119 "Key words for use in RFCs to Indicate Requirement Levels".
That's not even true. If anyone cares about this they should just read the texts. I'm certainly not going to argue this any further. We're looking at the same page and seeing different words.
It actually says this:
"However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered"
In other words, the opposite of what you claim. You can keep banging on this if you find it useful, but I'm not going to read any more of your comments.
On the other hand, the words "must" and "must not" specify absolute requirements and prohibitions of the standard, respectively.
The clear wording would be "... should only alter X" which makes it clear that altering things other than X needs be be done with full understanding of the implications.
They wouldn't be a good server to use, but they'd be one compliant to the specification.
--> What this tells you is that abiding by the spec is not everything, it just sets minimum interoperability guarantees.
Made me hate pretty much all footers, especially the bloated corporate ones.
But note that they are still violating the RFPs, if they rewrite headers for people who fail to jump through these hoops. They can implement their spam protections (if that's the purpose) while remaining compliant by rejecting the emails in question.
From the Article:
> "Google’s CardDAV server silently wipes out all kinds of data it doesn’t care about."
How is this "bad" functionality treated differently than issues found and publicized after a 90-day-count-down in the security disclosure universe?
They likely have known about their noncompliance, and they must know the impact; they are a technically savvy group. Plus I presume they have the financial resources to fix this with a year-to-year rising stock price currently at 1,095.50 USD.
"... moving on to the next project" is irresponsible after unleashing a service which when used correctly WILL corrupt users' data.
For one, these aren't security issues.
Also, they do document the parts of the standards that they don't support or adhere to:
https://developers.google.com/google-apps/carddav/
Their documentation could probably be more complete, but it does say, for example, that they don't support user defined fields on WebDAV requests.
I suppose they could have opted to not mention CardDAV or the other standards and just published an API called GCard or something like that.
They do mention that interoperating with Apple's operating systems is working, so that may be what determined the subset they care about.
> service which when used correctly WILL corrupt users' data
So that comes back to who gets to define what correct use is? If you follow the Google documentation and are losing data, then I agree with you. They should fix the problem or update the documentation.
> "We have not implemented the full specification, however many clients such as Apple iOS™ Contacts and Apple Mac™ OS should interoperate correctly."
They've explained they're non-conformant so all is well IMO.
Thanks for the corrections and critique criddell.
Also Goole doesn't even parse the date time in xml sitemaps 100% correctly and that's only a 4 page RFC!
* break compatibility with Outlook
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".
You can of course deviate from certain parts of the spec... dropping unknown fields as you mentioned might be a reasonable tradeoff. But then that deviation has to be documented. It isn't.
You're completely leaving out the other issues that the author describes: Timing out TCP sessions, discarding UIDs. Both things are not reasonable design choices in any world. And then the response to bug reports.
Has to be documented in order to do what? To claim to be standards compliant? Do they ever make that claim?
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.
If anyone wants to do it in Docker, I have a really simple Dockerfile here:
https://github.com/sumdog/bee2/tree/master/dockerfiles/Radic...
It's a bit messy to set up but the config file is extensively documented and you generally only need to touch it in the initial setup.
For CardDAV: https://github.com/owncloud/contacts could be used as a frontend, since it advertises it's talking to CardDAV-backend, but it's not actually deployable as a standalone interface. It's better than infCloud both architecture-wise and UI-wise, and could be the best opensource solution available, if you're willing to adapt this frontend to stand-alone usage (or integrate into whatever you need it for)
I used to feel sufficiently uncomfortable about handing reams of personal data to Google that it stopped me using calendar services on my phone - so it's actually made an appreciable difference to my life.
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.
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.
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.
Delightful.
I would imagine the same is true for CardDAV, not only at Google.
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.
There just isn't any money is letting users access and control their own data in a standard way.