26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
# Data collection protocol (draft)
|
|
|
|
1. Obtain institutional ethics/privacy review where required and use the
|
|
completed participant information and consent form.
|
|
2. Assign a random participant code. Do not put names or contact details in
|
|
filenames or the signature database.
|
|
3. Record device type, sampling setup, session date/code, and whether pressure
|
|
or contact-area data are available in a separate access-controlled study
|
|
log. Do not write unnecessary personal information into the signature CSV.
|
|
4. Collect several genuine samples per participant, with a short pause between
|
|
attempts. Mark examples explicitly as `genuine`.
|
|
5. If studying skilled or random forgeries, collect them only under the approved
|
|
protocol, keep the target identity in `user_id`, and label their type in the
|
|
`label` column. Avoid coercive or deceptive collection.
|
|
6. Use the common CSV columns `user_id,label,t,x,y,p,area,pen_down`. Each file
|
|
should contain one signature sequence; timestamp units must be consistent
|
|
within a dataset. Optional `p` and `area` fields should be blank or omitted
|
|
when unsupported.
|
|
7. Store raw files in `data/raw/own/`, restrict access, and keep them out of
|
|
version control. Store encryption keys separately from the database.
|
|
8. Keep participant-level identities together when making train/test splits.
|
|
Tune thresholds on a development set and report the final test set only
|
|
once. Report the number of participants, genuine samples, and each forgery
|
|
type alongside FAR, FRR, and EER.
|
|
|