Чому ми не зберігаємо копію вашої адресної книги

Очевидний спосіб побудувати продукт для спільних контактів — імпортувати все. Стягнути кожен контакт із кожного підключеного облікового запису у власну базу даних, оголосити її джерелом правди й виштовхувати зміни назад. Так інженерія простіша: запити швидкі, схема під контролем, а синхронізація зводиться до «порівняй мою базу з їхньою».

Ми свідомо будували Rolyio не так. Ваші контакти живуть у Google і Microsoft. Rolyio зберігає звʼязки спільного доступу та права — посилання між копіями контакту в різних облікових записах, — а не дзеркало вашої адресної книги. У цій публікації пояснюємо, що це означає конкретно й чому ми вважаємо цей компроміс правильним.

Що ми зберігаємо насправді

Коли ви підключаєте обліковий запис і ділитеся лейблом, у базі даних Rolyio зберігаються:

• Записи облікових записів і токени OAuth — токени зашифровані у спокої за допомогою AES-256-GCM.
• Метадані лейблів — тонкий шар поверх справжніх структур провайдера. Лейбл і є групою контактів Google чи категорією Outlook; ми зберігаємо, якій групі/категорії він відповідає і з ким ним поділилися.
• Спільні доступи та ролі — хто має «Перегляд», «Редагування» чи «Може ділитися далі» на якому лейблі, включно з доступами в очікуванні для людей, які ще не входили.
• Кластери звʼязків — записи, які кажуть: «контакт X в обліковому записі Google власника і контакт Y в Outlook отримувача — це та сама людина». Це серце системи: зіставлення ідентичності, а не зберігання вмісту.
• Стан синхронізації — інкрементальні токени синхронізації, відбитки змін для захисту від «еха» та часові мітки для розвʼязання конфліктів.

Чого там немає: таблиці з вашими контактами. Під час синхронізації дані контактів протікають через механізм синхронізації з одного облікового запису провайдера в інший, керуючись звʼязками та ролями, — і не осідають у сховищі на нашому боці.

Є один свідомий, обмежений виняток: коли спільний контакт видаляють, ми зберігаємо знімок у Кошику протягом 30 днів, щоб випадкове видалення — ваше чи колеги — можна було відкотити. Через 30 днів знімок стирається. Це страхувальна сітка з терміном придатності, а не тіньова адресна книга. (Її можна очистити й самостійно; див. Кошик і відновлення та видалення ваших даних.)

Чому звʼязки кращі за дзеркала

Менша поверхня для витоку

Архітектура безпеки починається з незручного припущення: скомпрометувати можна будь-яку систему. Питання лише в тому, що дістанеться зловмиснику. У дзеркальній архітектурі відповідь — усі контакти всіх клієнтів: імена, номери телефонів, звʼязки між людьми — усе в одній базі. В архітектурі звʼязків даних контактів, за якими полював би зловмисник, там просто немає. Є метадані — які лейбли з ким спільні — плюс зашифровані токени, ключ до яких живе окремо від бази.

Ми воліємо не бути медовою пасткою. Найменш ризиковані дані — ті, яких ви ніколи не зберігали.

Жодного другого джерела правди

Кожне дзеркало рано чи пізно розходиться зі своїм оригіналом. Віддзеркалена база контактів і копія Google неминуче «розповзуться» — невдала синхронізація тут, стан перегонів там — і тоді продукту доведеться вирішувати, яка версія справжня. Користувачі програють у будь-якому разі: або інструмент показує застарілі дані, або, ще гірше, «виправляє» копію провайдера власною застарілою версією.

Залишаючи провайдера авторитетним джерелом, Rolyio обходить цілий клас проблем. Те, що ви бачите в contacts.google.com чи Outlook, і є правдою. Створіть групу контактів у Google — вона зʼявиться в Rolyio; перейменуйте лейбл у Rolyio — він перейменується в Google. Робота механізму синхронізації — переносити зміни між копіями у провайдерів: із розвʼязанням конфліктів за принципом «останній запис перемагає» з урахуванням ролей і захистом від «еха» на основі відбитків, щоб наші власні записи ніколи не сприймалися як правки користувача. Механіка задокументована в статті як працює синхронізація.

Спільний доступ, який закінчується, коли закінчується

Звʼязки мають ще одну властивість, якої бракує дзеркалам: їх дешево розірвати — повністю. Коли ви скасовуєте спільний доступ до лейбла, Rolyio прибирає спільні контакти з адресних книг отримувачів і видаляє відповідні звʼязки. У нашій базі не залишається жодної залишкової копії того, що бачив отримувач, — бо її там ніколи й не було. Відкликання — це віднімання, а не проєкт із прибирання.

Та сама логіка діє, якщо ви залишаєте Rolyio зовсім. Ваша адресна книга ніколи не була в наших руках, тож немає чого експортувати назад і не треба вірити, що ми все зітремо: видалення облікового запису видаляє звʼязки та зашифровані токени, а ваші контакти залишаються рівно там, де були завжди, — у вашому обліковому записі Google чи Microsoft.

Чого це коштує нам

Чесність вимагає перелічити й недоліки, бо ми платимо за них щодня:

• Синхронізацію складніше будувати. Без центральної копії кожна операція має міркувати про N копій на боці провайдерів, поєднаних звʼязками. Розвʼязання конфліктів, семантика видалення (надгробки, що поважають ролі) і дедуплікація за email — усе це має працювати в розподіленому середовищі.
• Ми успадковуємо обмеження провайдерів. Google не дає push-сповіщень для контактів, тож бік Google синхронізується опитуванням приблизно кожні 60 секунд з інкрементальними токенами. Microsoft Graph дає вебхуки, тож бік Microsoft працює майже в реальному часі — але Graph не дозволяє перейменовувати категорії. Дзеркало могло б замаскувати такі асиметрії; ми показуємо їх відкрито й проєктуємо з їх урахуванням.
• Деякі функції просто поза грою. Усе, що вимагає аналізу вашої повної адресної книги на сервері, суперечить тому, що повної адресної книги в нас немає. Ми вважаємо це обмеження перевагою.

Тест, який ми застосовуємо

Оцінюючи нову можливість, ми ставимо питання: чи можна побудувати це зі звʼязків, ролей і API провайдерів, не накопичуючи даних контактів на нашому боці? Якщо так — будуємо. Якщо ні — шукаємо іншу форму. Міжекосистемний спільний доступ між Google Workspace і Microsoft 365 — визначальна функція продукту — цей тест пройшов: йому потрібні звʼязки ідентичності між екосистемами та синхронізація з урахуванням ролей, а не центральний склад контактів.

Якщо така архітектура збігається з вашим уявленням про те, як інфраструктура має поводитися з вашими даними, — підключіть обліковий запис і подивіться, що саме ми запитуємо: інкрементальні OAuth-дозволи розповідають ту саму історію, що й ця публікація.