Public use cased based thread model of Qubes OS?

[J. Eppler]

Hello,

I watched the Logan CIJ Symposium talk with the title: Future of OS.

One of the journalists did not understand much of the talk and asked a simple question of how to select the right operating for him. The talk was about Qubes OS, Subgraph and Tails.

Link to the talk: https://youtu.be/Nol8kKoB-co

I think the journalist was in the talk, because he was aware of the privacy problem which comes from mass surveillance, but was still confused about all the solutions he could possible use.

I think Qubes OS should document their thread model in the Qubes OS documentation for technical and academic people. In addition to that pick some of the general threads from the thread model and create a user stories around them in a way that it helps a journalist, architect or general user to understand the strength of Qubes OS.

Here is some kind of example:
Paul works for an company. He has to travel a lot. He want's to communicate with his partner after his work.

Threads:
- Laptop can be stolen
- Mass surveillance -> private communication

Qubes OS solutions:
- Full disk encryption
- Separate qube (VM) to communicate with his partner
  - Using Whonix + something

I don't know if this is a good example. However the idea of those use cases is to model "general" users which are specific enough to show what Qubes OS can offer for different user groups.

I think such use case stories could demonstrate the power of Qubes OS and communicate the goals of Qubes OS to people like the journalist mentioned at the beginning.

What do you think about using user stories to communicate and demonstrate the power Qubes OS?

Best regards
  J. Eppler

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Do you think of something like this?
https://github.com/QubesOS/qubes-issues/issues/1906

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXPQmtAAoJENuP0xzK19cs3PEH/R8eIz3Ku5J9VdKJVx5GgJHg
OHrwUVIzmnwS7WO1/SHAxQQn8faJuvWv2piucFasXnn1sZ12bNAmb74zSOpy0kHa
c2nHR8OJ1QNHGypTkQ4iKSwDnqaSPh0N0A164KflWLs9XFdqrUQCSftkgf9HACC0
hedASViHssxaNNFPW6BCkUNSBCdbdYa4FmNHEQ4pe84SdRxurzInkb/aS4jkk0De
tI0lf30i7vumqb4hcrUnL0XPsqKF6NKM1b4ljnIa4NL22FDQAuWC8dkVtLvI5AHj
MEXNBErbFwL/c4GXHVspqZWV31Cy+uL6B6q0/zXQwsm7QgVHyOGobfPZieKZ6z8=
=i15y
-----END PGP SIGNATURE-----

[Franz]

The use of stories is a classic marketing tool, in particular is the second instrument of the presentation.

In the first one you promise something that may interest your prospects enough to get their attention and keep them reading or hearing. Example: an operative system that keeps you safe even if your Internet provider totally lost an hacker attack.

The subsequent one is a story, as you suggested, which guides the prospect to feel the emotions that you want to communicate. In our case the emotion can certainly be the fear of suffering concrete consequences of an attack and perhaps also the shame of being guilty for exposing secrets of clients, friends or a family member. This story is usually large, detailed, but still interesting.

The emotions are the real trick with the power to convince our fellow humans. But now comes the third part, the rational part. How can the prospect be sure that Qubes is not another presumptuous attempt to do better than Apple, the largest company of the stock exchange, with thousands of engineers. Perhaps Qubes has 10 developers, how can 10 win over thousands? This is the rational part. We know it is so, but it is not so easy to transmit this knowledge to a prospect that was convinced by our emotion pitch, but cannot trust only emotion, and want to be convinced rationally too.

Here for example it is possible to state that Qubes was build considering that network had already fallen in the hands of an attacker and this is not the case of Apple, Microsoft, Linux.

Now the prospect is supposed to be convinced, but there may be some Qubes competitors that do exactly the same.  So now comes the fourth instrument that is what is specific of Qubes that nobody else has and what advantages for the prospect does it include.

After all that we are closing our offer asking the prospect to do some action: download Qubes, or buy a computer with preinstalled Qubes, or make a contract with Qubes developers to do something together with Qubes, or whatever.

All the above is not an opinion, it is a science, which was built over many many years, spending millions and millions of dollars to do mailings and testing them with controls over and over again. So what works and what does not is pretty clear.

Best

Fran  

 

Best regards
  J. Eppler

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fa611f20-9529-464b-ba65-1108c2fb3368%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[J. Eppler]

Hello Marek,

Do you think of something like this?
https://github.com/QubesOS/qubes-issues/issues/1906

yes, pretty much, but I would pay more attention to the normal user section and split, that up into different professions and normal user needs. The term normal user is a little bit to general.

I would also try to cover most of the high and medium risks of the Qubes OS thread model, which are relevant to the user.

[Chris Laprise]

> --

I think your suggestion of documentation for technical and academic
audiences is also interesting.

My own belief is that software projects tend to lose their way more
easily if they don't explicitly document the use cases they are
ostensibly trying to satisfy. The Qubes project should go through a
phase of use case identification to create a small database of core use
cases (for example, "Use a networked application after waking laptop
from sleep" and even "Shutdown system"). People can then refer to these
written or UML-graphed use cases when writing code or discussing the
characteristics of a new feature that may impact those use cases.

It could save effort as well, given that technical discussions here and
on github/issues repeatedly put people in the position of writing use
case descriptions... except those use cases remain buried and won't be
viewed as relevant when searches are done for new/related issues.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks, everyone. This discussion will be very helpful when working on
#1906 (as Marek linked above). I've added a link to this thread there
so that we don't lose track of it.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXPXOxAAoJENtN07w5UDAwQw0QAJ+9WKjD+9AHXkmDuJ6tU51V
OtfTRVv7qnBbJmh9mEPH9eyCnKg5XW4Z8udGxS0uxmEl0Yl9s4z9+/X27i2y+GeJ
dEOzeAQbolLLBGZZrjo55V+QKJen7SYniDuGcHPpP/nV7iudrxwFXqxz7rz20xW5
8/Bm1dMMKxMcaiSr0psrpvDzmFwXXTwwR+H7MBKVMovBwbR4iX5TeeRnMDW48sIh
saG4cW+0557iiZELYlHtR0L3I2E3L0tmwYmXv114Y0xllGJzauZ1t5nTnJSXuXx2
gmIZFWjbjHuF08oniTNBM4MvNZ/3BYQor8RY9QXwfEnCx61VBtqUsQYU9hqmC7ve
IjGgx9epjQS4+nDpKrMcTCLZ8Q+HFRjemwbXUBu4yefKSy4dtQ45gRT/bYDLed4o
VZHUkgYq/NKa2GffpOhZfueb7lEtMd6OgBUvjt7uLaFLci4F6wpgP4MBxXJeBHhA
s+eabvL6X1K3Khc5u2tFLjOPWcdPRpMXf+MKHJZoC/yErtXRdGfSqJuuf9B6J93B
CCG+sROhr1vVZTeuod2HNETIWBh8Jzk0WqnPYMT2Ihh3t+Ho748YEX7PPJPH33Ty
QQSb6i3XoE4P0Nm4rf1dmte0wlA/4c25I2Gb/onVklqXc7M4TxJftoN9ZDt/sZ8E
BlztdmC6Qz3a4pSlzdZ+
=N5j/
-----END PGP SIGNATURE-----