Add public trust user research guide

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)

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?
+