feat(android): add optional private comparison for secure input
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- android
- Lĩnh vực
- api, mobile, security, testing-qa
Hướng nghiên cứu
Bắt đầu với Android IME helper hiện có và tool contract dùng chung; kiểm tra cách capability discovery, input ownership và session cleanup hiện đang hoạt động. Tái hiện native EditText và diagnostic IME probe của API 36 bằng getExtractedText, sau đó xem xét các acceptance checks về bằng chứng đầy đủ, mới nhất và failure handling an toàn với secret. Hoàn tất khi các kết quả so sánh có giới hạn phân biệt được các kết quả khớp hợp lệ với các kết quả không khớp, trong khi các đường dẫn không chắc chắn hoặc không được hỗ trợ vẫn ở trạng thái unknown trên các nền tảng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Add optional native private input comparison for secure fields
Android secure fields can expose masked accessibility text even after a successful
fill. Preserving password, hint, selection and mask metadata improves evidence,
but metadata alone cannot prove the exact value was entered. The existing Android
IME helper commits and clears input; it does not currently provide private
readback/comparison evidence.
Reproduction and bounded evidence
A disposable API 36 emulator ran a native synthetic EditText fixture and a
diagnostic IME in separate application processes. After public agent-device fill
with synthetic 2468, the secure node reported password:true and accessibility
mask_only text of length 4. The IME's InputConnection extracted text reported
length 4 and equality true against that fixed synthetic expectation. Filling a
different same-length synthetic value, 1357, produced length 4 and equality false.
The observed extraction had startOffset 0 and partialStartOffset/partialEndOffset
-1. Retrieved text was compared in-process and never printed.
This establishes a narrow native feasibility result on that fixture and device.
It does not establish support for every app, WebView, custom editor, Android
version, or another platform.
The fixture uses EditText with TYPE_CLASS_NUMBER | TYPE_NUMBER_VARIATION_PASSWORD
and PasswordTransformationMethod.getInstance(). The separate diagnostic IME
calls getCurrentInputConnection().getExtractedText(request, 0) and compares
extracted.text to the fixed synthetic expectation in-process. This is a probe,
not the proposed production protocol: fragment equality alone cannot establish
complete, target-bound field equality.
Proposed capability
Add an optional private comparison operation through the existing Android IME
helper, returning a structured match, mismatch, or unknown result. Keep raw
field text inside the native helper. This should supplement fill evidence without
making accessibility masks an exact-value assertion.
The operation should require:
- A stable target binding: device/session, app package, editor field identity,
focused target, and input-connection generation. Bind the expectation and reply
to a fresh nonce; reject focus or generation changes during capture/comparison. - Fresh, complete value evidence after the action. Check extraction offsets and
partial-update markers, and prove completeness within bounded reads. A cursor
fragment, stale extraction, truncation, or unavailable completeness signal must
yield unknown, even if a returned fragment matches. - Bounded read sizes, request duration, and retries. Unsupported/refused/null
connections, unsupported editors, timeouts, and uncertain ownership return
explicit unknown/unsupported reasons rather than success or empty-value claims. - Explicit opt-in capability and permission gates for the helper/IME, with target
ownership checks. Preserve existing guards against typing into the IME itself.
Restore prior IME configuration when a session ends or fails. - Secret privacy throughout transport, logs, errors, traces, and artifacts. Do not
serialize raw retrieved values or expected secrets into evidence. Return only
the comparison result and minimal non-sensitive provenance needed to validate
freshness; do not expose lengths by default unless separately justified.
Expose this as a platform capability through the shared tool contract: callers
must be able to discover support and handle unknown consistently on Android, iOS,
and web. Do not imply an Android IME implementation automatically supplies iOS or
web parity. Unsupported platforms should retain truthful evidence limitations.
Acceptance checks
- Correct and wrong same-length synthetic inputs yield distinct comparison
outcomes on a genuinely masked native field. - Empty values, selection/cursor movement, focus switches, editor recreation,
stale sessions, partial extraction, truncation, and refusal cannot produce a
false match. - The helper remains a separate process and preserves existing input-owner gates.
- Automated log/trace/error inspection finds neither expected nor observed secret
values, including failure paths. - Unsupported editor/platform paths return unknown and cannot upgrade a
checkpoint to exact-value success.
This issue proposes a capability boundary and validation work, not a production
ready implementation or universal support claim. A metadata-only change remains
useful independently but does not close the exact-comparison gap.
- Ngôn ngữ chính
- TypeScript
- Star
- 4.7k
- Fork
- 304
- Merge trung bình
- 11 giờ 29 phút
- Pull request đã merge (30 ngày)
- 514
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
callstack/agent-device#2842 ·
-
docs(ios-runner): RUNNER_PROTOCOL.md points at the wrong file and omits recovery and busy codes Đang mởdocumentation good first issue ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
callstack/agent-device#2797 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
callstack/agent-device#2856 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
callstack/agent-device#2853 ·
Tất cả issue của callstack/agent-device
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
mksglu/context-mode#1200 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
jaegertracing/jaeger-ui#4506 ·
-
area:desktop area:ui bug platform:macos
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
anthropics/claude-code#96687 ·
-
good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
AOSSIE-Org/DebateAI#582 · 2 bình luận ·