Encrypted Email for Planet Earth
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 85 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/38068 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
5
6
11
12
13
14
16
17
23
24
25
27
29
30
31
32
35
39
41
42
43
44
45
46
47
49
50
51
52
55
56
58
59
60
63
65
66
67
69
72
73
74
76
79
81
82
84
00:00
Chaos (cosmogony)Information and communications technologyEmailEncryptionEmailEncryptionConnectivity (graph theory)Slide ruleMoment (mathematics)MomentumInternetworkingComputer animation
00:44
Message passingEncryptionMoving averageUsabilityInternetworkingQuicksortAngleMessage passingDifferent (Kate Ryan album)Meeting/Interview
01:36
EncryptionState of matterGoodness of fitBeta functionEmailProjective planeData managementEncryptionPixelQuicksortMessage passingInternetworkingProduct (business)Information securityLecture/ConferenceComputer animation
02:33
CryptographyEncryptionAuthenticationPhysical systemRSA (algorithm)Revision controlInternetworkingInformation securityCryptographyInternetworkingSoftware developerRight angleCore dumpPublic-key cryptographyCommunications protocolQuicksortRule of inferenceLecture/Conference
03:29
File Transfer ProtocolTelnetTransport Layer SecuritySmith chartCryptographyPower (physics)Computational physicsQuantumNP-hardCommunications protocolCryptographyCommunications protocolForm (programming)MIDINP-hardMoore's lawAverageFinite-state machineInformation securityGoodness of fitMeeting/InterviewLecture/ConferenceComputer animation
04:26
Computational physicsPower (physics)QuantumNP-hardCommunications protocolProcess (computing)Finite-state machineAlgorithmCommunications protocolCryptographyStandard deviationInformation securityElliptic curveRSA (algorithm)QuicksortLecture/ConferenceComputer animation
05:11
NP-hardAlgorithmNeuroinformatikCore dumpCompilation albumQuantumCommunications protocolState of matterQuantum computerFinite-state machineInformation securitySource codeClient (computing)QuicksortVirtual machineComplex (psychology)Open setLecture/ConferenceMeeting/InterviewProgram flowchart
05:58
Information privacyCommunications protocolInternetworkingIdentifiabilityInformation privacyStack (abstract data type)Communications protocolPoint (geometry)EmailInformation securityControl flowQuicksortOnline chatRight angleMehrplatzsystemNumberComputer animationLecture/Conference
06:45
BlogCryptographyKey (cryptography)WeightRight angleInformation securityStandard deviationCore dumpArchaeological field surveyQuicksortDifferent (Kate Ryan album)Communications protocolCryptographyGoodness of fitWorld Wide Web ConsortiumWeb 2.0EmailScripting languageGroup actionComputer animationLecture/Conference
07:42
CryptographyKey (cryptography)WeightImage resolutionWeb 2.0MassInformation securityCommunications protocolGoodness of fitInformation privacyPhysical lawEmailBitBit rateSinc functionComputer animationLecture/Conference
08:25
Message passingEndliche ModelltheorieTelecommunicationExecution unitMetadata
09:08
Data managementKey (cryptography)EmailSoftwareMetadataLeakSign (mathematics)Information privacyOpen setParticle systemCommunications protocolPublic-key cryptographyWordCore dumpFamilyNP-hardComputer animation
10:14
ImplementationEmailStandard deviationMathematical analysisImplementationEmailProcess (computing)Row (database)Projective planeLecture/ConferenceComputer animation
10:56
EmailTelecommunicationData managementProjective planeEmailMessage passingData managementClient (computing)Key (cryptography)Meeting/Interview
12:09
Communications protocolEmailData managementKey (cryptography)SoftwareFamilyLinearizationGraph coloringComputing platformMeeting/Interview
12:52
Physical systemKey (cryptography)Computer programmingSingle-precision floating-point formatEmailAsynchronous communicationCommunications protocolProjective planeCryptographyGroup actionSign (mathematics)Latent heatComputing platformSemiconductor memoryLoop (music)FamilyWater vaporTelecommunicationCASE <Informatik>
14:14
Read-only memoryNormal (geometry)Volume (thermodynamics)EmailMereologyProjective planeProcess (computing)Client (computing)AuthenticationKey (cryptography)Forcing (mathematics)Internet service providerDifferent (Kate Ryan album)JSONXMLUML
14:57
Information and communications technologyDivision (mathematics)Key (cryptography)Price indexPublic key certificateInternet service providerProjective planeRight angleDifferent (Kate Ryan album)Forcing (mathematics)Information securityMeeting/Interview
15:44
UsabilityOpen sourceCommunications protocolSingle-precision floating-point formatFamilyKey (cryptography)Information securityUsabilityXMLProgram flowchart
16:44
Information securitySpacetimeHacker (term)Self-organizationMultiplication signDigital mediaDigitizingSoftware developerOpen setProjective planeNumberInternetworkingOnline helpEncryptionMeeting/InterviewJSONXML
17:47
Open sourceSpacetimeInformation securityHookingNumberField (computer science)QuicksortDecision theorySoftware developerProjective planeCASE <Informatik>Different (Kate Ryan album)BitGoodness of fitPerfect groupRight angleXML
18:42
Service (economics)NumberField (computer science)Expert systemMathematicsPhase transitionExterior algebraInterface (computing)Computer fileRight angleInheritance (object-oriented programming)Graphical user interfaceConfiguration spaceComputer clusterContent (media)Entire functionWhiteboardXML
19:27
Parameter (computer programming)Service (economics)Level (video gaming)Configuration spaceHydraulic jumpMoment (mathematics)Computer fileWeb browserServer (computing)Expert systemMultiplication signMenu (computing)AverageQuicksortLine (geometry)Set (mathematics)Level (video gaming)Process (computing)Information securityField (computer science)Chemical equationNumberWave packetMathematicsSimilarity (geometry)Computer animation
20:37
QuicksortBasis <Mathematik>EncryptionBitCryptographyWave packetSoftware developerEntire functionComputer animation
21:35
Session Initiation ProtocolWordTouchscreenMultiplication signComputer configurationPoint (geometry)WritingField (computer science)Software developerPermanentGroup actionSet (mathematics)Contrast (vision)Online helpBuildingVirtual machineOrder (biology)Mobile appLecture/ConferenceXMLProgram flowchart
22:40
Information securityIdeal (ethics)NumberEndliche ModelltheorieInformation securityIdeal (ethics)UsabilityPublic key certificateVirtuelles privates NetzwerkComputer programmingRight angleKey (cryptography)Keyboard shortcutCognitionPasswordType theorySpacetimeXMLProgram flowchartLecture/Conference
23:41
Term (mathematics)Multiplication signInformation privacySet (mathematics)Forcing (mathematics)Metric systemMenu (computing)Field (computer science)InternetworkingProjective planeOpen setMobile appData storage deviceQuicksortEvent horizonMedical imagingMaxima and minimaNumberMeeting/InterviewLecture/Conference
24:47
Mobile appWordContrast (vision)Line (geometry)NumberLecture/Conference
25:34
Mathematical optimizationBlogEndliche ModelltheorieProjective planeBitSet (mathematics)InformationFacebookMetric systemInformation privacyInterface (computing)QuicksortUsabilityComputer animationXML
26:33
Interface (computing)Incidence algebraEmailProjective planeSoftware developerVapor barrierLecture/Conference
27:24
Software developerSoftware bugNumberQuicksortSpacetimeVector potentialInterface (computing)UsabilityGoodness of fitProjective plane
28:08
Electronic mailing listEmailFeedbackTouchscreenSoftware developerMeasurementMultiplication signQuicksortGroup actionSoftwareSet (mathematics)FacebookEncryptionKeyboard shortcutRevision controlOnline helpMobile WebLecture/ConferenceJSONXML
29:54
BitSoftware developerNumberEmailOpen sourceCountingCodeAveragePoint (geometry)Interface (computing)Pattern languageField (computer science)Real numberOnline helpStandard deviationMedical imagingLecture/ConferenceMeeting/Interview
30:43
QuicksortSoftware testingAddress spaceBitNumberSession Initiation ProtocolPattern languageInterface (computing)Android (robot)System callLine (geometry)Keyboard shortcutRegular graphMereologyMoving averageLecture/ConferenceMeeting/Interview
31:29
Standard deviationInterface (computing)SpacetimeGraph coloringInterface (computing)Greatest elementLink (knot theory)Uniform resource locatorRight angleCountingStandard deviationKeyboard shortcutSoftware design patternOnline helpOrder (biology)Computer animationLecture/Conference
32:20
Interrupt <Informatik>NeuroinformatikMoving averageCuboidEncryptionState observerInterrupt <Informatik>BitCore dumpKey (cryptography)Computer animation
33:04
Software developerSoftware testingVideoconferencingBitRight angleFocus (optics)Group actionMeeting/Interview
33:50
Focus (optics)Group actionTraffic reportingRight angleMultiplication sign
34:36
Sampling (music)Right angleInformation privacyNeuroinformatikSelf-organizationDigitizingRow (database)Absolute valueCASE <Informatik>Computer animationLecture/Conference
35:26
Software testingInternetworkingDigital signalWebsiteInformation privacyFamilyCuboidProjective planeIntegrated development environmentWebsiteSound effectSoftwareRange (statistics)Computer animation
36:21
InformationEmailNumberFamilyElectronic mailing listMoment (mathematics)CodeComputer animationMeeting/Interview
37:25
Digital signalInternetworkingSoftware testingComputer iconIdeal (ethics)Web pageRight angleOpen sourceDigitizingSoftware testingPrototypeBuildingOnline helpEmailMobile appInterface (computing)Metric systemBitMenu (computing)CryptographyWhiteboardProjective planeSet (mathematics)ResultantComputer animation
38:55
Open sourceFreewareBitSoftwareMassInformation securityInformation and communications technologyTelecommunicationXMLLecture/Conference
39:44
SoftwareQuicksortProgrammer (hardware)BuildingXMLMeeting/Interview
40:31
Information privacyInformation securityProgrammer (hardware)Information and communications technologySoftware developerSoftwareGroup actionInternet service providerBuildingSpectrum (functional analysis)Freeware
41:15
Archaeological field surveySet (mathematics)BuildingMachine visionInternet der DingeProcess (computing)UsabilityProduct (business)QuicksortFitness functionSoftware developer
42:00
User interfaceArchaeological field surveyTerm (mathematics)Moving averageHacker (term)NeuroinformatikTerm (mathematics)Software developerCodeSoftwareXMLUML
42:55
Hacker (term)Hacker (term)Figurate numberSet (mathematics)SoftwareSource codeNormal (geometry)Sign (mathematics)Point (geometry)Web pageState of matterInformation securityInformation and communications technologyXMLUMLMeeting/Interview
43:53
Hill differential equationWeb pageSoftwareInformation securityVideoconferencingCuboidRevision controlExistenceYouTubeExterior algebra10 (number)Meeting/Interview
44:36
SoftwareGame theoryMultiplication signInformation securityWordComputer programmingInformation and communications technologyLoop (music)Cycle (graph theory)Product (business)Meeting/InterviewDiagram
45:29
Software testingSoftwareSoftware testingLoginInterface (computing)Set (mathematics)Revision controlSpacetimeFacebookLevel (video gaming)Game theoryComputing platformInformation and communications technologyMereologyDiagram
46:33
Structural equation modelingSoftwareGame theoryInformation securityPoint (geometry)Communications protocolPattern recognitionTelecommunicationEmailMetric systemCopyright infringementQuicksortBasis <Mathematik>Sign (mathematics)Computer programmingWebsiteMessage passingLecture/ConferenceProgram flowchartJSONXMLUML
47:45
Hacker (term)Level (video gaming)MassProjective planeSign (mathematics)Lattice (order)NumberKey (cryptography)Cartesian coordinate systemDifferent (Kate Ryan album)Uniform resource locatorInformation security
48:30
Exterior algebraDataflowQuicksortSoftwareNormal (geometry)Open sourceSource codeLine (geometry)PlanningLecture/ConferenceMeeting/InterviewComputer animation
49:33
UsabilityLattice (order)Product (business)QuicksortEncryptionAbsolute valueTotal S.A.Set (mathematics)Different (Kate Ryan album)Self-organizationSoftware testingClient (computing)EmailTerm (mathematics)Meeting/Interview
50:41
Shape (magazine)Process (computing)System callQuicksortSoftwareSelf-organizationGroup actionUsabilityStandard deviationRight angle
51:33
MereologyAddress spaceEmailMetropolitan area networkForm (programming)TelecommunicationInformation and communications technologyFacebookQuicksortStandard deviationTwitterPoint (geometry)TrajectoryGodObservational studyMultiplicationChaos (cosmogony)NeuroinformatikCentralizer and normalizerGoogolLecture/Conference
53:34
Object (grammar)QuicksortEmailTwitterMoment of inertiaPoint (geometry)Slide ruleMultiplication sign
54:24
Cartesian closed categoryEncryptionMessage passingInterface (computing)Service-oriented architectureProjective planeOpen sourceComputer animation
55:30
Digital mediaProjective planeOpen sourceRoundness (object)Meeting/InterviewJSONComputer animation
Transcript: English(auto-generated)
00:15
So, we finally fixed everything. Have fun with the talk. Encrypted email from planet Earth with Harry, Mesquite, Gus and Rebel.
00:24
Give them a warm hand of applause. So the moment you've all been waiting for, the ugliest slide of your entire camp. The ugly slide is about an ugly reality, which is 25 years after the deployment of OpenPGP on the internet.
00:55
We don't have virtually any messages encrypted end-to-end.
01:02
And this is a massive failure of our community. And basically this talk is going to try to understand how such a large failure happened and what's the sort of different angles about how we can fix it. So I'm going to cover the history of how we got to this somewhat fucked up place.
01:26
Mesquite is going to cover the technical aspects. Gus Andrews from Simply Secure is going to cover the usability aspects. And Evan Hinshaw Plath will cover the growth aspects.
01:41
And effectively, we don't want to say that it's been a total failure. Since the Snowden revelations, there are so many great projects. I hope some of you are in the room. The only thing that works today is Enigma and GPG. But we also have the Leap Encryption Access Project trying to simplify key management.
02:04
We have MailPile, which is now at a good state of beta. We have Pixelated. We have the experimental Pond. And of course, the most usable, although post-email, is Signal and TechSecure. So we have a lot of good end-to-end products, but I think the
02:22
real question we're facing is why wasn't all these messages encrypted end-to-end by default? And people sort of say that the internet was broken by design. Actually, it's a sort of artifact of history, right? So if you just look at the dates, the fact of the matter is public key crypto sort of
02:41
rolled out right after and was under research and development when the core protocols of the internet were under development. So you have TCPIP published 1973, public key crypto by Diffie-Hellman in 1976, RSA shortly thereafter, SMTP shortly thereafter, and OpenPGP more than a decade after.
03:03
And of course, it is possible, and Vint Cerf in this quote sort of leans to this possibility, that there were attempts by the NSA and other folks working on sort of end-to-end crypto. Of course, the NSA had something like Diffie-Hellman before Diffie put it in public, before the internet sort of hit the public.
03:26
But the fact of the matter is regardless, what we've had to do is basically we've had to bolt on the crypto after we've already had massive deployment. And a lot of people are trying to do this now post-Snowden, but the fact of the matter is we've done it before.
03:43
As you can see, virtually every major protocol had some form of crypto kind of slapped on it in a roughshod manner often after it was more fully developed in the mid-90s. But the problem, which we're now suffering from, is that designing protocols is hard.
04:06
And the fact of the matter is in the mid-90s, we really didn't know how to design protocols very well. The assumptions, of course, that people made around the amount of computational power that would be in the hands of average people or government agencies was vastly underrated.
04:25
We didn't have any good notions of provable security. We didn't have any notions of state machines when we were building protocols. Algorithm agility has been, of course, a mixed bag at best. While we do have, it essentially allows a lot of downgrade attacks, and we have a lot of legacy algorithms, RSA 1.15, whatnot, still in the wild.
04:48
And right now, the standards community is in the process of trying to upgrade all these algorithms. We're trying to get off of RSA into elliptic curve crypto. I'm sure you've all seen Daniel Bernstein's great talk on that.
05:02
But the fact of the matter is we still need some algorithm agility because 10 to 15, maybe 20 years, 20 years being sort of, we don't really know what the fuck we're talking about, but 10 years being a clear and present danger. We do, of course, have quantum computation coming up, so we have to start even thinking about getting post-quantum algorithms into our core protocols.
05:24
But it doesn't matter what algorithms you put into your core protocols if your actual state machine and your actual ability to prove the security of your protocol is flawed from the beginning. So this, of course, is the triple handshake attack on TLS client authentication, and you can
05:43
sort of see it's a sort of miracle that TLS worked as well as it did. But when you really get down to it, when you bolt this crypto on after the protocols are released in the wild, you, of course, will open yourselves by sheer virtue of complexity to all sorts of attacks. And while we at this point in the 21st century understand how to develop cryptographic
06:07
protocols, what we don't understand, what we do at all, is designing privacy-preserving protocols. So typically, if you look at the older protocol stacks in the internet, we were just sort of throwing identifiers around willy-nilly, and we're seeing more and more breaks in this.
06:23
And even in new pieces of software, for example, you know, TechSecure has probably the best post-email sort of protocols. We're revealing, for example, people's phone numbers in multi-user chats. And the fact of the matter is all the move towards post-email, the thing that all
06:44
the insecure protocols got right is that they were decentralized, that you could actually run your own. And they were run through a standards body, and we had some core agreement on them. Right now, of course, in the post-email world, where we actually have some chances of getting a lot of the end-to-end security right, decentralization is not being taken account
07:02
of, so you're basically in end-to-end secure silos where you can't communicate with each other. So what I'd like to ask for people to do before we go on to the actual sort of hardcore problems, if you're interested in these, we really need you to get involved, because the community, to be honest, has sort of fucked this one up. Everyone's producing their own protocols, people aren't cooperating properly, we'll go into this in much more
07:23
detail, but effectively, there are some places where you can really make a difference and standardize things. Modern crypto is where most of the good post-email discussions are happening. If you're interested in actually getting PGP working, the IETF OpenPGP working group, chaired by the wonderful DKG, has finally reopened the IETF. The W3C is trying to look at how we could actually make JavaScript not such a nightmare in the web security IG.
07:46
And of course, there's a huge policy debate, and you can sort of say that this is just solutionism, that we're trying to solve mass surveillance by just throwing out protocols which are secure and encrypted and privacy-preserving. But, you know, if you want to try to solve the laws on this, good fucking luck.
08:05
So next, Mescio. Can I get, ah, okay, great. So let's get back a bit about, to talk about email. As he says, it's been already almost 25 years since PGP was invented, and still no one does it.
08:26
Sure, probably in this room almost everybody uses it, but we are a tiny minority of the world, and most of the communication of messaging is actually unencrypted. We won the crypto wars. It looks like we already got really far with crypto, but at the end, we didn't reach how to make it available to everybody.
08:50
Many people are saying that there is many problems on OpenPGP. I completely agree. Like, we have huge metadata leakage. We are learning from Snowden that metadata actually matters a lot.
09:04
So, as Dennis says, we kill based on metadata. So, for example, we have this thing that we call the Wolf Trust that to certify keys, we sign the keys of each other, and it leaks a lot on our network of friends or contacts.
09:23
We have Heathers on emails as an SMTP that actually puts all the emails in clear, all the metadata. We have many other problems, like for war secrecy, now it looks like it's really important that we have protocols that preserve your privacy in the future, and it looks like OpenPGP is not doing it.
09:48
We have many problems with key management, like people is not understanding how to use keys, and it's actually a hardcore mental problem to understand how this public and private key works and how to sign them.
10:08
Learning keywords, everybody is saying that email is a screw, that we cannot fix it. I do agree, email is a screw, but I'm still
10:20
concerned how much is actually all these problems that I show, problems of OpenPGP, or not just the implementations that we have right now on email. So, I love, sorry for my voice, I love all these projects that are coming out, like Pwned, Whisper Systems, or, yeah, can I have some water? Sorry.
10:59
So, sure, I love all these projects that are trying to reinvent messaging, it's amazing that the people
11:07
are experimenting with that, we need it, but the reality is that the people right now use this email. And if we come out with another email solution, we will have another more in the
11:22
stack, and it's going to be a hard problem to get actually mass adoption of it. So, I think we can still improve email, probably we cannot fix it, but there is a lot of effort right now on many projects trying to improve it, and it might be worth it.
11:45
I want to mention some of the problems that I think are there, and how I think they can be improved, like key management, Gus will mention more things on that, I think there is many problems on key management that are actually usability problems on the clients.
12:11
So, actually, we are used to implement critical software in a way that we expose the users to all the tiny details of the critical.
12:23
So, for me, actually, most of the problems that we have with key management in email are actually usability problems. We have some availability that all these problems are actually common to all the messaging platforms, I think, and availability to have many devices connected to the same thing.
12:46
Most of the new protocols are having problems to solve the issue, and emails, we have problems, how do we deal with keys to have actually several devices that have them, that want to access our email, or how do we rescue or email if we lose the device.
13:09
Asynchronous communication is a basic thing on messaging, and forward secrecy and asynchronous communication have many issues to deal with together, and it's a fairly hard problem to solve.
13:24
As Maria said, even Whisper System has some issues with that. Group communication, like public Cryptoc, is actually meant for one-to-one communication.
13:42
All the crypto protocols that we have are meant for one-to-one, and it's really hard to find a solution to make protocols that actually work well in groups. So it's true that we have many issues that are really hard. I don't think that this is specific of email. I think they are
14:04
general for messaging platforms, and many projects are working on trying to improve that. There's a really interesting project called MemoryHole that is working on hiding headers on emails and signing
14:21
headers, so basically moving parts of the headers to the body of the emails when you sign them. There's the URL there. I don't think you can see it, but anyway. Google for MemoryHole is in the process of trying to standardize, and the nice thing of the project is that
14:44
it's joining the force of many different clients, like Milepile or Anymail or Leap are working together on this project. There is Conix. Conix is a research project on trying to get the authentication of keys done by certifying keys from providers.
15:11
By having a proper, very favorable way of checking that the providers are not giving certifications of keys for different people, and I think this
15:28
is going to be probably an interesting future on how to simplify the user experience, on how to get the right keys for certain people. And there are many people implementing secure email, like Leap, where I work, or Milepile, that Milepile
15:51
exposed you to crypto, but they're thinking a lot on how to make it really easy to use.
16:01
WhiteOut is also there doing really nice things. They do a plug-in for the brochure, and they have interesting protocols on how to synchronize keys between multiple devices. And yeah, I think I can pass the voice to Gus, who will talk about UX.
16:23
Okay. I want to thank you all for coming. I'm becoming increasingly clear there are many things to do at CCC, so it's very exciting to have so many people in the room. I'm Gus Andrews. I am currently the secure usability, or sorry, a security, secure usability senior fellow at Simply Secure.
16:45
But I should say, whoop, hello? No, no, no, no. How are we doing this? Down or space? There we go. Okay, one at a time. That's good. Okay. So I should say I am not speaking for Simply Secure. I wear many hats, one of which is an organizer at HOPE, Hackers on Planet Earth, one of which is the producer of a digital literacy show called the Media Show.
17:06
So here I'm mostly speaking from my experience working with a number of tool developers in this field, and that also included my earlier work at OpenITP, the Open Internet Tools Project. Also, I should say, I'm from Southern California, and I tend to talk really fast, so if you see me talking really
17:20
fast, say, slow down. Just give me the little slow down. I will try to do what I can. Try to not speed. So I'm assuming that many of you are in the room because you want to help people encrypt. How many people here want to help other people encrypt? Yes, of course. How many people here would actually like to build or work on an encryption tool? Fewer. That's okay. That's good, though. It's nice to see some people in the room. Don't.
17:44
What I really want to say here is don't make a brand new tool. One of the things that we have too much of in this space and in open source tools for security is too many tiny, tiny teams with people working one by one. Don't be a cowboy. We don't really need more of that in this space. Find existing projects, hook up with them.
18:04
Also, a bit of a caveat, if you happen to be here, you probably have figured this out by now. If you're here because you want to encrypt your stuff, this is probably not the talk for it. You may want to go find a different talk or a hands-on workshop just in case there's anybody still hanging out going, what's going on here? I want to say after sort of talking with a number of tool builders in this field and working with
18:21
them for a while, it seems like there are a number of tradeoffs that developers have to make decisions about. And these impact how usable these tools are. Frequently what we see, and I hate this phrase because I'm a perfectionist, but we see that the perfect ends up being the enemy of the good. So you end up striving for perfection and then sort of not ending up with something good. And these are the tradeoffs that sort of do that.
18:44
There are a number of tools in the field that are struggling with whether they should support experts who already know how to encrypt or whether they should support newcomers. I'm not going to call out the names of most of the tools that I'm talking about here except if they're doing super awesome things. This is an interface from a tool which had been saying, we're going to provide an alternative to Dropbox within the next year.
19:07
And this is the interface they're offering people. They're not working on a graphic interface beyond this right now. So you'll notice that this actually requires the user to go into a config file, highlight a word, and change it. So that means they need to know what to change it to and they need to not accidentally paste in the entire
19:22
contents of the book of Kells or whatever they have in their clipboard into this accidentally and screw the entire config file up. That's an awful lot to ask, frankly, because generally what you want to do is err on the side of not letting users make too many mistakes. Not only does this config file contain much of what they need to do, but they
19:43
also demand that the user jump between this config file and a web browser at undefined moments. So a lot of people find this super counterintuitive. So this would be more supportive to experts who want to go in and say, oh, you know, I want to change how long it is until timeout or how many different servers I'm sharing these files with.
20:03
The average user isn't going to need that. The better solution here for making it usable for everybody is to hide a lot of the settings deep in a menu someplace. They can still be there. Just don't make this the number one thing that people have to interact with. Similarly, along similar lines, we are sort of struggling in this field to strike a balance between educating people and just making it bloody work for a change.
20:24
So there are a number of really great training curricula in this field. Tactical tech is here. Go find their security in a box thing. It's great. The EFF has security self-defense. Level Up has been doing a really great job with training us how to train other people.
20:42
And they are pretty great. Crypto parties also. I'm a little bit concerned that crypto parties are sort of using... I don't know that we have a demonstration that they encourage people to use encryption in an ongoing way. So I'm sort of looking to see them improve their methods, spread their methods to other people.
21:02
Any of this education is up against the thing that people use on a regular basis. For many people, it's the iPhone. There has one button and you poke it. That's all that happens. In this day and age, most users are not usually used to going to an entire training course to learn how a piece of technology works. So we're asking people to make a massive trade-off. We're asking them to learn a great deal to use these tools.
21:25
And that, once again, makes it less likely that those tools will be adopted. One thing that developers can do here is consider using graphics to explain things rather than just doing a whole lot of writing out text.
21:40
One of the developers in our field said, when I was talking to them at one point, More options is never the answer. Every single word we add to the screen is a new chance to overwhelm and confuse the user. That's every single word. We're not talking about every button. Every time you feel like you need to write something out, every word can conceivably confuse people.
22:01
Writing and editing matter, and that's not something that necessarily everybody is thinking about. Education also, the more you have to train people, the harder it's going to be for them to adopt things for permanent. Once again, there are certain tools that are airing on this easier side than others. Cryptocat, like when I had a journalist come to me the other day saying, help me encrypt my shits.
22:22
I took him straight to Cryptocat first just to make sure that we had a secure channel that probably nobody would be looking at. And so we went there. By contrast, here's another app that shall go unnamed that is asking, This is the wizard that every user, I believe, has to go through in order to set up a subconnection on this. And that is really, really complicated.
22:42
Ideal security versus ease of use. Many of us are planning for attacks that people may not ever, like James Mickens said, you have a couple of threat models. Either you're facing Mossad or you're not facing Mossad. So yes, there's some stuff in between, but you're either facing a really, really serious actor, or there's much more simple things you can do to fix things.
23:02
One of the programs in our space was like, oh, we're really worried about the attack, where the attacker can look at the phone and see where you pressed the keys and look at the where on those. So they scrambled the keyboard. The sheer amount of cognitive work it takes a person just to type in a simple thing like a password, which is already very confusing for them, is significantly harder,
23:21
and it's more likely for them to give up when they see a keyboard that's been scrambled like this. I've also had people ask me, oh, let's make sure that the users can see the certificates for a VPN. And when I did an interview with a bunch of VPN users and then also people who ran VPNs, even the people who ran VPNs said, I never look at the certificates on my VPN.
23:41
It's just good to know that they're there. So a lot of the times, users are just not where we are in terms of thinking about how complicated an attack is. Once again, putting settings further down in the menu can help make that easier. Gathering metrics versus protecting privacy is another huge tradeoff in our field. My first day working at the Open Internet Tools project, I was like, okay,
24:01
let's find out what users are actually doing and where they're having problems, so let's look at some metrics. And I was told, no, you'll never have metrics. You may not have them. It is not safe for our users. You'll never protect their privacy that way. But then as I got to know tools more and learned what they were doing, I learned that like ChatSecure in the images that you see here,
24:21
if they're in an app store, if they're in the Google app store, if they're in the Apple app store, there is some data being collected. You can see here that I've got the data from Turkey, Ukraine, and Belarus, and I was trying to match this data to figure out whether particular events were spurring downloading and installing of this.
24:41
You notice that in Turkey, you're looking at the blue, which is sort of in the background behind the orange. It does look like the protests in Turkey actually saw an uptick in the number of people downloading ChatSecure. By contrast, the protests in Ukraine, which is the middle line there, no perceivable impact as far as I can tell. There's just been steady growth in use in the Ukraine. And I included Belarus there to say, yeah, they're collecting this data,
25:02
and we actually kind of learned some things. I think it would be interesting to go in and go, why Turkey? Why did Turkey pick up these apps and Ukraine didn't? But you also notice that the numbers are so small in Belarus that it is still possible that you could disambiguate and find out who a particular user was, and that might be conceivably an issue. But it's worth also talking to users about how they think about these things, too.
25:24
I had some users that I was talking to, I'm trying to remember whether they were journalists or activists or who they were, but they said, oh, we thought you were gathering data to find out how the tool was working. So we're actually surprised that you're not doing it. And then we heard also Second Muse, who we'll talk a little bit more about later,
25:42
did this wonderful project researching with bloggers and journalists in Vietnam who are faced with jail for speaking out against the regime there. And the journalist said to them, yeah, we give Facebook all of our correct information about who we are and where we are because why wouldn't we? Aren't we supposed to trust Facebook?
26:01
We're working with Facebook. They need this from us, right? So talk to users before you make assumptions about what their privacy concerns are. I think we need to ask a little bit more and think about what we could be collecting. And Evan will talk a little bit more about metrics later on. So looking at these tools, what are the things associated with projects that are tools that are more usable?
26:20
Do they have big teams? Not necessarily. I had one team, I was giving them sort of like you should be fixing this with your usability, you should be fixing that with your interface. And they said, but we're not Google, you're not being fair. And I said, well, no, actually I was comparing you to MailPile. Like MailPile is a team of three people. Shout out to MailPile, I can see you in the room.
26:41
MailPile is a team of three people and their interface looked very new and up to date. And I actually had people confuse it with Google. So it was nice and clean and simple to use. So it's not about how big your team is, how many people you're working with, but it's where you choose to allocate your efforts. The team that was whining about not being Google had 11 people on their team.
27:02
They've been around for 10, 11 years, and yet they're still not creating a usable interface because they don't have anybody who's dedicated. They haven't found somebody, they haven't prioritized giving their resources to a person who is actually going to build a better interface. That's what really matters. If you have somebody who has a dedicated UX person, you tend to see a more usable interface.
27:20
That said, still having a team of one to two people is not optimal. I had another team say to me, we are only going to have two developers working on this project because if we had any more than that, when you add more developers, the number of bugs goes up exponentially, and I'm not sure I buy that because their tool is just still not usable, and I think they're still having trouble stomping all their bugs.
27:43
This is sort of the most important thing, and I think Evan's going to talk about this as well. Good projects, usable projects, observe their users and they listen to their users. They do it early and they do it often. What you're seeing here is StoryMaker, which is sort of a tool peripheral to this space,
28:01
has printed out all of their interfaces, and they've invited a bunch of potential users in to put a bunch of post-it notes up and go, why don't you just put these two on the same screen, or this looks confusing to me, or what if we had a button for this? That's one way to begin to get feedback from users, which is pretty low impact. People don't necessarily have to say who they are when they're putting these things up there.
28:25
It's very easy for people to actually comment on what's actually going on. There's a lot of tools out there. You can ask me for more of them for doing this as well. Don't use mailing lists. I don't even know why. When some developers, when they're saying, yes, we listen to users,
28:42
they say, oh, yeah, we have a mailing list. You're asking people to constantly be in their mailbox all the time, frequently with also your developers there or your more technical users. You're going to have your developer in there who is constantly yammering about how he wants to take this build and make it work on his Raspberry Pi
29:02
with his custom brew hackety version of your software. Don't listen to that guy. That guy is going to overwhelm your mailing list and drown out all the people who have very quiet concerns that they aren't necessarily even sure they can speak up about. Things that they think are their faults. I was talking with some trainers earlier, and we were sort of saying, a lot of the time, users think things are their fault, so they're not even going to speak up.
29:22
And if the discourse is all about perfect forward secrecy, people are going to start to drop out, and you're never going to hear from them. Going back to the idea of talking to your users, only a quarter of the developers I talk to actually say they talk to users before they start developing their software.
29:42
How do you know what people actually need? Maybe people don't actually need encryption. Maybe they need more help with their Facebook settings. Maybe they need some way to protect their mobile device better. Maybe they don't actually need to encrypt their email. You need to listen before you develop a tool. And then also, still, once again, only a quarter of developers
30:01
actually talk to users afterwards, too. So this is something that our open source developers really need to improve on, talking with a number of people. I'll talk more about how to do that in a bit. Other people working on your codebase don't count as users. Don't count those. Also, don't only hear from people on GitHub, because once again, you're pre-selecting for people who are highly technical, and you're not going to find the real pain points for average users.
30:25
Thank you. Thank you. Thank you. Also, yes, I appreciate that. So, yeah, another thing we don't see enough of in this field is reliance on standard patterns. I went looking for this one particular tool that, once again, will not be named. I'm not sure why this is the interface.
30:42
The image of the background is the interface. I'm not sure why it's so stretched out and weird-looking, but these sort of weird swoopy bits, the fact that it's asked for number or address at the top, this is a SIP client, once again. When you ask for number or address, it gets very confusing. I was doing user tests on voice tools last year, and a number of these tools were leading, because they also supported regular phone calls,
31:02
were leading people down calling on a POTS line, a plain old telephone number, and those calls would be insecure. But because you give people a phone keyboard, they're going to click those, and then they're going to make an insecure call. So people are introducing things into their interfaces that are actually causing people to be insecure. Don't roll your own interface.
31:21
There are patterns out there from OS X, from Android, probably from Google as well, that will say, when you're designing, please do this, use these colors, give this much space to such and such a thing. Those are free. You don't have to pay for them. Go out and find them. There's one URL from there, and I think I've got more in the links for this talk as well.
31:44
The other thing about this interface that I was, oh, you can't quite see it there. You can see it on that one. There's a weird little orange button at the bottom. What do you think that button does? Anybody? Yes. Pulls up the keyboard, right? I don't think it did. It did something else entirely.
32:00
It was this weird little orange basketball button, and it did a totally counterintuitive thing. What you're looking for when you're using a standard design pattern is for somebody else to have made all the mistakes for you first, right, and then go and find out what they've already learned about how to not make interface mistakes. There's a lot of knowledge out there about interfaces. Okay, what else should you do in order to help people get encrypted?
32:22
What you should do is you should build a new tool and roll your own encryption. Have we learned nothing? Okay, don't do that. No, because you wouldn't build a... What? Yes, I know. Sorry. I'm just getting riled up. That's all. You wouldn't put this shit in a computer in a pizza box. So don't build your own. Don't build your own.
32:40
Go out and find people. First of all, other people who are developing tools, don't be a cowboy. Go find your own. Go find other people. Then go find users to speak to who are not like you. Observe them. I'll be talking a little bit more in a second about why observe is more important than ask questions,
33:01
but listen to them and don't interrupt. The key thing is to look for places where users get confused and or stop, and especially if you're the developer of the tool, the instinct is to go, Oh, no, no, no, no. What you should actually do is don't do that. I have put Mescio on the spot. I've looped him in on user tests for Bitmask earlier,
33:21
and he was utterly stoic about this. It was great. We put him on a video conference so he could see what the user was doing on the desktop, and I muted him so he couldn't actually speak up and go, Oh, no, no. And so he had to suffer through the users going, I just can't make this work. I can't. And it hurts and it sucks, but get used to it. It's just the way that this is going to go.
33:41
Right. When I say observe, people don't use focus groups. Focus groups are probably the reason, if you think the soft sciences are soft and creepy and squishy and weird, and it's just people's opinions and a bunch of stories, that's because you probably have thought about, like you've heard from people using focus groups, and focus groups have a very deep bias towards people responding to other people in the room
34:01
and doing what they think they should be doing or saying what they think they should be saying. So that's one tool to avoid. In general, what you learn when you do social science research is that self-report data is unreliable. When you're just asking people what they do, they will tell you what they think you want to hear. It is better whenever you can to observe them actually doing a thing,
34:21
and you find so many wonderful, amazing mistakes. You just ask people, why did you do that? And then they can clarify their understanding. For more about why you should use certain methods, I did a talk at Hope last year. I'm sorry, not 2014. Yes, last year was 2014. Time goes quickly. Right. But where, though? Where do I find these people I should talk to?
34:41
Librarians are your privacy allies. In the United States in particular, they are obligated to help protect their users from government mandates to go in and look at people's records. So they are interested in the things that we're interested in. Also, they work with their digital skills teachers. They work with populations of people who are interested in learning more about computers but don't know that much.
35:02
Non-governmental organizations, absolutely. Human rights organizations, LGBT organizations, absolutely go talk with them. They have people who want to learn about these things too, and they have easy cases to explain to them why. Formerly incarcerated people as well, people on welfare. Coffee houses. I know the Whisper Systems team just goes out to coffee houses and asks people,
35:22
and that is a very brave thing. Ten minutes, oh gosh, I'm super running late. Journalists also, totally our allies. Ask people, like if you've already interviewed one person or worked with one person, say to them, I'm sorry, go back. Oh, now we're totally gone. What happened? It knew I was going. There we go.
35:45
Don't ask your family and friends. There's this thing called biasing of network effects. You're going to end up hearing things. You're not going to hear from a range of people if you ask your family and friends. Watch what questions you ask. If you ask, how often do you encounter blocked websites? What you hear back, what you're expecting is that people know that things are being blocked.
36:01
So don't do that. Ask, do you think you're being blocked? Don't ask, do you encrypt? People may not know what that means. Ask, how do you protect your privacy? Don't ask, how do you face censorship if you're talking to people in China? Especially, I had somebody get up and walk across the room without even talking to me anymore. Yeah, he couldn't even be seen with somebody who was talking about censorship.
36:21
So, yeah, that's pro tip. Don't talk to people in China about censorship. Move from general questions to more specific questions. And this will work for you, I promise. This great anecdote that we have from a circumvention tech festival in Valencia is that a Nick Mail came in. They had only been hearing from people on their mailing list. Look at that mailing list and how dense
36:40
the amount of information is that they need the user to read and that you have to give to people. And he came in, and he was talking with a number of people who trained journalists and activists. And the people were coming up to him and saying, thank you so much. You've saved my friends. You've saved my family. Your tool is just central to what I'm using. And he came away saying, I have learned more in the past five days of talking to people
37:02
than I have in the past five years on our mailing list. He also said, and people were hugging me, and I felt really bad because they had all these serious problems. And yet I'm just this guy who codes things. And I felt really awkward, you said. And then he's like, but that was really good. I know I should feel really awkward. So it was this total come to Jesus moment. We promise you, if you talk to people, it will be great.
37:23
We've developed some personas. If you can't go talk to people, these are some idealized situations with particular kinds of people, LGBT activists, human rights activists, journalists in Vietnam. Check out this particular page. Those are open source, free to use.
37:40
Like I said, Second Muse has done some wonderful reviews of what the Tibetan exile community needs and what Vietnam's digital activists need. Check those out as well. To do list. I'm just going to go this really quick, and then I'll let Evan talk. Is that feedback, by the way, that I'm hearing? Whoosh. I think that's something else nearby. OK. Before you build tools, ask people what they need.
38:02
Don't build anything that they don't need. Test early with people. Test often. You may not have a working prototype to give them, but you can always print out your interface. You can even sketch out an interface and say, where do you think you would go if you were going to, in this interface, if you were going to encrypt, or make your email safe, right? Find other people to work with. If you have an idea for a project, don't work alone.
38:23
Go find designers to work with in particular. Dribbble, D-R-I triple B-L-E, and then also Modern Crypto Project are great places to go find designers who are interested in helping. Take settings. Put them in a menu. Trainers I hear from say that they want the help for a given app in the document, not on the web. Try using graphics to give instructions.
38:41
That's really helpful. Evan will talk a little bit more about metrics. And if you can't do user research yourself, come talk to Simply Secure. We actually have a mandate to help people who are working on tools in this space, and we'd love to help you out. Evan.
39:05
So we're now moving to Q&A. No, sorry. Yeah. So is the next video? Is that the one? Yeah. OK, so I want to, in the last five minutes, talk a little bit about why open source and free software
39:23
that we've been writing hasn't been getting mass adoption, in particular, secure communication software, and why people are using startups or corporations communication software, and why they're not using our stuff. And in particular, I want to encourage us to steal ideas and techniques
39:43
from the capitalists and the startup community, because they have ways of making software work that are needed. These are sort of startup techniques, and so some of these techniques may seem sketchy, and they certainly are different than the way community
40:01
developed software has been created, but I think they're the reason we're losing, because if you have two kinds of software that are being developed, and one is just going in, and you're thinking about what you should develop, and you only have programmers contributing, and you build it, and you have another kind of software which is concerned a lot with how it gets adopted and used,
40:24
even if that other software is not so good, they're going to be really good at getting people to use their stuff. And so we get people using Gmail, because it's really good at getting you to use it. And those techniques are things we can use.
40:41
As developers, when we want non-developers to use our software, we need to stop thinking about scratching our own itches. The ultimate free software is, you know, every developer out there, everyone will be a programmer, and we'll all just scratch our own itches, and we'll build stuff. And it's great for software aimed at other geeks and developers, but for privacy software,
41:02
for encrypted email, encrypted communications, we need a broad spectrum of society using it to provide security for everyone. And so we need to not be just providing tools that a small group of people can use. So we need to build things that people will use, we need to build things that people want to use,
41:21
build things that people love, and you do that not by having a great vision like Steve Jobs has of, oh, the light bulb appeared over his head, but you use a set of techniques and you use a set of experiments. And so I think even though you look at the sort of
41:40
lean startup customer development, you know, ideas of product market fit, and it sounds very alien to this community, but the idea of launching things quickly, getting feedback, learning and iterating based on use is something that needs to be done in this community. Rather than just saying, oh, well,
42:01
we know about these hard problems, we're gonna go off and spend a bunch of years developing. You know, Leap is doing really interesting work in terms of development, but they wrote down all their hard problems, and then they sat in front of their computers for a few years and worked on solving them. And hopefully they built the right things, but they really should have learned
42:22
whether or not they were going down the right path and everything else before they started writing code, not a couple years later. And the startup world, because it's dependent on money and people are running out of money, they're very focused on learning as quickly as possible.
42:41
And we need to be doing that. You know, there's a term called growth hacking, which is basically figuring out how to get people to use your software and how to get them to keep using your software. And the normal hacker community that's building all these tools
43:01
doesn't think about growth hacking. We launch the software, and it will be good, and we do some about pages, and then people will sign up and use our software because it's great. And that's not the way it works. Or more to the point, if you have one set of tools which are closed source and not secure, but they're really good at getting people to sign up,
43:22
and you have another set of tools which might be great technology, but don't figure out all the tricks to get people to sign up and stay using it, that software will never get adopted. Like, it doesn't matter if we solve the secure communications problem if we can't get people using it, if we can't have them discovering the software
43:42
or signing up for the software, using it, promoting it to friends, coming back and using it again. The security aspect of it almost doesn't matter if we can't grow the user base. We need to learn quickly. We need to figure out ways
44:01
in which when you're developing software, when we're launching this stuff, you learn within hours and not months. You know, when the startup world launches software, they don't write the software first. They launch the page that describes the software, and then they have the sign-up button. Dropbox, everyone's talking about
44:21
a secure alternative to Dropbox. The first version of Dropbox was a video that was put on YouTube. The software didn't exist. It didn't work. What he did was he put up a video of what he thought the software would be and got tens of thousands of people to sign up for it, and then everyone who signed up for it said,
44:40
join the beta program. Oh, sorry, the beta program is full. It didn't exist. He got the users. He sold the software first, and then he wrote it. And the secure communications community spends tons of time writing the software and never figures out how to get anyone to use it. So we need to learn how to learn quickly and not learn very slowly.
45:04
The game of getting software adopted is how to make it around this loop as quickly as possible, from ideas to building it to launching a product to measuring the data and then learning again. Now, if you take a year to do that cycle,
45:21
you're gonna lose to someone who is taking a day to do it. So we need to figure out how all of these tools can learn really quickly. We need to be testing everything. We need to be testing every aspect of our software. Every feature you write should be written in such a way that it's an A-B test
45:43
that you have a set of data and cohorts so that you know changing the login interface or making all the buttons purple made your software better or worse. Right now, we don't know whether or not everything we launch makes things better or worse. We don't know if we're improving things. We don't know if not releasing a new version
46:01
you'd get the same level uptake. You know, Facebook has no idea where they're taking their platform because each engineer just launches little experiments to small percentages of the user. They don't know where they're gonna do it. They don't know what to improve it. But they know they want you to keep using the site and keep that engagement. And so as long as they're playing the game
46:21
of let's do 10 million tests a day to see how to make our software more addictive and we outside that space aren't playing that game, we're not gonna make addictive software that people use as their primary communications medium. And so as long as we don't play the game of how do we make this software better in everything we do, how do we collect data on its use,
46:42
our software will get, you know, it might be great software, but it just won't get adopted. And making secure e-mail and secure communication protocols, it needs to get adopted. Otherwise, there's no point in doing it. The last thing I want to talk about is something that's very popular within the startup community.
47:01
It's something called pirate metrics. It's a very simple idea of how you acquire users. And it has, this is it simplified down, but basically it says for anyone using your software, you need to acquire the user, as in get them to go to your website.
47:21
You need to activate it, which means get them to sign up and create an account or download the software. You need to keep them there. You need to make money on them, because this is a startup world, so they're doing that. But we can change that, so you just need to keep people using the software on a real basis. And then you need them to refer other people.
47:42
And you can track the growth sort of metrics of programs by this. So every single project that you work on where you want mass adoption, you have to be tracking these numbers. You have to know what percentage of users go on to the next stage and what percentage of people refer to others,
48:02
because that's how you get viral growth. And we're not going to get that growth just at hacker meetings where we're signing each other's keys. It's a race that we face. It's a race between different applications. To get secure communications, we need to win that race. And right now, we're not going to win that race.
48:22
Right now, we have all these different projects very bravely and valiantly fighting out there, and we're not learning quickly. We're just sort of going with the flow. And as long as that happens, we won't build better software. People will still use the insecure alternatives.
48:41
So if we do this, if we think about it, there's lots of easy wins. There's lots of easy ways to get the software adopted more quickly. We just have to look beyond the normal open source community. I want to thank you.
49:03
Thanks a lot. So we have a few minutes for Q&A. If you have any questions, please line up in front of the microphones. If you decide to leave early, please do so quietly. Any questions? Hand signs?
49:20
Making their way there. There we go. Over there? The one with the blue shirt? Sorry. Hello? Please. Hi. I have a question actually about usability.
49:42
Is there going to be anything else going on that you're participating in with the camp to do more exercises around this and learn about usability? And then secondly, do you have any references around helping people who want to become more product people to learn this? Because it's a whole different skill set
50:03
than understanding the technology and the encryption and all of that stuff. Yes, totally. Absolutely. Thank you for asking. I will pitch that I am... Well, this is sort of more a one-on-one thing. I'm actually going to be going around hopefully user testing a couple of encrypted email clients. So if you want to come in on that,
50:21
I can both sort of show you how I do user testing and then also you can help me out with the testing. I can show you the rig that I use and things like that. In terms of resources, actually one of the things... Evan used to work at an organization called Neo, and some of the folks at Neo produced a book called Lean UX that I'm very fond of.
50:41
It does a lot of teaching, giving you the general shape of how to iterate quickly. I think that's the main thing. That's about interface-wise. We also released a book called Talking to Humans. Both of those books, the Lean UX book and the Talking to Humans books, are about how to do this process for developing software.
51:02
And I recommend that you read them. Yeah. I think there's also a book. What was the one? I recommend if people are interested in getting involved in this, Simply Secure has a Slack channel. If you mail me at gus at simplysecure.org, I can get you on there. And we will be talking about things there, and periodically people post resources there as well. We've got some really amazing people in there from IDEO,
51:23
from Nielsen Norman Group, from the gold standard groups in usability, and so it's just been a great discussion there. We highly recommend you join us there. Right. Thanks. Over to you. So, this is a race.
51:41
Don't you think that e-mail by itself will lose the race to other forms of communication and that we should focus our efforts to improve other forms of communications instead of plain old e-mail? I mean, I can address that. So, I'll try to address that really quickly,
52:04
which is it is very possible, and part of me really hopes that in four years I come back to the Chaos Computer Camp and everyone is using end-to-end, encrypted, post-e-mail, signal, or whatever.
52:23
Unfortunately, people keep using e-mail, and the reason people keep using e-mail is even though people are slowly being sucked into these silos, you know, Gmail, et cetera, et cetera, which are nonetheless e-mail, there seems to be something about the fact that you do have a baseline of interoperability.
52:41
Yes. I can e-mail you, of course, from Google to Yahoo, et cetera, et cetera, to Rise Up, and we do not have that interoperability right now in post-e-mail and whatever the fuck comes after e-mail, and until we get that, and I work for Standard's Body, and we'd love to have you all come to us and sort this out,
53:00
I highly doubt we're going to get post-e-mail. In fact, what we're likely going to get, rather than a decentralized, secure, end-to-end e-mail, is we're much more likely to get everyone on a terribly insecure Facebook messenger and pray to God that Moxie and Trevor fix WhatsApp and we'll basically be stuck in centralized post-e-mail silos.
53:23
That's the current trajectory. Because these silos are doing the techniques that Gus and Evan are talking about, and we're not, and this is a problem for me, at least. A couple more data points on trends here. One of them is the reason we are kind of stuck with e-mail is business. Business still works with e-mail in a lot of ways,
53:41
and I think that's going to be sort of a big and movable object. The other large object with a great deal of inertia is China, however, and the country of China, where e-mail is just not a thing. So it'll be interesting to see whether that has an influence, whether increasing business and growth in China somehow moves us away from e-mail in that way.
54:00
But do you really want a future where we're all using QQ? I mean, this is terrible. It's WeChat. People are using China these days. Okay, thanks. We've got time for two more questions, so over to you. Just a quick one. Apologies if we missed this at the start, but what's the best way to get in contact with you all? Oh, let me actually bring that slide back up.
54:28
I'm sorry, interfaces, they're just terrible, because I hadn't mentioned. It's not just us. Technology is broken. There we go. All right, so that is, yeah, that's Andrew's work.
54:44
So, you in the red t-shirt question? Yeah, just a short one. Basically, are you developing on any open source projects on your own?
55:01
No, no, no. Project of what, sorry? Didn't I say don't do that? Basically, you said you should talk to users before starting a project. I think basically that's missing the idea and motivation behind most open source projects.
55:24
I think most people started just because it is cool. We want to have it on our own. My cool project is talking to users for open source tools. Well, thank you. Thank you very much. Could you give our speakers another round of applause?
55:42
Thank you very much.