-
-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI mocks for masking paste input #1763
Conversation
Yeah, agree. I anticipate users mainly using this for passwords, so it's a familiar experience to passwords. |
I’ve encountered one obstacle with the “asterisk” technique, unfortunately: if we naively substitute all characters of the copy with asterisks, then the copy itself of course ends up only consisting of asterisks – so the original copy is lost. I don’t think it’s trivially possible to display asterisks in the text field while still preserving a shadow copy of the original text. (This is because the user cannot just type in new text, but they can also backspace, move the cursor, select and replace text, paste, etc.) I’ve researched and experimented with different approaches, and found one workaround that would look viable to me, albeit not as elegant as asterisks admittedly: Screen.Recording.2024-03-28.at.19.51.33.movThis basically uses a Alternatives would be to try to blur the text to make it unreadable, but I found that rather tricky, because (a) it looks quite weird and is hard to work with, and (b) it might only be pseudo-safe, since the degree to which blurred or pixelated text can be restored from e.g. a photo or screenshot is quite astonishing. If we are good with the proposed UI, I could break up this draft PR into separate ones. |
The redacted text looks fine, so I'm good with that. Is it an option to use |
I’m not sure, because we would lose multiline capabilities then. Unfortunately, neither does While I’d suspect that many people use the paste feature for passwords or other shorter snippets, we also put in some effort into supporting larger texts, for which multiline has better UX. |
Ah, in that case, I think the most recent Related: "CIA Realizes It's Been Using Black Highlighters All These Years" |
Related #1739. This PR optionally allows users to mask the input copy in the paste dialog, for privacy reasons. - We [explored and discussed some UI approaches initially](#1763), and the “redacted text” technique seemed like the best compromise between simplicity and effectiveness. It’s basically struck-through text with a stroke thickness that matches the line height. - I moved down the keyboard hint, to accommodate the toggle button above the dialog. To me, it would feel justified to style the text as [subsidiary](https://github.com/tiny-pilot/tinypilot/blob/22b3e8ec354861b948a09ac0c8a14bac1e0952a1/app/templates/styleguide.html#L76-L77) (i.e., with reduced font size and slightly diminished color). - After clicking the toggle button, we give focus to the text area, because it seems likely that the user wants that. https://github.com/tiny-pilot/tinypilot/assets/83721279/e66827cf-8858-4c82-8ec3-55ab9d87bca6 <a data-ca-tag href="https://codeapprove.com/pr/tiny-pilot/tinypilot/1764"><img src="https://codeapprove.com/external/github-tag-allbg.png" alt="Review on CodeApprove" /></a> --------- Co-authored-by: Jan Heuermann <jan@jotaen.net>
Related #1739.
This PR demonstrates a few potential approaches regarding the UI of masking paste input.
Note that this branch contains functional mock-ups, which don’t work 100% correctly yet. You can ignore the code completely for now. The
localhost
URLs below refer to this branch, which contains feature toggles that respond to thevariant
query param.[invisible] Making the text invisible
http://localhost:8000/?goto=paste-dialog&variant=invisible
Screen.Recording.2024-03-26.at.19.40.20.mov
[asterisk] Substituting with asterisks
http://localhost:8000/?goto=paste-dialog&variant=asterisk
Screen.Recording.2024-03-26.at.19.54.09.mov
[hidden] Hiding the text altogether
http://localhost:8000/?goto=paste-dialog&variant=hidden
Screen.Recording.2024-03-26.at.19.41.11.mov
Discussion
What I like about [asterisk] is that you have full feedback when you type in. This is also somewhat true for [invisible], because at least the cursor moves while you type, and you can verify your input by selecting all text. With [hidden], you don’t have any feedback at all (like with a password prompt on the terminal), which feels strange to me.
With [hidden], it’s impossible to tell whether the input box is empty or not. For [invisible], it’s possible but potentially cumbersome, since you have to select all text first. I think this might cause subtle yet annoying usability issues.
[hidden] and [invisible] allow for a maximum of security, because they don’t give away the info how long the input text is.
My personal preference is [asterisk] – I think it’s a good compromise between usability and security.
Thoughts, @mtlynch?