Zum Inhalt springen

Diese Seite gibt es noch nicht in Ihrer Sprache. Sie lesen den englischen Text.

Sign-in details

Sign-in details beside the profile

The account a profile signs into has a login, a password, a sign-in page and a note, and all four live on the profile itself. The operating system seals the password where it can, our server never sees it, and on the built in engine one press puts the pair into the open form.
Login, password, page, note
What a profile holds
Never
Sent to our server
Sealed where the system can
On disk
The built in engine
Filling into a window

Four fields on the profile

Twenty accounts are twenty rows in a sheet that lives somewhere else, and walking over to it is the slowest part of the day. Here the pair sits on the profile that uses it, beside its one time code key.

A profile with something saved wears a small mark on its card in the list, so you can see which accounts still live in the spreadsheet.

  • Login

    The name, the mail address or the phone the account answers to. A line break is stripped out: it breaks the form and the row alike.

  • Password

    Kept exactly as typed, spaces at the edges included. Tidying those away is a silent way to break a sign in.

  • Sign-in page

    The address you go to. It has to start with http or https, and anything else is refused as you save.

  • Note

    The half sentence with nowhere else to live: the recovery mail, the seller, the day it was bought.

Who gets the password

The list of profiles is drawn without it. What reaches the screen is the fact that a password exists, not the password.

The value itself comes down on a request of its own, and only when you press show or copy. Filling never brings it to the window at all: the main process reads it and writes it into the page.

An empty password box means leave it alone. Once the real password has been loaded into it, clearing the box drops the password and keeps the login.

Filling the open window

The browser's own machinery writes the value, and the page receives the input and change events it waits for. It is not a keystroke per letter: a form counting keystrokes sees one write, not twelve.

The password field is picked by what the form calls it rather than by standing first. A sign-up form above the sign-in form keeps its own fields, and so does the search box at the top.

The window you are looking at is the one that gets filled, not the last one a flow opened. A profile launched without a window is filled just as quietly and is never pulled onto the screen.

A page with search, a sign-up form and a sign-in form
Login and password in the sign-in form, both events seen
A page with a search box and no sign-in form
Nothing written, nothing sent

Measured by running the fill in a real browser window against both pages. On the search only page the box stays empty and no suggestion request leaves.

Honest refusals

A button that does nothing is worse than a button that says why. Each refusal below names its own reason on screen.

  • ARMANOS Browser is open

    Filling reaches only the window the app draws itself, and this one is drawn by a separate process. The refusal says so and points you at copying.

  • The profile is closed

    There is no window to fill, so the app asks you to open the profile first.

  • Nothing is saved

    This profile has no pair yet, and the app says so instead of reporting a fill of nothing.

  • No sign-in form

    The open page holds no form the rules accept, and not one field on it is touched.

Where the pair is kept

The password does not lie in the profile file as text. The operating system seals it with the machinery that holds your other passwords, and the app carries no key of its own.

A key that ships inside a program is not a key, because everyone who downloads the program has it. So a value the system cannot seal is written as it was typed and never passed off as sealed.

A value that will not open is not a lost one

If the keychain refuses when the app starts, the sealed form stays where it is rather than being replaced by emptiness, and nothing is handed to the form. An unreadable value would fail the sign in and look like a forgotten password.

What travels and what stays

While you are signed in, profile settings are mirrored through your account: name, group, scenario, fingerprint template, proxy, tags and notes. The pair is not among them, and no column exists on the server that could hold it.

Two roads take it off this machine, and you open both on purpose.

Road off this machineDoes the pair travel?
Settings mirrored through your accountNo, and a teammate opening a shared profile arrives without it
A transfer file for a second computerYes, inside the file sealed with the passphrase you set
The folder your own cloud syncsYes, the same sealed file by the same road
A settings export to a plain fileOnly if you pick include: the app asks, and leaving it out is the default
Duplicating a profileNo, the copy starts with no pair of its own

What this does not do

  • It is not a password manager. One pair per profile, no vault, no search across accounts, no generator, and nowhere for the backup codes a site hands you.
  • Filling a window works on the built in engine only, and shipped builds start on ARMANOS Browser, so it is the exception. The button refuses, names the reason, and copying is the way across.
  • The sign-in page you save is a note. Nothing opens it for you, and the fill does not check which page it is filling.
  • Copying leaves the password on the system clipboard. Any program on this computer can read a clipboard, and the app does not clear it.
  • Sealing rests on the system keychain. A Linux desktop with no keyring service has nothing to seal with, so the pair is written as typed and owner only file permissions are the protection there.

How to check

Each claim above sits in one file. Two stands below run the product, and two read the source.

No call that sends profile settings carries the pair
apps/desktop/src/main/main.js · apps/desktop/test/login-stays-local.js
Filling picks the sign-in form and the page sees real input
apps/desktop/test/login-stays-local.js
The password is sealed on disk, and a value that will not open is not erased
apps/desktop/src/lib/profiles.js · apps/desktop/test/login-in-keychain.js
Only frames of the same site are filled
apps/desktop/src/main/main.js · apps/desktop/test/подстановка-входа-в-свои-рамки.js

Questions

Does the pair reach your server?
No. Profile settings travel while you are signed in, and the pair is not among them.
What opens the password on this computer?
The operating system, with the machinery that holds your other passwords. The app has no key of its own, and a value it cannot seal is written as typed.
Can the page grab the value as it is filled?
In the main document the writing runs in a world of its own that the page cannot reach into, unless the build has no separate worlds and falls back to the page's own. Inside a frame it always runs in the page's world, and only frames of the same site are reached.
Why is the first password field skipped?
Because the first one usually belongs to sign-up. The fill prefers the field the form marks as the current password and leaves a matching pair of new boxes alone.
Is there a master password on the app?
No. Anyone already signed in to this computer can open it, so the boundary that matters is your user account.

Keep the login where the account is

Install ARMANOS, save the pair on the profile that uses it, and fill it into the open form.