Use cases

The server acts on the pages of the sites your profile lists, in the sessions you signed in to. You sign in once, in the browser’s dedicated profile; the model then works in that session. It types a password only from a credential file you wrote.

Step by step

• Reach the page, with open_tab or navigate: the server opens http and https addresses only, and counts the page against the ceiling of your profile.
• Read the form, with observe: it reads only a site of your profile, masks the sensitive fields in the image and withholds their values.
• Fill a field, with fill: it types a text into an ordinary field, and fills a password only from a credential file bound to that exact origin.
• Choose in a list, with select_option: by the option’s text or value, in a native list only.
• Submit, pay, delete, with click or press_key: a payment, an irreversible deletion or a change of secret waits for your answer in a window on your screen; Enter in a payment form too.
• Keep a capture, with save_evidence: a masked image, manual-<label>.png, in the encrypted directory.
• Fetch a document, with click: a download started by the click lands in downloads/<operation_id>/ of the encrypted directory, under a safe name; no tool opens it.
• Wait for the result, with wait: until the page has loaded, shows a text, or shows an element with a role and a name, at most 60 seconds.

What leaves your machine at each step, and what the journal and the automatic captures let you check afterwards, is on What leaves your machine, and what the server never does.

What has been run, and what has not

Run, as the README records it: a Chromium browser, with its profile in a throw-away gocryptfs volume and its debugging port on the loopback interface, was attached; the server opened a page of a public shopping site, filled its search field, pressed Enter and observed the results. The typed text does not appear in the journal.

Run on the operator’s workstation with the operator’s own gocryptfs volume mounted: the confirmation window of the server, on a local payment page. Three outcomes were observed: a refusal (confirmation_denied, the page received nothing), an acceptance (the click was made, the page received one request) and 91 seconds without an answer (confirmation_expired, the page received nothing).

Not run by the project to date: a renewal, a declaration or a payment on a real site. The test suite plays the payment gate on local pages, with fake window programs in place of kdialog and zenity.

Two limits weigh on these tasks. While the server is attached, the browser refuses every download, in your own tabs too, except in the short window around one of the server’s clicks or Enter keys; a download a page starts more than half a second after a load ends is refused, and you fetch that file yourself. Accepting a dialog that asks for a payment, a deletion or a change of secret is always refused, since no capture can be taken while it is open: you answer it in the browser. The others are on Limits.