feat: Make it configurable to disable federated sync addressbook

[T0mWz]

Issue

As an administrator, I want to have a list of trusted servers so that users
can collaborate on documents. I also want to create federated teams to make
sharing easier.
However, I do not want the system address book to sync automatically, as this
would result in me unnecessarily sharing personal data with all users across
different environments, from a privacy and security standpoint.

As a user, I want to be able to collaborate with a few users in another
environment via Federated Teams and Collaborative Document Editing.
However, I have no relationship with the majority of users in that other
environment. It is also undesirable to be able to see all individuals in my
system address book from that other environment.

From a security perspective, I want to encourage collaboration but not share
the personal data of all my users with other environments.

See related issue; #63437

Proposal

Make it configurable to sync a system address book between trusted servers.
I want to be able to configure trusted servers to create federated teams and
support collaborative document editing.
In other words, add a configuration option to exchange sync tokens, but make
it configurable to exchange the system address book.

Acceptance Criteria

• Trusted servers continue to serve as the foundation for federated teams and
  collaborative document editing, regardless of the address book sync setting.
• The shared_secret pairing and the CardDAV sync_token exchange with
  a trusted server continue to occur during every sync cycle, even if the
  address book itself is not being synced (necessary to continue validating the trust relationship and
  connectivity).
• There is a configuration option that allows an administrator to disable synchronization of the
  system address book (contact information/vCards) from a trusted server on a
  per-environment basis, without breaking the federation itself.
• When address book sync is disabled, no vCards are downloaded or saved locally,
  and the local system address book is not cleared
  by a potential full resync.
• Default behavior remains unchanged (address book sync is enabled by default),
  so that existing environments are not broken during an upgrade.

Implementation (current status in nextcloud-server)

New config option in config.php:

‘federation_sync_addressbook_data’ => false,

Default true → current behavior, so backwards compatible.

apps/dav/lib/CardDAV/SyncService.php
syncRemoteAddressBook() has been given a new parameter
bool $syncAddressBookData = true:

Step	true (default)	false
1. Create/look up local system address book	yes	skipped
2. Send sync report request to remote (authenticate with shared_secret, returns new sync_token)	yes	runs continuously
3. Download vCards + create/update/delete locally	yes	skipped

apps/federation/lib/SyncFederationAddressBooks.php

• IConfig added to the constructor; reads
  federation_sync_addressbook_data on each run.
• ensureSystemAddressBookExists(), markCardsAsPending(), and
  deletePendingCards() are only called if address book sync is enabled.
• A full resync is forced to false if address book sync is disabled
  (otherwise, the local address book would be cleared without syncing back).
• Status logging (setServerStatus, error handling for 401/other
  exceptions) remains unchanged—so the trust relationship remains visibly healthy
  regardless of the address book setting.

[come-nc]

If you are not removing the permission to get your cards from trusted servers the privacy issue stays the same, trusted servers have access to the personal data stored on your server. And the new setting will give a false sense of privacy while it does not prevent fetching.

[SebastianKrupinski]

Hi @T0mWz

The system address book sync is what allows users to find other users on a remote system with partial names... so doing this would essentially make remote users invisible unless you knew the entire federated user name "this user@remote system"

[T0mWz]

If you are not removing the permission to get your cards from trusted servers the privacy issue stays the same, trusted servers have access to the personal data stored on your server. And the new setting will give a false sense of privacy while it does not prevent fetching.

Hi @come-nc , A Trusted Server relationship is required to facilitate collaboration, for example collaborative document editing. When organizations wants to work closely together—such as a school or a research firm—where they are working on a project as part of a consortium, thus across organizational boundaries. The goal here is to encourage collaboration, but this shouldn’t automatically mean that an entire address book is shared between sites; rather, it should allow you to selectively specify what... For example to collaborate on document editing, create selective teams for federated share, create a federative deck, talk channel, etc..

[T0mWz]

Hi @T0mWz

The system address book sync is what allows users to find other users on a remote system with partial names... so doing this would essentially make remote users invisible unless you knew the entire federated user name "this user@remote system"

Hi @SebastianKrupinski , currently, you still have to ask someone for their federated username. But we're also working on a way to exchange them more easily—think of it like exchanging business cards. See for details nextcloud/contacts#4417

[come-nc]

If you are not removing the permission to get your cards from trusted servers the privacy issue stays the same, trusted servers have access to the personal data stored on your server. And the new setting will give a false sense of privacy while it does not prevent fetching.

Hi @come-nc , A Trusted Server relationship is required to facilitate collaboration, for example collaborative document editing. When organizations wants to work closely together—such as a school or a research firm—where they are working on a project as part of a consortium, thus across organizational boundaries. The goal here is to encourage collaboration, but this shouldn’t automatically mean that an entire address book is shared between sites; rather, it should allow you to selectively specify what... For example to collaborate on document editing, create selective teams for federated share, create a federative deck, talk channel, etc..

That does not answer my concern. Your PR is not removing permission from the trusted servers to read the addressbook, so there is no added privacy/security.