Web Passwords (wwwfill)

A web password (internally a wwwfill entry) is an ordinary credential record that is looked up by domain rather than by label. Web passwords exist so a host can serve browser-style autofill: name a domain, get back the username/password pair(s) stored for it - and, in the default access mode, do so without a per-request confirmation on the device.

This page describes the web-password model as it is observable over the USB-Slave Serial Protocol interface. There is no separate “web password” transport; web passwords are read and written with opcodes 5, 7, 8 and 11 of the serial protocol.

The model

A web password is a normal record placed in a reserved group named wwwfill. The group name is the type marker - there is no separate flag. The record’s fields are used as follows:

Record field	Holds	Notes
group	wwwfill	The literal reserved group name (8-byte field).
optional	the full domain	Up to 83 bytes. This is the lookup key.
label	generated	First up to 13 characters of the domain, plus 3 hex characters. See below.
username	the account username	Up to 50 bytes.
password	the account password	Up to 50 bytes.

Because a web password is an ordinary record, it also appears in the GET_LABELIDX enumeration under its generated label. Filter on group wwwfill (or use GET_WWWFILLIDX) to separate web passwords from regular entries.

Label generation

When the device stores a web password it generates the label itself, so a client never sets it. The scheme is observable through the enumeration commands:

• the label prefix is the first up to 13 characters of the domain string (not the first dot-delimited component - for login.example.com the prefix is login.example); plus

• 3 hexadecimal characters (0-9a-f) that keep the label unique when several accounts share a long domain prefix.

For example, domain example.com yields a label such as example.com4a2. A client should treat the label of a web password as device-owned and address web passwords by (domain, username) - never by manipulating the generated label directly.

Multiple accounts per domain

One domain may have several username/password pairs; each gets a distinct label suffix. The uniqueness key is the exact full domain plus username - adding a second entry with the same (domain, username) is rejected as LABEL_EXISTS.

Domain matching is case-insensitive but requires an exact full-domain match to return a hit; a partial or parent-domain string will not match. The domain is validated as a free-text string against the label character set - it is not parsed as a URL and no DNS structure is enforced. The host is responsible for reducing a URL to a bare host (strip scheme, port, and path) before using it.

Reading and writing web passwords

Op	Name	Request	Response
5	GET_WWWFILL	<domain> <index:int>	<status> [<username> <password>]
7	GET_WWWFILLIDX	<index:int>	<status> [<domain> <username>]
8	PUT_WWWFILL	<domain> <username> <password>	<status>
11	DEL_WWWFILL	<domain> <username>	<status>

Looking up by domain (op 5). Send the domain and a 0-based index. The response carries the username and password for that match. The status is OK (0) if this was the last match for the domain, or MORE_LABELS (9) if more accounts exist at higher indices. MORE_LABELS is a success code: iterate index = 0, 1, 2, ... while the status is 9 and stop after you receive OK. If no account matches, the status is ENTRY_NOT_FOUND (1).

Enumerating all web passwords (op 7). Iterate the index from 0; each response returns the domain first, then the username. Stop when the status is OUT_OF_INDEX (4).

Adding (op 8). Send domain, username, and password. Fields over their maximum lengths are truncated. On a domain that fails the character set the status is BAD_DOMAIN (8); on a full store, NO_SPACE (6).

Deleting (op 11). Both domain and username are required to disambiguate multiple accounts per domain. Note that this command rejects over-length input with a session-fatal PARSE_ERROR - enforce the field maximums client-side.

See USB-Slave Serial Protocol for the full framing, worked byte examples, and the recommended delete-then-put strategy for overwriting.

Confirmation behavior

In the default Normal access mode (selected in the device’s Admin -> Slave security menu), exactly two web-password operations are exempt from on-device confirmation:

• GET_WWWFILL (op 5) - read the password(s) for a domain; and

• PUT_WWWFILL (op 8) - add (or, on an existing (domain, username), overwrite) a web password.

This reduced-confirmation path is what makes unattended browser autofill practical: a helper can read and write web passwords without a device button press on every request. The other two web-password commands are not exempt - GET_WWWFILLIDX requires a first-time confirmation (then streams), and DEL_WWWFILL requires confirmation. In Ask all mode every command, including the two above, requires confirmation; in Allow all mode none do.

The first-time confirmation for a GET_WWWFILLIDX enumeration in Normal mode. Once allowed, the rest of the enumeration streams without further prompts.

Note

Design implication for integrators: in Normal mode a host that names a domain can read that domain’s stored web password(s), and can add or overwrite web passwords, without device interaction - but it cannot enumerate all web passwords, delete them, or touch non-wwwfill entries without a device confirmation. Scope your integration accordingly, and treat the on-device access mode as a user-controlled security boundary.