|
Size: 8586
Comment: Typo
|
← Revision 12 as of 2016-05-20 08:07:42 ⇥
Size: 9445
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Concept of EasyGpg | = Building a Vision for GnuPG |
| Line 3: | Line 3: |
| This page tries to summarize the ideas of the EasyGPG Concept and its relation to the existing technology, namely Kleopatra. Wherever needed, the different sections individually address both aspects. | As part of the [[EasyGpg2016]]-contract we try to build a vision for the future user experience of GnuPG. This includes archetype users, some user stories and aspects how to evolve the existing //certificate manager gui// towards this vision. This page started with results from a day-long meeting on the 20th of April at Intevation, Osnabrück. Participants were Andre Heinecke, Bernhard Reiter, Björn Balazs, Emanuel Schütze and Jochen Saalfeld. Feedback appreciated, see contact points for EasyGpg2016. <<TableOfContents(3)>> |
| Line 7: | Line 15: |
| === easyGPG With easyGPG communication partners will typically exchange their emails and files confidentially. To achieve this, the effort needed for the user will be minimal and numerous security levels and compatible applications will be supported. |
=== Future GnuPG With future ~GnuPG communication partners will typically exchange their emails and files confidentially. To achieve this, the effort needed for the user will be minimal and a number of security levels and compatible applications will be supported. |
| Line 11: | Line 20: |
| * communication partners: all people even without any previous knowledge on crypto. See section archetypes for more details. | * communication partners: All people even without any previous knowledge on crypto. See section archetypes for more details. |
| Line 15: | Line 24: |
| * compatible applications: A variety of applications can only be reached by providing open standards and free software. * To make this vision become reality, we want to introduce a standard to define a handshake of the client about to send an email with the mail-provider that will return the public key of the recipient. |
* compatible applications: Support by a larger variety of applications can only be reached by providing open standards and a Free Software implementation. * To make this vision become reality, we want to introduce a handshake of the client with the mail-provider of the recipient, that will return the public key for encryption. |
| Line 18: | Line 27: |
| === Kleopatra Kleopatra will be a crypto manager providing all the power features advanced users need to manage their confidential communication. Users with lower demands will not need to enter to the full application, instead Kleopatra will provide contextual dialogues for the main applications (Mail, File Manager) to either allow to encrypt files or emails and to gather the information needed to configure private communication. |
=== GUI / Kleopatra Kleopatra (as example of an UI server and GUI) will be a crypto manager providing all the power features advanced users need to manage their confidential communication. Users with lower demands will not need to enter the full application, instead Kleopatra will provide contextual dialogues for the main applications (Mail, File Manager) to either allow crypto operations on files or emails or to gather the information needed to configure private communication. |
| Line 26: | Line 39: |
| | Tecnolgogie & Crypto for me are | Black Box | something I deeply understand | 1 | 3 | 6 | 2 | 10 | | | Technology & crypto for me are | a black box | something I deeply understand | 1 | 3 | 6 | 2 | 10 | |
| Line 34: | Line 47: |
| | Number of existing crypto keys | | | 0 | 0 | 1 | 0 | 3 | | | Number of (pre-)existing crypto keys | | | 0 | 0 | 1 | 0 | 3 | |
| Line 36: | Line 49: |
| | User of easyGPG (E) or Kleopatra (K) | | | E | E | **E**+K | E | **K**+E | | | | | | | | | | | | | | | | | | | |
| How am I accessing the crypto functions | contextually out of other apps only | starting crypto gui first | 1 | 3 | 6 | 3 | 9| |
| Line 42: | Line 54: |
| Following some typical tasks of the users are described and how the interaction with easyGPG resp. Kleopatra will look like: | Following some typical tasks of the users are described and how the interaction with future ~GnuPG will look like |
| Line 44: | Line 56: |
| === T1: Sending Mail to one reciepient | === T1: Sending Mail to one recipient |
| Line 58: | Line 70: |
| ## Automatically the public key for that address is being retrieved. A little indicator represents the security estimation of that communication process (smart integration of Tofu, WoT, individual certificate verifications,...). She could click here in order to gain more information about this state and what to do in order to improve the secrity estimation. | ## Automatically the public key for that address is being retrieved. A little indicator represents the security estimation of that communication process (smart integration of Tofu, WoT, individual certificate verifications,...). She could click here in order to gain more information about this state and what to do in order to improve the security estimation. |
| Line 67: | Line 79: |
| **Description: John wants to communicate safely with a potential whisle blower.** | **Description: John wants to communicate safely with a potential whistle blower.** |
| Line 79: | Line 91: |
| ## The system now searches for a public key, finds non and indicates this directly on the TO. field | ## The system now searches for a public key, finds none and indicates this directly on the TO: field |
| Line 84: | Line 96: |
| ### Webpage with instruction to communicate via some other form (Telefon, Jabber, ...) ### White list this recipient as someone to not communicate ecrypted to |
### Webpage with instruction to communicate via some other form (Telephone, Jabber, ...) ### White list this recipient as someone to not communicate encrypted to |
| Line 93: | Line 105: |
| * The standard behaviour when trying to send to someone without key has to be defined. For Erna e.g. it will be sufficient to send anyway, without asking | * The standard behaviour when trying to send to someone without cert has to be defined. For Erna e.g. it will be sufficient to send anyway, without asking |
| Line 96: | Line 108: |
| === T3: Create a new mail account after having recieved crypto instructions: **Description: Ernst want to leak and discuss a memo with John.** |
=== T3: Create a new mail account after having received crypto instructions: **Description: Ernst wants to leak and discuss a memo with John.** |
| Line 104: | Line 116: |
| * To be secure nothing gets back to him, Ernst has bought a new computer. * He has access to the internet and just applied for a free email account. |
* So he cannot that easily be tracked, Ernst has bought a new computer. * He has access to the Internet and just applied for a gratis email account. |
| Line 112: | Line 124: |
| # He get instructions how to backup his key and gets asked to upload his key so others can communicate safely with him. | # (Maybe) he gets instructions how to backup his key and gets asked to upload his key so others can communicate safely with him. |
| Line 116: | Line 128: |
| * It seems to be reasonable to make the set-up process even slicker. Neither passwords nor uploading or backuping the key has to be done in this step. It might be a good idea to simply prompt the user with these tasks after having used crypto a couple of times. This advantage would be to even lower the barrier to start with crypto. | * It seems to be reasonable to make the set-up process even slicker. Neither passwords or a backup of key has to be done in this step. It might be a good idea to simply prompt the user with these tasks after having used crypto a couple of times. This advantage would be to even lower the barrier to start with crypto. |
| Line 126: | Line 138: |
| * She has found some manuals, pointing her to install GPG4Win | * She has found some manuals, pointing her to install Gpg4win |
| Line 129: | Line 141: |
| # She download GPG4Win and start the normal installation # During the installation the system shows her the new actions she can do with GPG4Win installed, namely file-actions and email actions. # After successful installation of GPG4Win she can |
# She download Gpg4win and start the normal installation # During the installation the system shows her the new actions she can do with Gpg4win installed, namely file-actions and email actions. # After successful installation of Gpg4win she can |
| Line 139: | Line 151: |
| * When she stops the configuration before key creation, the corresponding dialouges will be prompted once she initiates an action that requires some input from her (e.g. she wants to sign something) * There should not be any need to start Kleopatra itsself. All configuration should be done via external dialogues (compare T3) |
* When she stops the configuration before key creation, the corresponding dialogues will be prompted once she initiates an action that requires some input from her (e.g. she wants to sign something) * There should not be any need to start Kleopatra itself. All configuration should be done via external dialogues (compare T3) |
| Line 142: | Line 155: |
| === T5: Configuration of an additional device **Description: John buys a new smartphone and wants access emails in parallel to his laptop.** |
|
| Line 143: | Line 158: |
| === Some corner cases === | User: * This task does applies to all users, but is not equally important. Maybe Ernst or Erna can just initiate a completely new installation and can disregard old settings, devices or data. Comments: * Technically all devices need to have access to the same private key. TODO === Some corner cases |
Building a Vision for GnuPG
As part of the EasyGpg2016-contract we try to build a vision for the future user experience of GnuPG. This includes archetype users, some user stories and aspects how to evolve the existing certificate manager gui towards this vision.
This page started with results from a day-long meeting on the 20th of April at Intevation, Osnabrück. Participants were Andre Heinecke, Bernhard Reiter, Björn Balazs, Emanuel Schütze and Jochen Saalfeld.
Feedback appreciated, see contact points for EasyGpg2016.
Vision
Future GnuPG
With future GnuPG communication partners will typically exchange their emails and files confidentially. To achieve this, the effort needed for the user will be minimal and a number of security levels and compatible applications will be supported.
Comments:
- communication partners: All people even without any previous knowledge on crypto. See section archetypes for more details.
- typically: We are aware that we will not be able to reach 100% of the communication events and security demand varies between different users.
- confidentially: Means end-to-end encryption.
- minimal effort: We are aware that there will always be a small additional hurdle. We try to make it as small as possible to foster frequent use.
- compatible applications: Support by a larger variety of applications can only be reached by providing open standards and a Free Software implementation.
- To make this vision become reality, we want to introduce a handshake of the client with the mail-provider of the recipient, that will return the public key for encryption.
GUI / Kleopatra
Kleopatra (as example of an UI server and GUI) will be a crypto manager providing all the power features advanced users need to manage their confidential communication. Users with lower demands will not need to enter the full application, instead Kleopatra will provide contextual dialogues for the main applications (Mail, File Manager) to either allow crypto operations on files or emails or to gather the information needed to configure private communication.
Users
Trying to formalize the users of a project is always a difficult task. We have decided to go with what we call archetypes for now:
| Quality | 1 vs. | 10 on scale | Grandma Erna | Journalist John | Student Annika | Civil Servant Ernst | Nerd Bob |
|---|---|---|---|---|---|---|---|
| Technology & crypto for me are | a black box | something I deeply understand | 1 | 3 | 6 | 2 | 10 |
| I use technology | rarely | frequently | 1 | 7 | 5 | 4 | 10 |
| My attitude towards protection of my communication | "I do not have anything to hide" | "Communication always has to be private" | 1 | 7 | 4 | 7 | 10 |
| Context of crypto use | Privat (P) | Business (B) | P | B+P | P | B | B+P |
| Number of devices | 1 | 4 | 3 | 2 | 6 | ||
| Number of identities | 1 | 2 | 2 | 1 | 4 | ||
| Platforms: Desktop (D), Web (W), Mobile (M), Tablet (T) | T | D + M, W, T | D, M, W, T | D | D, M, W, T | ||
| Motivation | Laggard | Early Adopter | 1 | 5 | 7 | 3 | 10 |
| Number of (pre-)existing crypto keys | 0 | 0 | 1 | 0 | 3 | ||
| Access to IT-Support | no | 24/7 | 1 | 3 | 4 | 10 | 8 |
| How am I accessing the crypto functions | contextually out of other apps only | starting crypto gui first | 1 | 3 | 6 | 3 | 9 |
Tasks of the Users
Following some typical tasks of the users are described and how the interaction with future GnuPG will look like
T1: Sending Mail to one recipient
Description: Annika wants to tell her University that she is sick.
User:
- This task does apply to all users
Comments:
- University provides a look-up service for public keys
- Communicating about Sickness is a sensible topic and hence the communication about it needs to be encrypted.
Workflow:
- Annika starts email client on her desktop
- Annika selects her university identity to send mail with
- Annika put her professors email address into the TO: field.
- Automatically the public key for that address is being retrieved. A little indicator represents the security estimation of that communication process (smart integration of Tofu, WoT, individual certificate verifications,...). She could click here in order to gain more information about this state and what to do in order to improve the security estimation.
- She writes and sends her mail as usual.
Remarks:
- This process in its ideal form does not require any more steps than sending usual, not-encrypted email.
- Users should be able to configure the behaviour if it is not possible to send an encrypted mail (e.g. send anyway, ask, wait for some time before being able to send)
T2: Communicating with a non-crypto user
Description: John wants to communicate safely with a potential whistle blower.
User:
- This task does also apply to all other users.
Comments:
- We assume the new contact has no key-pair yet.
Workflow:
- John starts his email client on his desktop
- John chooses the right identity to send with
- John enters the email-address in the TO: field
- The system now searches for a public key, finds none and indicates this directly on the TO: field
- John now enters the rest of the mail and presses "Send"
- The system feedbacks to him, that it is not able to send encrypted (because John has defined this in the settings), why this is so and offers the following:
- Inform the communication partner how to set-up encryption:
- Send a mail with instructions
- Webpage with instruction to communicate via some other form (Telephone, Jabber, ...)
- White list this recipient as someone to not communicate encrypted to
- Define what to do with this mail:
- Send not encrypted
- Save
- Send as soon as a key is discovered
- Discard the current mail
- Inform the communication partner how to set-up encryption:
Remarks:
- The standard behaviour when trying to send to someone without cert has to be defined. For Erna e.g. it will be sufficient to send anyway, without asking
- The white list of non-encryption partners needs to be configured. Ideally, the system searches for keys to the partners anyhow and asks to remove them from the white list, when a public key is being found.
T3: Create a new mail account after having received crypto instructions:
Description: Ernst wants to leak and discuss a memo with John.
User:
- This task does also apply to all other users.
Comments:
- Ernst got an URL from John about how to setup crypto.
- So he cannot that easily be tracked, Ernst has bought a new computer.
- He has access to the Internet and just applied for a gratis email account.
Workflow:
- Following the instructions he now installs Thunderbird and Enigmail.
- He starts and follows the normal setup to access his new mail account
- After the "normal" mail setup, the dialogue asks him whether he wants to import his keys or create a new key.
- He chooses new key, as he has none. The keys get generated and he gets asked to choose a password to protect his key.
- (Maybe) he gets instructions how to backup his key and gets asked to upload his key so others can communicate safely with him.
- He is now ready to communicate with John.
Remarks:
- It seems to be reasonable to make the set-up process even slicker. Neither passwords or a backup of key has to be done in this step. It might be a good idea to simply prompt the user with these tasks after having used crypto a couple of times. This advantage would be to even lower the barrier to start with crypto.
T4: Installation of GPG4Win / Kleopatra
Description: Annika wants to install software to encrypt her communication.
User:
- This task does also apply to all other users.
Comments:
- She has found some manuals, pointing her to install Gpg4win
Workflow:
- She download Gpg4win and start the normal installation
- During the installation the system shows her the new actions she can do with Gpg4win installed, namely file-actions and email actions.
- After successful installation of Gpg4win she can
- Quit the application
- Watch a video (?) that explains the main terms of encryption to her
- After watching the video she is asked to create or import her own keys (see T3)
- Import her keys.
- Last option would be to start Kleopatra.
Remarks:
- When she stops the configuration before key creation, the corresponding dialogues will be prompted once she initiates an action that requires some input from her (e.g. she wants to sign something)
- There should not be any need to start Kleopatra itself. All configuration should be done via external dialogues (compare T3)
T5: Configuration of an additional device
Description: John buys a new smartphone and wants access emails in parallel to his laptop.
User:
- This task does applies to all users, but is not equally important. Maybe Ernst or Erna can just initiate a completely new installation and can disregard old settings, devices or data.
Comments:
- Technically all devices need to have access to the same private key.
Some corner cases
- What should happen if not all recipients possess keys / the same kind of keys?
- Don't send
- Only send the encrypted mails
- Send all unencrypted
- Send different mails encrypted and unencrypted
- How to solve when more than one certificate is being found?