Social media

You run accounts for clients, or several brands of your own. The login is the small part of the problem. Platforms match accounts by the device that opens them and the network they arrive from, and two accounts opened in one browser share both.

In ARMANOS a profile is a separate browser with a separate data directory. On ARMANOS Browser that directory is fork-profiles/<profile id> inside the app's own data folder. Cookies, local storage, IndexedDB, service workers, the cache and saved logins live there and nowhere else.

Compare that with the usual answers. A second profile in a plain browser gives you a second cookie jar on the same device. Incognito gives a clean jar on the same device, then forgets the session you needed to keep. A VPN changes the address and leaves the machine untouched. A fingerprint extension edits values from inside the page, after the page has already started running.

• Its own data directory

  Cookies, storage, cache and saved logins stay inside one folder per profile and are never shared.

• Its own device

  The fingerprint is derived from the template, the profile id, the generation and the engine version. It is computed at launch, not stored, so the same profile is the same machine everywhere.

• Its own exit

  HTTP, SOCKS5 or your own server over SSH. If the proxy or the tunnel will not come up, the launch is refused rather than going out from your home address.

• Its own clock and language

  When the proxy country is known, the timezone and the language stack come from that country instead of from your computer.

• Its own extensions

  Chosen per profile, from the built-in catalogue of 11 or installed by store link with the signature checked.

• Its own start page

  The profile opens on a local page that shows the exit address, the engine version and the fingerprint the browser was actually handed.

The scenario is a record in packages/shared/src/index.js, read when the profile is created. It decides the start address, the injected bundle, which blocklists load, whether links are cleaned, which first-party rules apply and which action counters the profile keeps.

On ARMANOS Browser all of that is written before launch as a small extension generated for that one profile: the compiled block rules, the parameter stripping and the in-page part. If it cannot be written, the profile does not open at all. A browser that looks protected and is not would be worse than a refusal you can read.

Blocking is deliberately narrow. The social list holds cross-site tracking hosts only. Sign-in, CDN, media, token and captcha hosts are absent on purpose, because a profile that cannot log in is not a protected profile, it is a broken one.

• Start address

  https://www.instagram.com, unless the profile names its own.

• Blocklists

  The general, LinkedIn and social lists together, 74 distinct entries after merging.

• Link cleaning

  40 tracking parameters stripped on navigation, including igshid, mibextid, fbclid, ttclid, twclid, epik and li_fat_id.

• In-page suppression

  navigator.sendBeacon calls are dropped, and WebSocket frames of type TYPING, READ_RECEIPT and SEEN are not sent.

• First-party telemetry

  Two rule sets matched by path, each fenced to its own hosts: one for LinkedIn, one for the Meta, X and Pinterest group.

• Safe pace

  Ten action counters plus a 200 action daily ceiling, both ramped over the first seven days.

The scenario names LinkedIn, Facebook, Instagram, X, TikTok and Pinterest. Its three blocklists merge into 74 entries: general web trackers, LinkedIn's off-site pixels, and the cross-site infrastructure of the five social platforms.

A platform also watches you with its own requests, from its own address, and no domain list can catch those. That is what the path rules are for, and each set only fires on the hosts it belongs to. The LinkedIn set contains the bare words beacon, telemetry and /px/, which are safe on one known site and reckless across five.

The two most valuable rules here are Meta's cross-app handshake, facebook.com/ig_xsite_user_ and instagram.com/accounts/xuserid. That is the call which ties a Facebook account to an Instagram one, and it fires on a plain page load of either site.

TikTok gets less, and we would rather say so than let the table imply otherwise. It has thirteen entries in the cross-site list and its click identifier is stripped from links, but it has no first-party rule set, because none has been measured against it yet.

Two of the five fingerprint templates are mobile: Android phone and Android tablet. Behind them stand 22 phones and 7 tablets, one line each: screen in layout points, pixel density, the GPU string exactly as ANGLE reports it on Android, cores, memory and the vendor's own fonts.

A profile is given one of those devices whole. Nothing is drawn separately, because a Pixel screen with Samsung fonts and a Xiaomi GPU is not a rare handset, it is a tell. The model travels only in client hints. Modern Chrome on Android reports a frozen user agent, Android 10 and the letter K, so writing a real version and model there would give the profile away in the first header.

Three things a seed cannot set are set at launch. The window is resized over the debugging protocol, because desktop Chromium refuses windows narrower than about 500 points and a phone whose window is wider than its own screen contradicts itself in one line. Orientation is derived from the size, mouse events are turned into touches, and every new tab is held until it has been dressed. Phone profiles also get the three Android connection fields, with a link speed, a round trip time and a ceiling that agree with each other.

Choose the phone when the account lives on a phone: a creator posting from Instagram or TikTok, or a page whose audience and notifications are mobile. Choose the tablet when you want mobile layout with desktop client hints, which is exactly what real Chrome on a tablet reports.

navigator.userAgent

Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/153.0.0.0 Mobile Safari/537.36

navigator.platform

Linux armv8l

Client hints: model

moto g84 5G

Client hints: mobile

true

screen

393 x 873, devicePixelRatio 2.75

navigator.maxTouchPoints

5

hardwareConcurrency / deviceMemory

8 / 8

WebGL renderer

ANGLE (Qualcomm, Adreno (TM) 619, OpenGL ES 3.2)

navigator.connection.type

cellular

downlink / downlinkMax / rtt

