diff --git a/README.md b/README.md index 263dd8e..51bbd41 100644 --- a/README.md +++ b/README.md @@ -48,6 +48,7 @@ And its project motto keeps the same principle courteous: - [Wake-up point and roadmap](ROADMAP.md) - [First-session continuity notes](SESSION_NOTES.md) +- [Public trust user-research questions](USER_RESEARCH.md) - [Coarse-grained concept](CONCEPT.md) - [Architecture decisions](ARCHITECTURE.md) - [Certificate Investigator design](DESIGN.md) diff --git a/USER_RESEARCH.md b/USER_RESEARCH.md new file mode 100644 index 0000000..51a1bda --- /dev/null +++ b/USER_RESEARCH.md @@ -0,0 +1,150 @@ +# Public trust user research + +This guide is for conversations with non-specialists before Browsec commits to +a distributed-trust architecture. Its purpose is to discover what people would +benefit from, tolerate, distrust, and reject—not to persuade them that our +current idea is correct. + +Ask one question at a time. Let the participant describe concrete experiences +before introducing terminology such as certificate authority, consensus, +community trust, reputation, or distributed network. + +## Short conversational interview + +### Existing experience + +1. Have you ever opened a site and received a security or certificate warning? + What did you think was happening? +2. What did you do next, and why? +3. Have you ever wanted to use a site that your browser blocked even though you + believed it was legitimate? +4. Have you ever trusted a site because the browser showed no warning and later + regretted it? + +### What “trustworthy” means + +5. When you call an online service trustworthy, what do you mean? +6. Does trustworthiness change with the activity—for example reading news, + sending a private message, downloading software, or making a payment? +7. What information would help you decide whether to continue to a questionable + site? +8. Which matters more to you: knowing who operates the service, knowing that + other people have used it safely, or knowing that its technical identity has + not unexpectedly changed? + +### People and institutions + +9. Whose judgment about an online service would you consider useful? +10. Would you treat advice differently if it came from friends, technical + specialists, an organization you know, your employer, your government, or + strangers with a good history? +11. Should several independent sources be able to disagree visibly, or should + the browser combine them into one recommendation? +12. Would you ever allow a chosen person or group to make a security decision + automatically for you? In what situations? +13. Whom would you explicitly refuse to give that power? + +### Desired behaviour + +14. If the browser distrusts a service but people you chose consider it + legitimate, what should the browser do? +15. If the browser accepts a service but a community you trust reports danger, + what should happen? +16. Should the system merely provide evidence, recommend an action, block the + connection, or let you choose among those behaviours? +17. How much explanation would you want before continuing: a simple warning, a + short reason, or a detailed investigation? +18. Should an earlier decision apply once, for the current session, for a fixed + time, or until you revoke it? + +### Privacy and social cost + +19. Would you be comfortable if other participants could learn which services + your browser checks or visits? +20. Would you contribute observations about certificates or service behaviour + if the system protected your browsing history? What protection would you + expect? +21. Would public participation under a stable identity feel safer and more + accountable, or more invasive? +22. What information about you should never leave your device? +23. Would background network activity, battery use, or bandwidth use bother + you? How much control would you expect? + +### Abuse and failure + +24. What would make you suspect that a trust community had been manipulated or + captured? +25. What should happen when trusted participants disagree sharply? +26. How should the system respond if a once-reliable participant begins giving + harmful advice? +27. Should old recommendations expire automatically? How quickly? +28. What would be worse: occasionally blocking a legitimate service, or + occasionally allowing a harmful one? +29. What behaviour by this system would make you disable or uninstall it + immediately? + +### Governance and control + +30. Who should be able to create a trust community? +31. Who should decide its rules, membership, and removal process? +32. Should communities be able to split, merge, or recognize one another? +33. Should there always be a local setting that overrides every community and + institution? +34. Which emergency security announcements, if any, should be allowed to reach + everyone—and who should be permitted to issue them? + +### Closing + +35. What useful capability have these questions failed to mention? +36. What part of this idea sounds most valuable? +37. What part sounds most dangerous or unpleasant? +38. Would you personally try such a system? Why or why not? + +## Very short version + +Use these when there is time for only a brief conversation: + +1. What makes an online service trustworthy to you? +2. Have browser security warnings ever helped or frustrated you? +3. Whose security advice would you accept, and whose would you reject? +4. Should advice remain visible as disagreement or become one browser verdict? +5. What could such a system do that would make you want it? +6. What could it do that would make you uninstall it immediately? +7. What information about your browsing must never leave your device? +8. When should the system advise, ask, block, or act automatically? + +## Interviewer notes + +- Ask for examples: “Can you remember a time when that happened?” +- Do not correct technical misunderstandings during the discovery portion. + Misunderstandings reveal what the interface will need to explain. +- Avoid presenting “the community” as inherently benevolent or “the authority” + as inherently malicious. Both can fail or be captured. +- Distinguish what the participant **wants**, what they would merely **tolerate**, + and what they would **refuse**. +- Record the intended activity. Trust for reading a public page may differ from + trust for payment, identity documents, private communication, or executable + software. +- Ask whether a desired automatic action should be the default or an explicit + opt-in. +- Record exact phrases when possible; they may suggest better UI language than + our engineering vocabulary. +- Do not collect names, browsing histories, or sensitive incidents unless the + participant knowingly chooses to share them. + +## Synthesis questions for us + +After several interviews, classify responses without forcing consensus: + +- Which benefits recur across technically different participants? +- Which feared behaviours would be unacceptable even if technically useful? +- Which decisions do people want to retain personally? +- Which decisions are they willing to delegate, and to whom? +- Which activities require different trust standards? +- Where do people prefer visible disagreement over one combined score? +- What privacy cost are people unwilling to pay? +- Which terms were consistently misunderstood? +- Which requested benefits require distributed trust, and which could be solved + more safely by a local tool? +- What is the smallest system that produces a real user benefit? +