Trang này chưa có bằng ngôn ngữ của bạn. Bạn đang đọc bản tiếng Anh.
Cookies
Cookies in and out of a profile
- Ten
- Fields the import reads
- 3
- Ways an expiry may be spelled
- One
- Profiles per file
- Arrived and refused
- What the import reports
What the file holds
Export writes one file of plain JSON: a list of records, one per cookie.
Each record carries the eight things below that decide where the cookie goes back and how long it lives there, and whatever else the engine gave with them. The import reads two more: a whole address, used in place of one built from the domain, and the session flag.
Import reads either a bare list or an object with a cookies list inside it, and it takes the expiry under any of the three names an export is likely to use.
A record marked as a session cookie keeps no date at all, even when the file carries one.
Name and value
The session token itself, and the name the site reads it by.
Domain and path
Which site gets the cookie back and which part of that site.
Secure and HttpOnly
Whether it travels only over an encrypted connection and whether page scripts may see it.
SameSite and expiry
Whether it goes along on a request begun at another site, and when it dies.
Export takes the whole jar
Export reads everything the profile holds rather than the cookies of the page in front of you. The number in the message is the number of records written to the file.
Where that jar sits is decided by the engine the app is set to, and so is whether the profile has to be open.
The file is named after the profile by default, with anything outside letters, digits, dot, dash and underscore replaced, and you choose where it goes.
| The engine in the settings | Where the jar is | To read it or write it |
|---|---|---|
| ARMANOS Browser | Inside the running browser | The profile has to be running in that build |
| Built in engine | In the profile folder on disk | Open or closed, both work |
You are told, not handed an empty file
The file is a set of live sign-ins
Whoever opens that file can sign in as those accounts, so the app says it before the save dialog rather than after.
The file is held by permissions and not by a password. On macOS and Linux it is written for your account alone, and those permissions travel with the copy.
On Windows permissions are not what protects a file. There it takes the rights of the folder you saved it into.
The warning comes first and the save dialog opens only if you continue, so the file is never written by a misclick.
Delete it once the move is done
What did not arrive is counted
A browser turns a cookie away for plenty of ordinary reasons, and one bare number of what arrived reads as a session moved in full.
So the message carries both numbers, and somebody the site still asks to sign in knows where to look.
Three of the reasons below are the app's own refusals and the last one comes from the browser, though the message on screen counts them as one number and lays them all at the browser's door.
| What the file had | What happens to it | How it counts |
|---|---|---|
| No domain and no address | There is nowhere to send the cookie back to | Refused |
| No name | A record without a name is not a cookie | Refused |
| An expiry the browser cannot read | The date is dropped and the cookie still goes in | Arrived and refused both |
| A rule of the browser itself | Secure on a plain address, or a domain that does not match | Refused |
What this does not do
- It does not translate another product's format. What it reads is an ordinary cookie record, so a file shaped some other way has to be reshaped first.
- It does not say which rule refused which cookie. The count is on screen and the detail behind it is not.
- It moves one profile at a time, with no load across a selection and no call for one in the local API.
- It does not sign you in by itself. A site weighs the device and the address too and can ask for the session again.
How to check
Every claim above sits in one file, and most have a stand you can run.
- Export reads the whole jar, not the page in front of you
- apps/desktop/src/lib/forkPage.js · apps/desktop/test/cookie-transfer.js
- SameSite and the expiry survive the move in both directions
- apps/desktop/test/cookie-transfer.js
- Import counts what was refused beside what arrived
- apps/desktop/src/main/main.js
- The cookie file is written for your account alone
- apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
- A flow reads a cookie only for the site its step stands on
- apps/desktop/src/main/main.js · apps/desktop/test/rules-and-runs.js
Questions
- Can I bring a file from another tool?
- If it is an ordinary list of cookie records, yes. We read the fields a cookie has, not one product's own database.
- Why am I asked to open the profile first?
- With the app set to ARMANOS Browser the jar lives inside that running browser, so a profile it is not running has nothing to read. Being told that beats a green message over an empty file.
- Do the two numbers in the message add up?
- Not always. A cookie whose date could not be read goes in without it and is counted on both sides, because a lost expiry is worth telling you about.
- Is the exported file encrypted?
- No, and the app says so before it writes. Permissions hold it on macOS and Linux, and on Windows it takes the rights of the folder you picked.
- Will the account still be signed in after the move?
- Often, though not always. The site weighs the machine and the address too, so a session arriving without its own fingerprint looks like a new device.
Take one session with you
Install ARMANOS, open a profile, and write its jar to a file you carry yourself.