Багато відкритих вікон ще не означає справжню ізоляцію акаунтів. Стаття розділяє дві задачі, порівнює профілі одного браузера, віртуальні машини та браузери з ізольованими середовищами й пояснює, чому кожному акаунту також потрібен окремий IP.
Термін «мультивідкриття браузера» використовують дуже широко. Для одних це кілька відкритих вікон, для інших — кілька повністю незалежних цифрових ідентичностей. Різниця між цими підходами більша, ніж часто здається.
Насправді потрібно розв’язати дві задачі
Перша — конфлікт станів входу. В одному браузері Cookies і локальне сховище спільні. Якщо увійти в акаунт A, а потім в іншій вкладці авторизуватися в акаунті B, сесія A може бути витіснена. Це найпростіший рівень потреби.
Друга задача — пов’язування акаунтів. Платформи визначають, чи належать два акаунти одному оператору, не лише за Cookies; вони також аналізують характеристики пристрою та мережевий вихід. Навіть із розділеними сесіями два акаунти можуть бути пов’язані, якщо їхні браузерні відбитки однакові й вони використовують той самий вихід.
Багато людей розв’язують лише першу задачу, а потім дивуються, чому акаунти все одно залишаються пов’язаними.
Кілька профілів в одному браузері: лише половина ізоляції
Вбудовані профілі браузера мають власні закладки, розширення та стан входу, а Cookies між ними не змішуються. Для відокремлення робочого акаунта від особистого цього цілком достатньо.
Однак це не захищає від пов’язування акаунтів. Усі профілі працюють в одному браузері, тому характеристики пристрою залишаються однаковими, як і зовнішній мережевий вихід. Профілі добре розділяють сценарії використання, але не підходять для повноцінної роботи з багатьма акаунтами.
Вікна інкогніто ще слабші. Вони переважно не зберігають стан входу; відбиток і мережевий вихід взагалі не змінюються. Сприймати інкогніто як справжню ізоляцію — це лише створювати хибне відчуття розділення.
Віртуальні машини: сильна ізоляція, висока ціна
Віртуальні машини та Android-емулятори можуть забезпечувати незалежність на рівні операційної системи. Кожен екземпляр має власне системне середовище, а відбиток і сховище природно не спільні, тому ізоляція значно сильніша, ніж у профілів браузера.
Проблема полягає у вартості та ефективності. Кожен екземпляр споживає окремі системні ресурси. Три-п’ять екземплярів ще можна обслуговувати, але десятки швидко стають непрактичними. Налаштування мережі теж складніше, оскільки проксі потрібно конфігурувати окремо всередині кожного екземпляра, а масове керування стає неефективним. Такий підхід підходить для невеликої кількості акаунтів із високими вимогами до ізоляції, але не для щоденної роботи у великому масштабі.
Браузери з ізоляцією середовища
Ідея цих інструментів полягає в тому, щоб розмістити кожен акаунт в окремому середовищі: сховище незалежне, параметри відбитка незалежні, мережевий вихід можна прив’язати індивідуально, а кеш і Cookies між середовищами не спільні.
Це доповнює саме ту половину, якої бракує двом попереднім підходам: розділяється й рівень пристрою. Тому для роботи з багатьма акаунтами часто використовують саме цей шлях. Під час вибору варто перевірити два моменти: параметри відбитка не повинні повторюватися між середовищами, а прив’язка проксі має бути справді один-до-одного.
Чому виділений IP потрібно налаштовувати разом із середовищем
Якщо змінити середовище, але не змінити мережевий вихід, це схоже на використання кількох браузерів на одному пристрої. Платформа все одно бачить той самий IP, тому акаунти залишаються прямо пов’язаними на мережевому рівні.
Зворотний варіант теж не розв’язує проблему. Якщо змінити лише IP, залишивши те саме середовище, виходи можуть бути в дуже різних регіонах, а відбиток залишатиметься повністю однаковим. Така суперечність сама по собі є явним штучним сигналом. Обидва виміри мають бути незалежними одночасно.
Під час налаштування виходу легко не помітити WebRTC. Він може розкрити локальну мережеву адресу. Якщо перевірка показує, що IP доступу належить проксі, але WebRTC розкриває реальний IP, то проксі фактично налаштований неправильно.
Після налаштування перевіряйте в такому порядку
Спочатку створіть середовище, дайте йому назву та позначте відповідні акаунт і ринок. Потім налаштуйте мережевий вихід так, щоб його регіон відповідав позиціонуванню акаунта. Далі перевірте, що параметри відбитка не повторюються в інших середовищах, а часовий пояс і мова відповідають регіону виходу. Після цього на тестовому сайті переконайтеся, що проксі справді працює і WebRTC нічого не витікає. Лише тоді входьте в акаунт.
Порядок не варто змінювати. Якщо увійти до повного налаштування середовища, а потім змінювати параметри в процесі, легко викликати додаткову перевірку платформи.
Мережевий вихід також має залишатися стабільним. Часті короткострокові зміни є сильним сигналом аномалії, а кілька акаунтів з одним виходом можуть бути безпосередньо пов’язані. Саме тому під час вибору проксі зазвичай варто віддавати перевагу резидентським або виділеним типам.
Для команди потрібен додатковий рівень правил
Призначайте середовища окремим учасникам, щоб різні люди не працювали по черзі з одним і тим самим акаунтом. Ведіть зрозумілий список відповідності середовищ і акаунтів, щоб відповідальність була очевидною. Регулярно експортуйте та зберігайте резервні копії конфігурацій, щоб у разі несправності пристрою не довелося відновлювати все з нуля.
Можливості PurpleMark для мультиакаунтних середовищ підтримують централізоване керування та призначення середовищ учасникам. Відбиток і стан входу кожного середовища зберігаються окремо, тому незалежність акаунтів можна стабільно відтворювати без ручного складання конфігурації щоразу.