2 Mbps / 100 Mbps / 100 ms

fonts

12 Android families, Moto Sans among them

timezone / languages

America/Argentina/Buenos_Aires, es-AR

One phone profile as the app generates it, with no proxy set. Device, country and link quality were all derived from the profile id, so this profile gets these same values on every launch. Add a proxy and the country, the clock and the language stack come from its exit instead.

A profile created five minutes ago, with an empty cookie jar, no history and nothing cached, is a signal by itself. The warm-up robot browses ordinary public sites inside that profile first, so the account opens in a browser that has been used. In the app the button says Build up browsing history.

The pool is 30 addresses in six groups: search, news, shopping, reference, media and everyday sites. Nothing in it needs a login. A robot that lands on a sign-in wall produces no history and a run of failed sessions instead, which is worse than doing nothing.

Selection and order are shuffled for every profile with a Fisher-Yates pass rather than a random comparator, because a biased shuffle makes some orders far more common than others. Two profiles that walked the same sites in the same order have only traded one correlator for another.

Per site the robot builds six steps: open, let the page settle, scroll, pause, scroll further, pause. The dwell is a range around the number you set, from 0.6 to 1.4 of it, and the scroll distances vary. It runs on the same automation engine as your own scripts, with the same progress, the same stop and the same concurrency.

1. 1

   Create the profile with its scenario, template and proxy

   Pick the country you will work from. The clock and the language follow the exit, so this is the moment that decides them.

2. 2

   Warm it before the first login

   Six to twelve sites at twenty seconds each is a reasonable first run. Up to five profiles can warm at once.

3. 3

   Sign in and stay inside day one

   Day one allows 40 actions, three posts, five direct messages and one account switch.

4. 4

   Let the ramp finish

   The ceiling rises every day and reaches the full 200 on day seven. The card shows which warm-up day the profile is on.

• Sites per run

  1 to 40, six by default. If your groups hold fewer addresses than you asked for, the app counts the real number and says so.

• Seconds per site

  5 to 300, twenty by default, spread from 0.6 to 1.4 of that per site.

• Groups

  Search, news, shopping, reference, media and everyday sites, any combination.

• Your own list

  Up to 60 addresses of your choosing, which then replace the built-in pool for that run.

• At once

  Up to five profiles in one run, each with its own selection and its own order.

The scenario carries a recommended ceiling of 200 actions a day. An action is a top level navigation in a profile window, reported to the app, counted per profile, reset on the first access of a new day and kept in a small file so a restart does not lose the count.

A new profile does not start at 200. The warm-up ramp gives 20, 35, 50, 65, 80, 90 and 100 percent of the ceiling over the first seven days, counting the day of creation as day one. Day one is 40 actions.

Ten separate counters run alongside it, each with its own daily maximum and its own warning threshold, each ramped by the same curve. The profile card turns amber at the threshold and red at the ceiling. Nothing is ever blocked: the app cannot know that your fiftieth profile view is riskier than your fifth, and pretending it can would only teach you to ignore the colour.

These numbers are our recommendation, not a platform rule. Platforms do not publish theirs, and what they tolerate depends on the age, the history and the standing of each account. Treat the ceiling as a brake, not as permission.

The synchronizer mirrors one running profile into the others in real time. You pick a master profile among the open ones, then the target profiles that repeat it. Two open profiles is the minimum, which the free plan's two profiles exactly cover.

On ARMANOS Browser there is no preload script to capture with, so a small agent is injected into the master's page under a random property name that is not enumerable. It queues up to 500 events, the app drains that queue every 120 milliseconds and applies each event to the targets. Navigation is mirrored by watching the master's address, and a target that closes is dropped from the set.

Which tab counts is asked of the pages themselves, through document.visibilityState, and the answer is remembered for the session. That matters more than it sounds. A profile with a start page has two tabs, ours opens first, and choosing by order of appearance mirrors a page nobody is looking at.

The windows are arranged by the tiling button, on the display where your cursor is, in a grid sized to the number of open profiles. It refuses when a cell would come out smaller than 420 by 320 points and says how many windows it could not place. Ten windows need a large screen.

• Mirrored: navigation

  When the master's address changes, every target loads the same address.

• Mirrored: clicks

  By CSS path first, and if the element is not found there, by the position as a share of the viewport.

• Mirrored: scrolling

  The master's scroll position, throttled to one event per 120 milliseconds.

• Mirrored: field values

  The value of an input or textarea, applied and announced to the page with an input event.

• Mirrored: navigation keys

  Enter, Tab, Backspace, Delete, Escape and the four arrows.

• Not mirrored

  Rich text composers without a value property, file uploads, drag and drop, hover and anything drawn on a canvas.

Everything above is about the device, the network and the counters. None of it writes a caption, picks a hashtag or decides what to answer under a comment. There is no content generator and no post scheduler in the app, and we would rather name that than let the word automation imply it.

The synchronizer repeats what you do. Ten windows doing something a person would not do is that thing done ten times. Use it for the mechanical half, the same navigation, the same form, the same settings change, and do the part that has to read as human one window at a time.

A profile is also only as good as the address behind it. A residential exit shared with a hundred bot farms undoes the isolation the rest of this page describes. Choose the proxy as carefully as you choose the fingerprint, and check the exit on the profile's own start page before you sign in.

And nothing here claims a platform cannot tell. What is on offer is separation and a consistent device, held the same way on every launch, on every machine you sign in from.