Remove password field handling claims

1 files changed, 2 insertions, 8 deletions

diff --git a/SPEC.md b/SPEC.md
index 451ded5..276565b 100644
--- a/SPEC.md
+++ b/SPEC.md
@@ -36,7 +36,7 @@ The supported target environment is deliberately narrow:
 
 ## 3. Non-goals and platform limits
 
-- Parley cannot guarantee insertion into literally every application. Password fields, lock/login screens, games, custom-rendered controls, unsupported XWayland clients, and applications without input-method support may reject insertion.
+- Parley cannot guarantee insertion into literally every application. Lock/login screens, games, custom-rendered controls, unsupported XWayland clients, and applications without input-method support may reject insertion.
 - Parley will not bypass the lock screen or cross user/session boundaries.
 - Continuous live captioning and partial streaming text are not required for v1.
 - Flatpak packaging is not a v1 requirement. A Flatpak would require a separate portal-oriented audio and filesystem design.
@@ -256,8 +256,6 @@ The critical assumption is that the engine must be active for the focused input
 
 The persistent mode is preferred only if it does not interfere with typing, shortcuts, compose behavior, keyboard layouts, or other input methods. Temporary activation is acceptable only if switching and focus are reliable. If neither is robust, IBus will not be the default.
 
-When IBus exposes input purpose/content type, Parley must refuse automatic insertion into password and PIN fields and retain the result on the clipboard.
-
 ### 7.2 Safe fallback: clipboard only
 
 Copy the transcript and notify the user to press Ctrl+V. This requires one user action but does not synthesize input and should always remain available.
@@ -276,7 +274,7 @@ Requirements:
 - recreate the session when required; and
 - fall back to clipboard-only on any failure.
 
-This avoids root/uinput configuration and is preferred over `ydotool` for synthetic paste. It still has focus races, depends on the target accepting Ctrl+V, and cannot insert arbitrary Unicode directly—it pastes clipboard contents. Portal-based synthetic paste cannot reliably identify every sensitive field, so it must not claim universal password-field detection.
+This avoids root/uinput configuration and is preferred over `ydotool` for synthetic paste. It still has focus races, depends on the target accepting Ctrl+V, and cannot insert arbitrary Unicode directly—it pastes clipboard contents.
 
 ### 7.4 Last resort: `ydotool`
 
@@ -359,8 +357,6 @@ Secrets and portal restore tokens must not be exposed over D-Bus or written to l
 - Temporary audio is deleted after transcription, cancellation, or error unless a future diagnostic option explicitly retains it.
 - The recording state must always be visibly indicated.
 - Do not log transcript contents by default.
-- Refuse IBus auto-insertion into known password/PIN purposes.
-- Never promise detection of all sensitive fields, especially with synthetic paste backends.
 - Portal control is opt-in and revocable.
 - `ydotool` support is opt-in and documents its elevated input capability.
 - D-Bus methods are available only on the user's session bus; no system-wide service is needed.
@@ -405,7 +401,6 @@ Test both against:
 - VS Code or another Electron application;
 - a Qt application;
 - representative XWayland applications;
-- password/PIN fields; and
 - multiple keyboard layouts if available.
 
 For IBus passthrough, explicitly test ordinary typing, modifiers, application shortcuts, compose/dead keys, layout switching, and interaction with any real IM engines. For temporary activation, test caret/focus retention and engine restoration.
@@ -427,7 +422,6 @@ Exit criterion: all daemon states and failures are represented without blocking
 
 - Turn successful prototypes into selectable backends.
 - Implement deterministic fallback behavior.
-- Add sensitive-field protections where information is available.
 - Ensure every failed insertion leaves text saved and copied.
 
 ### Phase 6 — UX, performance, and packaging