Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1187 Thanks!
We have Krista here.
She's head of the
engine development at the PEP team.
So let's give a warm welcome
applause to Christa, please.
I mean, OK,
good afternoon, and I guess it is by one
minute or so.
So she said, my name is Krista Bennett.
I am the core engine developer
for the pet project.
How many of you actually know anything
about the pet project?
OK, if you've heard about it,
typically, the talks about pets have been
the sort of sales pitches we want to get
to people for the project, but I
am not a PR person.
So instead, this will be slightly more
technical. It's not super technical.
But what I was thinking I
really wanted to do was I
worked there for about two and a half
years now, and it's
kind of an ambitious project.
So pretty easy. Privacy, or Pep
aims to give encryption to the masses
and make it easy for everybody.
And we want to do that.
That causes us to have a number of design
calls that are really, really
challenging. And I was thinking about
myself 20 years ago when I started doing
software development and wanted to think
about some of the lessons I would tell
myself if I could go back in time
based upon what we've learned in doing
this project. So what I'm going to
do is I'm going to
explain a little bit about Pep.
It might be a little speed walkthrough of
Pep because again, I
think a lot of people have heard the
long form use Pep.
It's great and it's easy speech.
And then I want to talk a little bit
about our architecture because a lot of
architectural decisions have
brought up some really unexpected
challenges, at least for me
as a developer.
A large part of our software is
intended to be free because we
like free software. It's good, but
a lot of our users use proprietary
systems and we want to be able to reach
them because we want everybody to be able
to encrypt and be private.
So that compatibility actually
causes a lot of issues.
And then.
Email has been around for a long time,
and so you would really expect it to be
super standardized.
And it turns out it's really not.
So I want to talk a little bit about that
because that's that's been kind of
I wouldn't call it the fun challenge, but
it's been one of the more interesting
challenges for us to continuously deal
with and then kind of wrap it up with
some is what
we've all learned from all of this
working at. Perhaps so
I'll start this with what Pep supposed
to do. So Pep is
a secure, private messaging
solution.
Right now, it's just for email, but it's
basically intended to get everybody
encrypting all the time so that we can
beat mass surveillance.
Yay.
If there's one person encrypting,
you know, if I'm sending you some mail,
you and I encrypt to each other and
nobody else does it.
That stands out if everybody
is doing it. Nobody's interesting.
So if we can get people doing it by
default without thinking about it, then I
think we've won something.
And it also makes it a whole lot harder
to go, you know, search for the internet
for keywords.
And I know grandma calls you up
over the holidays or makes
you go up to her room and fix your
computer, but she doesn't really want
your tech support.
And so we'd like to give both you and
grandma a break and letting her have a
product that she can install and forget
about that still does the complicated
work of encrypting your email.
So this looks
like I downloaded it off of our Web page
because I did, but I'm
going to give you a short overview of the
protocols just so you can understand what
it's supposed to do and then we'll get
into the other stuff that I really wanted
to talk about.
So let's say Grandma has downloaded
Pap and she
wants to communicate with her grandson,
Bob.
And he also down to downloads our product
when they both download PIP to handle
their emails on
both sides. Keys are generated and they
don't have to think about it.
They don't do it on purpose.
They don't have to understand what a key
is.
Then the first time Bob Male's grandma,
he sends her an unencrypted mail because
he doesn't know he doesn't
intentionally encrypt anything.
He's just using the product to do that,
and it contains his public key.
Grandma gets the public key,
and she sees that there's
there's an email from a pap user and
the her pet product.
When she reads, the email goes, Aha, it's
a pet user.
I'm going to communicate my key back to
him when I reply, and I'll encrypt to
that key because it's there.
It's not a trusted key yet because we
haven't gone over any particular secure
channels to verify that these keys belong
to each other. But at least if even if
they just stop there, they would be
communicating with encryption.
And again, not worrying about it, not
intentionally encrypting.
But of course, we want to be able to
verify keys. How many of you verify all
the keys of all the people you encrypted?
And if anybody raises their hand, I'm
going to call you a liar?
Well, maybe one guy gave one guy.
We want people to be doing that
verification process, but we want to make
it easy because rooting out a super
long hash over the phone to somebody is
something that people just don't do.
And it's not that it's hard, but people
don't do it. We want to make it simpler
and we want to make it part of the
interface and part of the process.
So what we do is we've
mapped the fingerprint space
to trust words in various languages.
Those fingerprints.
This is a little bit wrong because we now
use a combination of the fingerprints to
generate the trust words.
But basically on each side, you say,
OK, I want to you push a button and says,
I want to, I want to verify grandma's
key. And so Bob and grandma
get up on the phone, and
once they want to verify each other's
keys, the words pop up and they read
the words to each other. And if they
match, hey, the keys
are the keys that they're intended to be,
they can verify trust with one another.
And now, from from now on,
they will be using a trusted key back and
forth to communicate with each other.
And the other thing we give them is a way
to tell whether or not that trust the key
is being used or if there's been a
compromise.
And we do that simply by putting a color
at the top of the message.
So initially, when they send this
unencrypted mail back and forth to each
other, that color is gray because we have
no trust information at all.
Once we're actually encrypting to one
another, we make it yellow
because we want people to know that those
messages are at least encrypted.
But again, there's no trust that's
been exchanged. So it's like warning.
Yeah, it's encrypted and stuff, but you
don't know that this is really bob.
It might be his evil younger sister who
you don't want to send mail to because
younger sisters are always evil.
Right?
I don't have one, so I can say that.
But once they verify things, then it's
green.
And if there is some sort of detected
attack by Pep, we'll turn it red.
And so if a bad key is used
or there's a known
attack that we've detected within within
the system, we can let Grandma and Bob
know that, hey, something's not right,
and we want to keep it that simple.
And yes, under the hood, it's a lot more.
It's what most of us are doing with GPG
Plus Plus Plus.
But for Bob and grandma, we want to make
sure that this is about
as complicated as it gets.
But we also know that Bob and grandma,
maybe grandma is technically inclined,
but Bob Bob does other things.
He's more interested in other stuff,
and he's not necessarily going to want to
install a Thunderbird with an email on
his Linux system because he doesn't have
one. He has an iPhone,
but we still want him to use it.
And so one of the challenges for
us is that
we want to be able to reach people where
they are.
It does not make sense to say, Well, you
know what, if you want to encrypt, you're
just going to have to get down and dirty
because most people won't do it.
My father's a chemistry professor.
He's a very bright man.
He can understand the math behind
encryption, but he does not want
to go through the pain of setting things
up to write encrypted emails to me.
He just doesn't. He's got other things to
do, and he told me that,
but I still like him to use it now.
He uses outlook and I can say whatever I
want about that, but that's what he uses,
and that's all he's going to use.
So we want to ensure that we reach people
where they are.
But at the same time,
we want as much of this to be as free and
transparent as possible.
Closer solutions have all sorts of lovely
problems. My former Homelander's
is really fond of
trying to trying to slip in back doors
to to various encryption products, and
we don't want that.
And so we developed an architecture which
for us seems to handle our main functions
very well in a way that's isolated.
It remains free software
and we're still providing services
for applications which are
at a level that people are normally out.
So
you say, if I could expand, so I am the
core engine developer. I work way down
here, the engine.
There are two main, I guess two
I would call them. Two main functions are
probably other things we do that I should
talk about, but we make sure that all
the cryptography happens down here and
we make sure that the mails get
passed and generated and dealt with,
and everything gets decrypted and put in
the right place and keys get imported.
All the crypto stuff, all of the really
detailed mime stuff that needs to happen
to a message that happens down here.
Part of our architectural design to
is to separate this sort of cryptographic
complexity and protocol complexity and
everything else from the
UI complexity.
You don't want me designing your UI.
Anybody here you GeoCities back
in the day. Blink tags.
Yeah, that's what it would look like.
It'd be awesome, and my son would never
speak to me again.
So we want people who are experts in
writing applications to have an easy
way to implement our protocol.
But at the same time, we don't want them
having to worry about the crypto and
stuff. So we've separated those things
and provided sort of an API layer these
adapters, which
allow them to actually.
Sorry, sometimes I get tripped over my
tongue.
They are they allow application
developers to be able to interact with
our engine without having to deal with
the really dirty stuff.
And it allows us to rely on people who
are way more expert and weigh better with
user interfaces and designed to deal with
what's actually interfacing with our
customers.
So up until the adapter
level up above the adapter level and
the adapter level down, that's all free
software that's all maintained by the
foundation part of our entity, which is a
nonprofit, the
visions that we developed for money.
Those are handled by the company security
and those are nonfree.
That doesn't mean you couldn't develop a
free software client on top
of the engine, but it
does mean that this is how we we
we have to make our bread.
And again, we want to reach people where,
where, where they are.
It has some other kinds of implications,
though. So.
Because those are proprietary apps
that sometimes makes it very hard for
them to interface with free software, we
all kind of know this is an issue
and our decision to do things this way to
keep it free at the bottom and to make
it available to everybody at the top
where we're with everybody has created
really one main set of challenges
for engine development. So there's
there's that set that comes from this
architectural design.
And the other is simply the domain
again, you'd think.
I mean, I've been I've had emails since
1991. You'd think it would be easy to
deal with, right? I mean, should be
standard and everybody does the same
thing, and it's really not
so.
Yeah, it is that.
So
I'll start with talking about the free
and compatibles.
Ideas, so if we want it to be free, we
want free software.
It has to remain compatible with these
upper level proprietary
software pieces, and there are three main
challenges with that that I'll discuss.
So first is making sure we all speak
the language the same language and
use a portable language.
See, is great. You can use it everywhere
we. So the engine is all in C 99
kind of. But Microsoft does
some things in its compiler that are not
exactly C 99.
So we always have these little challenges
on various systems where it's like, yeah,
there is a standard, but platforms
like to deviate just a little to make
your life fun.
We want to limit the dependencies we have
because especially with free software,
you might have several different
licenses. You have to figure out what are
going on. And we have these two,
we have these two main things that we do
down in the engine cryptography and mind
processing.
We don't really want to roll our own.
I mean, rolling your own crypto.
Well, some people can do it.
Where's Neal? Is it?
I know
you want somebody who knows what they're
doing to roll their own crypto.
And yeah, I understand the cryptography
behind it. But I am not a cryptographer
and mime.
It just turns out is really freaking
hard. And the and
we want to limit the dependencies to the
stuff we really have to borrow from
somewhere else.
These adapters are really nice for making
sure we speak the same language.
Basically, it's, you know, translation
from iOS version of
iMessage object into
what ours looks like, and that goes from
Objective C to C or for
Android, it's JNI.
It's Java to Java to see.
So that's that's how we sort of deal
with it.
But it's a challenge.
Not quite as challenging, though, as the
libraries themselves.
So for the most part, what
we've had, I guess
most trouble with in terms of
making things work together is getting
crypto library licenses and what the
proprietary guys will let us deal with to
work out. So everybody knows the Apple
Store is really, really nice about
letting you have GPL libraries in there
and then you can't.
So right now we have a couple of
different crypto engines we use.
We were using code OPG.
Most people use code OPG.
It's kind of a standard,
but since we can't use,
we can't use GP Jimi, which is a library
interface to it in
in the Apple Store we have to use, we had
to find some other free library that does
crypto now.
There aren't a lot of super awesome
crypto libraries out there that are free
and you want to be really careful about
those. And so we use net
p-gp, which is available under a
previous license.
But I think the last official
update of that was in 2010.
We maintain a fork, which is more
updated.
And that's what we've been able to find.
That works for us at this point.
And so that's something that that's
difficult because then you're maintaining
another project just so that you can
actually be able to deal with this
proprietary saw,
even if you have two great free software
from crypto libraries that everyone's
going to use.
You can't really just do drop in
replacement. So we have kind
of an additional it's not an adapter
level, but it packages things
so that they look the same semantically
as far as the engine's concerned.
But it may be that one crypto engine does
things incredibly differently.
So, for example, Net P-gp does not do
detach signatures on non-filers.
So you will let us do it with with
with a string. We have a memory.
We can get a detached signature for that.
It's something we need that BGP
doesn't let us do that. So you then you
have to go into the code and like, figure
out how to do it yourself and write
another adapter. And sometimes that can
be messy.
One thing that is sort of, I guess, one
of my favorites is that if you're
a free software developer, one of the
great things about it is you
get to decide or you get to make more
decisions about
how that product or our project works.
You can make if you've got a religious
conviction about a programing language or
a way of doing things.
If it's your project, you can
do it. Your boss is not going to come to
you and say, Hey, you're fired.
I want it this way.
You know, there are consequences to that,
but you get to make those kinds of
decisions.
So even with really good libraries,
sometimes the developers of those
libraries have content that is not
compatible with yours.
One of the things we try to do with Pep
is to give as few prompts as possible,
especially prompts dealing with crypto,
because we don't want people to have to
say, you know, 10 times, do you really
want to leave this kid you really wanted
to leap is key because we don't want them
thinking about keys.
But for example, going to Biji
prompts for certain things, and it does
it very, very intentionally and
with some, I think force of
purpose behind it and getting out of
doing those things turns out to be a lot
harder than you would want it to be,
because maybe the developer thinks it's
so important that he doesn't want to make
it easy for you to do that wishy.
I could be doing it, too.
But sometimes there's also no good open
source library solution because the
problem is heart.
And that's sort of what I'll get into
after this, which is that our domain mime
is really, really ugly and
we do have a free software mime
library.
And I don't want to be too critical of
the developer because we I tried to write
one, and it turns out it's it's a
difficult, difficult problem.
But regardless, often
there's not the thing available to the
tool available that you need to be able
to do the development. And then the
question is, do you have the time?
Do you have the resources?
Do you have the knowledge to roll your
own or are you stuck with kind of
a solution that almost fits?
And then you spent a lot of time trying
to fit it into that box, which it's
not really made for?
And that's been a challenge that's sort
of constant for us and in this process.
And I think everybody has it.
But this is the first paid big
free software project I've worked on.
So I guess
this is just my experiences.
And then there's distributions and under
the cycles of current platforms.
So lions and tigers
and bears, oh my is a popular American
kids book. This was languages,
libraries and distros.
Oh my. But the distributions are not
usually my nightmare, but
the default distributions for
and I'll give you the example because we
had a big fun time with this.
Damian's default windows
default fedoras default
were all completely and widely different
and in fact, internal parts of those
libraries. So dependencies that were
related to gloopy were very, very
different from one another.
And it turned out they had very different
functionality, and that functionality was
super important to us.
Some of those libraries were broken.
We couldn't do anything with them.
And so if somebody insults the system
default, which of course, we kind of want
to let people do, we want this to be
easy.
It's bad when we tell them, OK, well, you
have to go to PPA to get
a different version of this, or we have
to package another version and ship it
with the product. So then they have two
versions of the library in the system.
It can be really difficult.
And, you know, sometimes sometimes
I don't usually expect Debian stable to
have bleeding edge stuff, but sometimes
it does because it's well-tested
and sometimes it's decrepit and hasn't
been updated since dinosaurs walked the
Earth. And sometimes you've just got a
bunch of all of it, so that can be really
tough.
The other thing is that some
distributions that we use have an
installation candidate for us, a piece of
software that we want, and sometimes they
don't.
And sometimes that is
something that's default with the
operating system sometimes.
A lot of extra insulation, so this is
always a problem with dependencies, but
it's become particularly messy with us
because we again have these proprietary
platforms on top of it.
So it's not just a matter of am I using a
bulldozer, Damien? It's the well, what
is I was going to do with this?
And what will windows do with it?
And so this mobile versus desktop
solution is bonus fun action for all of
us. And sometimes I'm very glad I'm down
in the engine because while I do
have to deal with that from a dependency
point of view, I don't have to deal with
the problem on top and
into the bug reports.
OK, so as I said, there's
there's sort of this portion of it comes
largely from our architecture,
but our domain is not really
very easy either.
So the meI'm standard,
if say so.
So if you've ever looked at the source of
a meal, sometimes it'll say like
content type message RC 822.
And that's the initial standard that was
released for internet mail messages
back in well when dinosaurs walked the
Earth.
And it would be nice if you could just
take that grammar and shove it into
a pasture generator.
And in doing so,
magically get something that'll poor pass
all of your emails.
And you would also think that it would be
standardized because you've got so many
different email clients sending stuff out
through the internet. How can we all
possibly read each other's emails if we
don't agree on something?
Well.
It's because there's this rule, which
says if you were doing mime,
you should accept very liberally,
take almost everything, you get in and
accept it and find something to do with
it. But what you should produce, you
should produce strictly according
to the rules.
Well, most people don't produce strictly
according to the rules. So I guess it's
except deliberately and produce whatever
you want. And if your company is big
enough, everybody has to accept it, which
is really how it works.
But even if you're going to follow all
the rules, it's not easy.
So an RC, if you don't know,
is a refresh request for comments.
It is often a formalized
statement of the accepted practices
for something. So for example.
For internet mail messages, it's what
people were doing to send internet mail.
And somebody said, Well, we need to
formalize this, so everybody agrees on
it. And then the request for comments
go to the ATF and is accepted and
or rejected or modified
several billion times.
So RC 22 was the initial standard,
but that's been superseded by RC 28 22,
which has been superseded by RC 53
22, which I think the current standard.
But you can't just say, OK, well, I'm
just going to read RC 53 22 for two
reasons.
One, it refers back to the other two
repeatedly.
And if it's only those three things that
would be great, those are just the things
for mail messages.
But it also is one
of these things where, well, let's say
we've changed something between 22 and 50
to somebody out there has got a
client that doesn't implement the
difference.
So if something has been implemented or
suggested in a standard, it is in the
mail space forever.
So you have to deal with what was and
what is, and sometimes they're in
conflict.
The other thing is, while those were the
standards I gave you, but these are
updated by RC 11:23,
each one of which six 13:47.
And that's all I could get with sort of a
one level of depth of clicking through
the RC.
So you have to read an awful lot just to
kind of understand what's going on out
there. The grammars themselves sometimes
seem to be in conflict with themselves.
So generating your own parser
and generator would already be hurt,
but that's not enough.
That's just mail messages.
But at some point, people started to
decide to send weird things to each
other, like videos and
PDP keys and other
things, other kinds of content.
And that's where mine comes in.
So those are the multiple perfect
multi-purpose internet mail extensions,
and there are it's in five parts.
It's great reading if you're, you know,
if you've got something nothing to do
between now and New Year's, I highly
suggest you avoid them.
But again, these are also updated
and obsolete and by lots
and lots and lots of our season and
they don't go away.
If you really want to do it right,
you end up having to come in contact with
them.
But there's more because we don't just do
mine, we do mime and crypto mindless
crypto. And I know I don't have all the
resources for these.
And Neil can make faces at me.
These are sort of the main top-level
ones. There's one for crypto cryptography
or encrypted messages and signatures via
mine. That's obviously 1847.
It's the initial one.
There's one for SMI, which doesn't do.
And then there's one for P2P or two for
P2P, which we do.
And I'm sure there are more because I
think there's one that starts with 40
that I can't remember at the moment.
So there's quite a bit of this,
and this is really what it would take if
you wanted to make a magic email parser
that that deals with everything out
there.
And we have
a free solution called the
Bat Pen.
And if you look at the code, which
is difficult to understand, it's not
terribly well documented.
You see that the attempt has been made
really to do what I just suggested to
take the grammar and literally translate
it towards a parser.
And that is problematic
because big companies
do whatever they want and sometimes
customers want weird things.
So, for example,
enterprises are concerned about security,
and I'm not really sure what the attack
is, they're concerned about, but for
example, exchange has something called
hetero firewalls.
And that means so when you send out an
email on the internet, you know, it's got
all these headers. There's the ones that
we all see if you don't hide them that
are from men to one subject.
But there's also some additional stuff,
like what time it was sent out
and then the various servers
it was received by along the way.
And there's something called X headers,
which are supposed to be optional headers
that people can use to put additional
information in.
And we use some of those in order to
identify your messages.
But.
Header filtering is something
that's used to filter out any
non-approved header, and that's
perfectly legitimate, according to the
RC, but it makes things difficult
if you want to do anything with with
e-mail headers, and I actually don't know
if filtering out ex headers is OK.
There's a bunch of others that are OK to
filter out, but this kind
of thing happens.
Symantec decided to rename our
attachments, I think, and that causes
some additional problems.
And these are things that are maybe
they're either unspecified or specified.
You're not supposed to do them, and it
doesn't matter.
Sometimes people leave things out
or they add things that are not allowed.
So there's
OK. So there's two kinds of of,
I guess, returns.
There's a carriage return in a line feed.
And back in the day when you were either
typing on a typewriter or had a you had a
teletype terminal, a carriage return
ends the line and goes to the beginning
of the next one.
Technically speaking, I think a line from
just advanced at one line.
These are just characters for us now
and see it slash and slash slash are,
but we call them S.R.
and Elf. So character return in line
feed.
And this is really
dumb, and it sounds really stupid, but
it's used as a token everywhere
in my message.
So in order to be able to pass on my
message and understand what it's doing
and break it up into the right parts,
the carrot, there's a character turn line
feed cigarets that's called S.R.
Left that must be in all the right places
at all the right times.
Or things go bananas,
except for there are some clients which
do what the RC says not to.
So the RC says the body of a message is
simply you use ASCII characters.
There are extensions to that, but this is
the mail rc, and the only two
limitations of the body are as follows.
This is this is the first one.
S.R. and Elf must only occur together
as Kremlev.
They must not appear independently in the
body, so a carriage
return before S.R.
left was technically not OK.
And there are clients that don't
accept that, and our library certainly
didn't because that was not OK
and the grammar specified by the RC.
So we choke on that for a long time.
It's small, but trying to find that and
figure out what happens takes a lot of
your time. So it's technical that you get
every single time you use one of these,
every time you use somebody
else's library because you're going to
have to spend time figuring out
why it doesn't work for you.
And that means you get to know their
code, too.
And sometimes people add things which
aren't part of a standard. It doesn't
mean they're wrong or even entirely
specify. Now, I haven't looked at the
memory hole specification, which is
a way of removing metadata from
the headers of your mail and sticking it
into the body of the mail so that it can
be encrypted and safely used
until it's received on the other end.
But when memory hole was initially
specified, it was
very vague and.
That's definitely not in the standard,
and there are some additional things that
that enigma was put in to be
able to to use memory hole, which is
it, which is a nice idea for protecting
this metadata, but my person is
going to choke on it or at the very
least, ignore it.
And so that's one of those things.
Again, we have to go back into the code
because it's it's not a standard thing,
you know, and sometimes something is
totally standard, but normal clients
choke on it anyway.
So if you have a really long file name
or you use a non,
you use a non Unicode
character said, or Unicode
is a problem. So using non-U.S.
ASCII characters that then
there are some special things that happen
with it in the mind. But some clients
just rename it.
Some clients ignore it entirely,
and some use the correct format for that.
And it turns out that a lot of clients
choke on it when you do what the RBC says
to do.
So it's not an easy problem, and that's
why I don't want to bash bash the
provider of our library.
But at the same time, it costs a lot of
time and effort to figure out why it
doesn't work. And then you have to go
back to the I.R.S. and go, Aha, this
is or is it in the RC?
And that's why it's not implemented.
So that's
this is my personal nightmare.
Every time I have to go back in here, I
want to cry.
Well, what does this all mean for the
domain when it means that mime is hard
and standards don't solve everything?
And my boss is a
really bright guy and he's
really good, a generation
of code and all sorts
of stuff, and he really wanted to
be able to just generate a mind parser.
And it just turns out that I think that
that dream of magic magically generating
a mime parser may be doomed to failure
because figuring out what the
actual grammar is for the moment
is probably impossible.
So I've kind of baffled about what I
do up here and complained about things,
and I like I said the talk I wanted to
give was more kind of a
if I could talk to myself 20 years ago
when I was taking a fairly useless
software engineering class,
what would I tell myself?
That would be more useful?
The first thing is that
so we try to be as interoperable as
possible, and I think we plan pretty
well for it.
But it's a lot of work still.
So, you know, it's and it's not always
the work you expected.
And I think that's something that's
really important in development that you
realize that it doesn't matter how
well you've created something.
Things will come up that you may not have
the tools to deal for and you have to
develop them.
Using the right language won't solve all
of your problems because you just may
have to deal with too many other
languages and problems to to.
To let that be your only source
for interoperability and libraries
won't solve them, either. You still got
work to do, even if somebody else has
done the hard core work for you first.
You'll often find yourself at the mercy
of other people software.
The decisions, again for us said that
it's we have these
two core areas we we deal with
and, you know, from time, it's that we
have such a literal parser and
generator for crypto.
It's really more a matter of having
different takes on how you think
people should use cryptography.
And software use is really great, but you
have to pay attention to to how much
extra work you're going to put into it.
And you know, I first of all, I consider
I think everyone should consider therapy.
It's awesome. But if you're going to work
with my maybe, maybe have an extra
therapist because it's it's a nightmare.
I hope I didn't babble everybody's ears
off. That's really the end of what I had
to say.
I just kind of wanted to give some
some some feeling for what, what
kind of work is going on under the hood
because we have a lot of PR that goes on
with Pep, but not a lot of, well, here's
where we get our hands dirty.
And I'm I'm the dirty person.
I have a student out here who is
laughing, I'm pretty sure.
And if you have any questions, I
am willing to take them either about Pep
itself or about my current nightmares.
And thanks for being here and listening.
Thank you, Chris.
So we have lots of time
for Q&A, so if you have any questions.
There are two microphones in the room and
you can line up there.
And while there's no one
standing up there, do we have questions
from the internet signal angel?
You know, the
internet does fully encrypted and has no
questions.
Accidents.
Anybody in the room?
Anybody still awake?
Raise your hand.
OK.
Well, seems like there were no questions,
so then we have to thank
Christa again, give her a nice applause
for this awesome talk, please.
Thank you.