[00:00.000 --> 00:01.440]  Is this good?
[00:01.580 --> 00:02.240]  We're getting a good level.
[00:03.100 --> 00:04.920]  Okay, as he said, my name is Peter Wayner.
[00:05.240 --> 00:06.460]  It was a long time ago.
[00:06.560 --> 00:07.400]  I was just thinking about it.
[00:07.480 --> 00:10.920]  I was realizing I'm getting up on my 30th anniversary of poking around the Internet.
[00:11.180 --> 00:13.920]  And this was long ago when I was in the Palo Alto school system.
[00:15.140 --> 00:19.520]  And back then, and I think it's still the case, Hewlett-Packard was always very gracious.
[00:19.800 --> 00:21.980]  And they kind of left these machines around for us to play with.
[00:22.020 --> 00:25.940]  And we found our way to poke around.
[00:26.120 --> 00:29.920]  And they gave us their own little systems we were supposed to talk to.
[00:30.000 --> 00:31.580]  But they left the modems unconnected.
[00:31.680 --> 00:33.460]  And someone says, well, we should try this number.
[00:33.800 --> 00:37.320]  And it was, I guess it was the tip.
[00:37.420 --> 00:41.940]  It was the AIMS tip for getting into what was then the ARPANET.
[00:42.040 --> 00:43.760]  And you dial-up and it would ask you for a password.
[00:43.880 --> 00:44.700]  And then it was explained to me.
[00:44.780 --> 00:47.400]  He goes, you can just hit return and it will work.
[00:48.580 --> 00:50.140]  And there really wasn't much you could do.
[00:50.140 --> 00:55.320]  Except we ended up talking to some guy with a primitive chat system at MIT who said he was editing a file.
[00:55.520 --> 00:57.180]  And I think that's all that we managed to do.
[00:57.260 --> 00:59.980]  But there were only about 30 or 40 machines on the Internet at that time.
[01:02.900 --> 01:06.360]  So, apropos of that, the real reason I'm here is not to tell you those kind of stories.
[01:06.400 --> 01:10.860]  But to talk about this idea I've been flogging for the last four or five years.
[01:12.400 --> 01:19.560]  And this is an idea that came to me when I was working on an article about privacy and the Internet.
[01:19.800 --> 01:22.060]  And this was maybe late 90s.
[01:22.160 --> 01:27.220]  And people were talking about these new stores that were springing up like Amazon.
[01:27.220 --> 01:33.360]  And everyone wanted to build these personal dossiers on their customers because that was how we were going to offer all this great service.
[01:33.520 --> 01:34.460]  It was going to be customizable.
[01:34.960 --> 01:37.760]  You were going to be able to go to the store and it would know everything about you.
[01:37.800 --> 01:40.140]  And it would show you what you really wanted to buy.
[01:40.240 --> 01:43.440]  And you wouldn't have to waste your time looking at stuff you didn't want to buy.
[01:44.260 --> 01:45.600]  And that was all well and good.
[01:45.600 --> 01:48.920]  But, of course, everyone was also worried about the privacy amplifications of this.
[01:49.480 --> 01:59.940]  And so I got in this argument with this guy where I said, it did not seem obvious to me that in order to offer this level of service you had to have this dossier.
[02:01.080 --> 02:08.520]  And I had the advantage of once meeting the guy, Ralph Merkle, who was one of the inventors of public key cryptography.
[02:08.880 --> 02:11.420]  And when I was talking to him, I said, well, how did you come up with this idea?
[02:12.280 --> 02:16.520]  And Ralph said, he goes, well, I wondered, you know, could you use two keys?
[02:17.000 --> 02:19.920]  One that would lock the data and another one that would unlock it.
[02:20.080 --> 02:22.600]  And he goes, I tried to prove that that couldn't be done.
[02:22.980 --> 02:25.680]  And when I couldn't do that, I tried to prove that it could be done.
[02:26.100 --> 02:29.720]  Now, if you know enough about math, that still hasn't been resolved.
[02:30.300 --> 02:33.240]  But I tried to take that spirit and apply it to this case.
[02:33.240 --> 02:39.480]  And I tried to prove first that in order to have these stores, you had to have these dossiers about all your customers.
[02:39.860 --> 02:43.320]  And when I couldn't try to prove that, I tried to prove the opposite.
[02:44.500 --> 02:47.800]  And I did not come up with anything as cool as public key cryptography.
[02:47.800 --> 02:51.700]  I didn't come up with anything that was, you know, as mind-boggling.
[02:51.700 --> 02:57.780]  Because what I ended up doing is finding out that the old crypto protocols would do pretty much what you wanted them to do.
[02:57.900 --> 03:11.460]  But I did come up with a lot of examples for how you could run a business like Amazon or how you could run a database or you could run a business for any kind of database that was out there without keeping these extensive dossiers.
[03:15.370 --> 03:19.630]  So this is the traditional way that people see security.
[03:20.010 --> 03:22.210]  And this is what I'm trying to invert here.
[03:23.130 --> 03:29.050]  The traditional way is that you kind of see your database or your system or your store or whatever it is as this fortress.
[03:29.530 --> 03:35.710]  And you're going to have all this secret information about your customers, but the way you're going to try to protect it is to build a wall around it.
[03:36.210 --> 03:39.910]  And inside that wall, you're going to have all the information in the clear.
[03:40.150 --> 03:45.690]  But if you do a good job with that parameter, then the people, the customers, their data will still be safe.
[03:47.930 --> 03:49.370]  Now, there's some truth to that.
[03:49.450 --> 03:50.170]  You can do a good job.
[03:50.210 --> 03:50.890]  You can get Oracle.
[03:50.890 --> 03:53.110]  And the ads say that Oracle is unbreakable.
[03:53.310 --> 03:54.670]  So, you know, there you're set.
[03:56.450 --> 04:01.870]  But, you know, anybody here in this conference knows that that's not really the way it works.
[04:02.650 --> 04:07.390]  And, you know, even if you do buy Oracle, there are lots of other ways that people can get around things.
[04:07.570 --> 04:09.470]  One, there could be a hole in your operating system.
[04:09.590 --> 04:16.070]  So even if you do a good job with your database security, there might have been some hole left in there because you're running it on, say, the Windows operating system.
[04:16.610 --> 04:21.810]  Or you could have another hole where someone actually just walks in the door and just takes the hard disk.
[04:21.970 --> 04:24.110]  So then all of a sudden, they have the data in the clear.
[04:24.270 --> 04:30.370]  So even though you've got really great computer security, your physical security may have a hole in it.
[04:31.010 --> 04:36.970]  And even if you do a good job with all those traditional solutions, you could still have problems with insiders.
[04:37.210 --> 04:43.250]  And this continues to be a problem where you have people at the IRS are snooping on famous people's tax forms.
[04:43.770 --> 04:47.210]  You know, pretty much anywhere you go, you have a problem with insiders.
[04:47.530 --> 04:59.630]  And so if you're running a business, if you're trying to build these things and you're trying to keep your customers happy while keeping information about them, it's very hard, I think, to use the traditional solution.
[05:01.210 --> 05:05.390]  So what I've tried to do is illustrate some ways that you can keep...
[05:06.430 --> 05:12.490]  you know, have this system that does useful work that answers questions for people without actually knowing anything at all.
[05:12.830 --> 05:18.290]  So you want to have a database that answers useful questions without holding any useful information.
[05:18.570 --> 05:28.330]  And so the goal I set for myself was to build these databases and to imagine these systems so that they would be secure if someone gets root on the system.
[05:28.470 --> 05:30.870]  They would be secure if someone walks in and takes the hard disk.
[05:30.970 --> 05:34.350]  They would be secure if you happen to hire the wrong person by mistake.
[05:35.970 --> 05:37.230]  Okay, now here's the solution.
[05:37.390 --> 05:41.310]  I found that it was quite possible to reuse a lot of the old crypto protocols.
[05:41.430 --> 05:46.830]  I found, for instance, the classic UNIX password database is a good early example for how to do this.
[05:47.330 --> 05:50.310]  Diffie-Hellman, SHA, MD5 were all the tools I needed.
[05:51.650 --> 05:54.450]  But this time around I wanted to kind of recast the model.
[05:54.610 --> 06:00.550]  So I really think what I was changing when I was working at this idea was that you didn't have the fortress.
[06:00.890 --> 06:03.590]  You could just use these tools in a different way.
[06:03.890 --> 06:12.890]  So instead of keeping the information in one contextual space, you were going to diffuse it in this mathematical space and only the right person was going to be able to see that information.
[06:13.530 --> 06:25.690]  So we were trying to think of the database as instead of being this all-seeing oracle with a small O, it was going to be kind of this neutral mathematical switch where the data would just flow through it and it wouldn't know what was going on.
[06:26.130 --> 06:30.270]  So those are a few little metaphors I built along the way.
[06:31.250 --> 06:35.550]  Now here are some advantages I claim for approaching security this way.
[06:36.070 --> 06:37.110]  First of all, it's cheaper.
[06:37.630 --> 06:38.550]  You don't need...
[06:38.550 --> 06:39.370]  Let's face it.
[06:39.450 --> 06:44.110]  If you're going to buy Oracle, it costs a lot of money to hire someone who knows how to install Oracle.
[06:44.290 --> 06:45.390]  I still haven't figured it out.
[06:45.390 --> 06:55.690]  One of my friends who I guess worked in the big three-letter agency said he used to work at Oracle and he said he goes, no man, there's no way I can install that.
[06:55.850 --> 06:57.730]  You've got to really get someone who knows what's going on.
[06:57.890 --> 06:59.690]  And he worked for Oracle for five years.
[07:01.350 --> 07:08.190]  So if you use these solutions, I claim that it's a lot easier to build them and it's a lot easier to keep them secure.
[07:09.830 --> 07:12.770]  Another big advantage is they're going to be OS independent.
[07:12.770 --> 07:15.590]  You don't have to worry if you've got holes in your operating system.
[07:15.710 --> 07:21.670]  And let's face it, I wouldn't want to try to secure any operating system no matter how good it is, even if it's, say, OpenBSD.
[07:22.870 --> 07:26.690]  And the other advantage I claim is that you don't have to worry as much about your employees.
[07:26.990 --> 07:29.870]  And you don't have to worry about the people that you give insider access to.
[07:31.570 --> 07:35.430]  Now here are the disadvantages that should be pretty obvious when I work through these examples.
[07:35.810 --> 07:37.470]  One is that there's no super user.
[07:37.670 --> 07:43.350]  One of the problems with disenfranchising your insiders and taking away that power means that they can't help people.
[07:43.550 --> 07:47.970]  So if something goes wrong with your system, someone calls up and says, I forgot my password.
[07:48.410 --> 07:53.470]  Someone calls up and, you know, it's someone who can't work the computer for whatever reason.
[07:53.790 --> 07:55.510]  You know, you can't really help them.
[07:55.730 --> 08:00.730]  And I claim that there's still many instances where this is still a valuable solution.
[08:00.730 --> 08:04.630]  And when you do the calculus, it's okay to go through disenfranchising your super user.
[08:06.090 --> 08:11.590]  Some of the solutions I've got here are vulnerable to some kind of guessing attacks, but there are ways to work around it.
[08:12.230 --> 08:15.370]  And the problem is that you essentially give your user more responsibility.
[08:15.810 --> 08:26.030]  Now, I think that's something that's an easy sell here at 2600, but anyone who's dealt with a larger user community means that there are some limitations to how much responsibility you can push on people.
[08:27.990 --> 08:31.190]  Okay, so let's go to the first level example I wanted to show you.
[08:31.730 --> 08:33.610]  I'm going to start off with one-way functions.
[08:33.950 --> 08:40.390]  And I suppose a lot of you are familiar with this, but in case you aren't, I'm going to just describe a one-way function the way I'm thinking about it.
[08:40.810 --> 08:47.270]  And that's if you have a function, it's going to be a function f of x, that if you have x, it's very easy to compute f of x.
[08:47.470 --> 08:54.450]  But if you know f of x, it's very hard to go backwards and figure out which x you stick in that function to get the right value out.
[08:55.370 --> 08:58.130]  So it's going to be something that's easy to compute but hard to invert.
[08:59.650 --> 09:02.530]  And it turns out that there are a number of these functions that are out there.
[09:02.950 --> 09:09.030]  And the only limitation to this is that the problem is is that we don't have any proof that they're hard to invert.
[09:10.370 --> 09:19.430]  Mathematics makes it very easy to prove things constructively, but if you don't, it's very hard to prove that you can't do something with mathematics.
[09:19.910 --> 09:21.450]  And it's like proving a negative.
[09:21.590 --> 09:22.410]  It's very hard to do.
[09:23.330 --> 09:27.630]  So one of the classic ones that you might want to use today is SHA-256.
[09:28.050 --> 09:30.810]  And there's a variation I call the HMAC.
[09:31.070 --> 09:32.690]  And so that would be a good way to begin.
[09:33.010 --> 09:37.250]  One of the problems we've had recently, or in some ways it's not a problem.
[09:37.350 --> 09:38.650]  It's a very exciting time in mathematics.
[09:38.830 --> 09:42.210]  There are a lot of people who've been poking holes in these one-way functions.
[09:42.570 --> 09:47.530]  And so they're looking at SHA and they're finding out neat ways that they can get around that.
[09:47.970 --> 09:54.050]  And the ways that they can not necessarily invert them, but ways they can cause these things called collisions.
[09:54.230 --> 09:55.310]  So they're finding these weaknesses.
[09:55.850 --> 10:02.350]  So if you're going to be playing around with these one-way functions, it makes sense to keep track of what the research is that's going on.
[10:03.350 --> 10:09.450]  You could also use kind of classic private key or public key encryption to give yourself a one-way function.
[10:09.730 --> 10:14.750]  If you use public key encryption, one of the things you can do with that is you can actually build in a back door.
[10:15.230 --> 10:20.810]  So you may or may not want to have a back door in your system, but if you want one, it's possible to do it with the mathematics.
[10:22.170 --> 10:37.170]  Now, the last bullet point on the slide says that one of the big advantages of one-way functions is that even when you pass stuff through this one-way function, in this case I'm using H instead of F, you can test equality.
[10:37.490 --> 10:50.510]  So if I give you two values, you'll be able to say, you may not know what those values are, but if they have the same hash value, which is the term you use for putting it through a one-way function, you can test that they are the same.
[10:50.970 --> 10:58.810]  Now, the disadvantage to that is you can't really test greater than or less than, but that's, you know, you can work through the proof of why that is the case if you want to.
[11:00.410 --> 11:04.970]  Okay, so that's the mathematics or a very skim over the mathematics.
[11:05.130 --> 11:10.990]  Now, let's see how you could do this if you're in the real world and you want to help people build privacy-protecting databases.
[11:12.190 --> 11:18.290]  So here's a story or an anecdote which I find, which I think motivates why you want to do this.
[11:19.490 --> 11:29.990]  Obviously, Amazon's well-known and there's some people who've sued them and they've become kind of a target because they have a privacy policy and people have sued them for violating it and that's been a problem for them.
[11:30.390 --> 11:32.470]  But there are a lot of other companies that are out there.
[11:32.550 --> 11:43.250]  One of them is called Crutchfield and I was about to give a course on this topic and two or three days beforehand, I went outside and I went and I saw my neighbor.
[11:43.390 --> 11:46.050]  He was sweeping up all this glass around his car.
[11:46.150 --> 11:48.170]  Someone had broken into his car and stolen the stereo.
[11:48.850 --> 11:50.010]  And I said, wow, that's terrible.
[11:50.150 --> 11:52.910]  And then I looked up the street and there was a pile of glass outside of my car.
[11:53.130 --> 11:59.130]  And I went up there and they weren't able to take the stereo because it was so complicated getting it out of the dashboard and maybe someone came along.
[11:59.790 --> 12:03.590]  But both of us, both of our cars were broken into.
[12:03.790 --> 12:09.770]  And I can tell you that we don't have the nicest cars on the street by any measure.
[12:10.710 --> 12:17.550]  And we were wondering, you know, geez, he said, he asked himself rhetorically, why would they choose our two cars?
[12:18.390 --> 12:20.270]  And this took me a while and I thought about it.
[12:20.350 --> 12:26.870]  And then I realized both of us had bought stereos from Crutchfield online within the last six months.
[12:27.110 --> 12:32.010]  Now, I have no idea whether there's any link between Crutchfield and whoever broke into our cars.
[12:32.310 --> 12:35.390]  But it has always struck me as something that's suspicious.
[12:36.190 --> 12:40.390]  Because Crutchfield is a really nice, high-touch store.
[12:40.590 --> 12:41.990]  They take very good care of you.
[12:42.310 --> 12:45.410]  When I called them up, they said... In fact, this was online.
[12:45.710 --> 12:49.270]  When I was online, I typed in, you know, what kind of car I had.
[12:49.390 --> 12:51.770]  And it said, well, these are the stereos that will fit in your dash.
[12:51.990 --> 12:54.070]  And they presumably did this for my neighbor, too.
[12:54.410 --> 13:02.410]  So not only did Crutchfield have my name and my address and what kind of stereo I had bought from them, but it also knew which kind of car it had been installed in.
[13:02.510 --> 13:05.530]  It knew the model year and, you know, the address.
[13:05.670 --> 13:09.770]  So it's quite possible for someone to find all that information from the Crutchfield database.
[13:10.490 --> 13:14.590]  Now, I don't know if someone... if there's an insider who's doing these kind of things.
[13:15.030 --> 13:18.930]  But I think that it's, you know, conceivable.
[13:20.910 --> 13:21.390]  Okay.
[13:21.930 --> 13:28.270]  So in my neighbor, when his stereo was... once he realized his stereo was gone, he called up Crutchfield and bought another one.
[13:28.450 --> 13:37.510]  So there's not necessarily much incentive for Crutchfield to do a great job or protecting the customer's information.
[13:38.590 --> 13:38.910]  Okay.
[13:39.030 --> 13:44.590]  So let's take a look at how you could protect your customer if you... if you really want to take care of them.
[13:44.870 --> 13:45.670]  Here's a table.
[13:45.810 --> 13:46.830]  And it looks like a database table.
[13:46.890 --> 13:48.270]  I might be able to make this a little bit bigger.
[13:50.950 --> 13:55.230]  We're losing a little bit because I'm using this JavaScript version of PowerPoint.
[13:55.910 --> 13:58.850]  But we've only lost one row off the bottom of the table.
[13:58.990 --> 14:00.710]  And you can imagine this being a database table.
[14:00.710 --> 14:02.670]  That's going to be inside of some customer's store.
[14:03.170 --> 14:05.750]  And on the first column is the name of the person who bought it.
[14:05.890 --> 14:09.930]  And there are a few columns that are missing, presumably with the address and the personal information.
[14:10.130 --> 14:13.810]  This is the item they bought, which is some pair of pants and the color and the size.
[14:14.370 --> 14:27.030]  And so the simple way I claim that you could go about fixing this is just to say, instead of storing the customer's name, you can store the hash of their name or the result of putting their name through a one-way function.
[14:27.370 --> 14:32.610]  So all of a sudden, the customer's name is replaced with a number, just like all of our names were.
[14:32.850 --> 14:39.230]  It would have been actually interesting if they had hashed all the names instead of just giving us numerical numbers when you registered.
[14:41.550 --> 14:45.190]  But one of the neat things about this is, okay, let's see what you can do with this.
[14:45.310 --> 14:47.490]  So obviously the column is now gobbledygook.
[14:47.590 --> 14:56.710]  If you're an insider and you come to the table and you say, I want to figure out who bought that pair of Turing chinos or I want to figure out who bought that stereo that I want to steal.
[14:57.530 --> 15:02.630]  Or, you know, I guess if it was in... what was the car movie, the one where they had to steal all those cars?
[15:04.810 --> 15:05.630]  Yeah, exactly.
[15:05.830 --> 15:10.430]  Like if you're going... if you're... you know, let's say your database is really good and you've got $100,000 cars in it.
[15:10.850 --> 15:15.590]  You know, all of a sudden, that first column with your name is now obscured.
[15:18.830 --> 15:24.990]  So... but what good is that database?
[15:25.190 --> 15:31.410]  So obviously the insiders can't poke around the database and figure out something and figure out information that they might have used.
[15:31.530 --> 15:39.910]  So if Crutchfield had used something like this and it was the case that that was how my data was stolen, then that would have prevented that kind of crime.
[15:40.750 --> 15:42.330]  But there's still some advantages.
[15:42.530 --> 15:47.310]  A customer can come in, type in their name, and they can find out their list of past purchases.
[15:47.610 --> 15:58.230]  So if I wanted to go back to a store and I wanted to prove that I had purchased something, I could type in my name and then all of a sudden the database would release that information and it would become clear.
[15:58.370 --> 16:02.030]  It would bring it into the clear and I could prove that I had bought something in the past.
[16:02.510 --> 16:04.370]  I could get warranty service on it.
[16:04.470 --> 16:13.630]  If I happened to like a pair of pants and I wanted to know what the right size was and I wanted to order a new pair online without trying them on again, I could do that.
[16:14.030 --> 16:17.690]  I could... all of a sudden, all of my past information becomes open to me.
[16:25.300 --> 16:28.040]  Now, I think there's also something kind of interesting about this.
[16:28.120 --> 16:32.920]  The translucency, this effect that I'm talking about here, still balances the different needs.
[16:33.140 --> 16:35.340]  The marketing department is not frozen out.
[16:35.500 --> 16:41.340]  One of the things that you often hear is like, well, you know, the stores need to keep this information about who buys what thing.
[16:41.740 --> 16:48.200]  So they know that if you bought the red hat and you've got the blue pants, then they're going to buy more of those together.
[16:48.380 --> 16:50.000]  They'll be able to understand technology.
[16:50.000 --> 16:51.760]  They'll be able to use all their data mining.
[16:52.020 --> 16:56.080]  Well, what's going on here is that the marketing department is not locked out.
[16:56.540 --> 16:58.140]  So they can still do their job.
[16:58.140 --> 17:00.100]  They just don't know the name that's associated.
[17:00.260 --> 17:03.920]  All of a sudden, everyone's name has been replaced with this numerical pseudonym.
[17:04.640 --> 17:07.140]  So database mining is still possible.
[17:07.360 --> 17:08.860]  You can still match up records.
[17:08.960 --> 17:11.760]  You can still find out who are your good customers.
[17:12.080 --> 17:14.520]  It's just you can't... you don't know their names.
[17:14.880 --> 17:21.780]  And if they come back in and they type in their name when they're checking out for whatever reason, you can flag them and say, oh, these guys are a popular customer.
[17:21.880 --> 17:23.140]  Maybe we want to give them some freebies.
[17:23.240 --> 17:26.220]  You can do all those kind of gimmicks that the marketing department talks about.
[17:26.540 --> 17:28.640]  You just can't figure out what their names are.
[17:29.860 --> 17:34.500]  Now, as I mentioned at the beginning, that there are limits to how you might... to this system.
[17:34.860 --> 17:37.300]  I mean, one of the problems is that it doesn't stop all snoops.
[17:37.400 --> 17:41.900]  If you know the person's name and you want to find out what they've bought, then you can look things up.
[17:42.100 --> 17:54.480]  You may not be able to look for the car you want to steal and just figure out who that person is there, but you can look up what Bob Jones has purchased at this store in the past.
[17:55.500 --> 17:58.620]  And I'm going to fix that in a couple slides.
[17:59.760 --> 18:01.800]  And there's also... you could use a phone book attack.
[18:04.520 --> 18:06.060]  So I guess I just cover these things.
[18:07.180 --> 18:12.320]  So let's fix those problems by adding passwords.
[18:12.900 --> 18:16.700]  Well, instead of... if you notice here, I've got the same kind of table I talked about in the past here.
[18:17.620 --> 18:19.160]  But this time I added a different thing.
[18:19.220 --> 18:25.480]  If you look at the header of this table, all of a sudden I'm hashing not just the name, but the name and a password.
[18:25.760 --> 18:34.540]  So if you've got a database that's particularly valuable, you can ask each person to type in a personal identification number or some kind of secret that they keep only to themselves.
[18:35.460 --> 18:39.380]  So the example I've kind of cooked up here is one of a pharmacy.
[18:39.600 --> 18:48.800]  And I think that this is quite useful because pharmacies have lots of different requirements of keeping track of what their customers purchase for a number of different reasons.
[18:49.000 --> 18:53.680]  One, they want to help the customer because they want to maybe warn them about dangerous drug interactions.
[18:54.220 --> 19:04.880]  They have to do it for legal purposes because the DEA wants to track certain drugs and make sure people aren't... who knows what they're doing with it, but for some reason they have to track them.
[19:06.200 --> 19:09.060]  But there are downsides to this.
[19:09.760 --> 19:18.420]  If you have drugs like OxyContin or whatever Rush Limbaugh was taking or drugs like that, those are things that have black market value.
[19:18.600 --> 19:30.120]  And so if you have this database, you might know whose house you want to break into and who is there... In fact, down in Baltimore where I live, the sportscaster... I mean, this is something that must happen to you if you end up on TV or radio.
[19:30.600 --> 19:37.660]  But the sportscaster was caught breaking into his neighbor's house to take their drugs because he was addicted to them in the same way that Rush Limbaugh was.
[19:38.380 --> 19:42.460]  And so clearly there's something very powerful at work here.
[19:42.740 --> 19:46.060]  So this database, as a result, has dangerous value as well.
[19:46.200 --> 19:51.400]  And so maybe someone would break into the pharmacy or break into the pharmacy computer and use that to steal drugs.
[19:51.620 --> 20:07.680]  So if we use an approach like this, all of a sudden we have this translucent system where customers can come in, they can type in their name and their password, they can be sure there aren't any dangerous drug interactions, but they don't have to worry about their personal information being compromised.
[20:08.720 --> 20:09.620]  Now how would you use this?
[20:09.780 --> 20:13.740]  One of the people have said, well, you know, you still have to keep this information for the DEA.
[20:13.860 --> 20:27.700]  The way I can imagine this working in a real environment is that the local pharmacy would have the local copy of the database in this translucent form, but they would have a clear version that would be stored in a really secure location.
[20:27.940 --> 20:34.280]  So all of a sudden the local pharmacy doesn't have to worry about having an Oracle expert on hand to make sure that it's truly unbreakable.
[20:34.760 --> 20:38.660]  And the local pharmacy doesn't have to worry about someone taking the hard disk.
[20:38.820 --> 20:41.780]  The local pharmacy doesn't have to worry about someone getting root on their machine.
[20:42.020 --> 20:50.160]  But all the information that they need What you need to keep for the DEA is kept in that, you know, Iron Mountain-like environment or vault or something like that.
[20:52.320 --> 20:58.360]  Now, of course, there's the downside to this, which I think in this case is still worth it when I do the calculus in my head.
[20:58.620 --> 21:00.140]  You have forgotten passwords.
[21:00.220 --> 21:01.980]  All of a sudden, you don't have a super user.
[21:02.180 --> 21:04.800]  And so you must be able to withstand lost records.
[21:05.040 --> 21:13.920]  Now my feeling is that, you know, in a case like this, it's not a problem for people to create a new identity for themselves.
[21:14.320 --> 21:21.540]  So when you're hashing up the name, the user name, and your password, if someone comes up with a new password, that in essence creates a new identity.
[21:21.860 --> 21:27.120]  And those two identities won't be linked together, but I think that it's okay to give people the responsibility.
[21:27.460 --> 21:40.500]  I think there'll probably be people who disagree with me on that, but I think, you know, whenever you're architecting these systems, you're forced to make these kind of decisions and trade-offs about usability versus privacy.
[21:40.720 --> 21:42.720]  And in this case, this is how I would choose it.
[21:42.940 --> 21:50.600]  But we'll show you in another... the next example I have is... I think it's even more clear that it's okay to just live with forgotten passwords.
[21:53.280 --> 22:01.880]  This isn't the next example, but it's a kind of... people have said, you know, what do you deal about... there are lots of other problems that people have.
[22:01.980 --> 22:04.520]  Sometimes they type uppercase instead of lowercase.
[22:04.800 --> 22:07.820]  There are other cases where they forget things.
[22:10.540 --> 22:14.540]  There are a lot of different ways you can fix that if you so care, if you want to do that.
[22:14.820 --> 22:23.860]  You can use things like forcing people to only type in uppercase by converting everything uppercase and stripping away the spaces before you hash it.
[22:24.080 --> 22:29.180]  You can use... you can force them to use something like Soundex codes.
[22:29.260 --> 22:33.420]  I don't know if you guys are familiar with it, but a Soundex code is something developed from the 70s.
[22:33.680 --> 22:42.360]  And the idea is that any word... if you have two words that are homonyms, that they sound the same but are spelled differently, they should still come out with the same code.
[22:42.540 --> 22:52.020]  So if you look at the Maryland driver's license, the first four characters are the Soundex code for your name, which in my case is W560.
[22:52.340 --> 23:00.820]  So if you spelled my name with an E-Y-N-E-R instead of an A-Y-N-E-R, both of those versions will come up with the same Soundex code.
[23:00.920 --> 23:08.320]  And I know that there are lots of people in the three-letter agencies that are spending their time coming up with Soundex codes for Arab names.
[23:08.620 --> 23:21.600]  So there are lots of different techniques that are out there for coming up with our kind of canonical forms for words or names or things that deal with forgetfulness or the fact that people spell their name differently or they don't always use the same form.
[23:22.180 --> 23:34.600]  Another solution you can do is that if you have N... let's say you have N fields that identify a person, you can hash together K of all each... every K size subset.
[23:34.800 --> 23:38.700]  So you can choose K of them, of all N, and you can hash them up all independently.
[23:39.040 --> 23:43.420]  So if people get K out of N correct, then you're still going to be able to look them up in the database.
[23:47.400 --> 23:49.320]  OK, there are actually two more examples.
[23:49.520 --> 23:51.320]  So this is the librarian example.
[23:51.560 --> 23:58.300]  So one of the problems that librarians have had is that they keep all these records of what people are reading.
[23:58.300 --> 24:10.100]  And the librarians, I think, naturally want to keep that information private because they're worried about, say, terrorists breaking into the library and blackmailing, say, some of their readers.
[24:12.740 --> 24:23.080]  So I know that librarians are very... they really want to keep the... this is one of the reasons they want to keep everything private and that's why they're fighting for the privacy rights of their readers.
[24:23.300 --> 24:26.700]  So let's say how you could use this with a translucent database.
[24:27.780 --> 24:37.180]  What you could do, you could hash up the title and with a person's password and you would keep the replacement costs in the clear.
[24:37.340 --> 24:39.140]  So when you come to check out, you would give your name.
[24:39.300 --> 24:40.600]  You say, I'm Mary Smith.
[24:41.220 --> 24:46.780]  And the computer would dutifully look at the book and it would say, oh, here's the title or here's the ID number of the book.
[24:46.980 --> 24:52.500]  And it would take your pin and it would hash that and it would store that in the database and it would store the replacement cost.
[24:52.800 --> 24:56.300]  And I probably should put the due date on this because it would make more sense.
[24:56.580 --> 25:02.940]  But if the time comes... so you take the book out and when you return it, you would return it and they would dutifully scan it.
[25:03.000 --> 25:06.200]  They could compute the hash function and then they could remove that line from the database.
[25:06.200 --> 25:13.820]  And if you don't return it after 21 days or whenever it's due, then all of a sudden they would know that you, Mary Smith, owes 1495.
[25:14.300 --> 25:19.440]  And they would done you for it and do whatever librarians do to get the... to rebuild their inventory.
[25:23.200 --> 25:41.400]  And one of the advantages of this is that if you're a terrorist and you want to blackmail Mary Smith, maybe Mary Smith works at a local military base or has access to classified information, then the librarians have prevented that information from going out the door to anyone who breaks into the library system or anyone who is a... you know,
[25:41.460 --> 25:42.800]  maybe steals the hard disk.
[25:42.980 --> 25:46.640]  Because we've had a lot of problems with stolen... you know, just stolen machines.
[25:47.240 --> 25:50.540]  Maybe somebody will keep a copy on their laptop and it would get stolen.
[25:50.760 --> 25:53.220]  This is the way librarians can defend against the terrorists.
[25:53.840 --> 25:55.880]  Let's say you want to make things even more secure.
[25:55.960 --> 25:56.860]  You can turn the crank again.
[25:56.940 --> 26:00.040]  You could start hashing people's names and passwords.
[26:00.580 --> 26:02.360]  Or names and books they take out.
[26:02.520 --> 26:04.260]  So all of a sudden in order to get...
[26:04.710 --> 26:07.840]  there's not even anything recognizable here except the replacement cost.
[26:08.280 --> 26:14.080]  And the downside to doing this or the flip side to do this is you have to take the cash in advance to put it in escrow.
[26:14.200 --> 26:16.340]  Because there's no way you can done the people if they don't return it.
[26:16.620 --> 26:20.440]  But if you want to take out a book, you have to put up $14.95 that goes into escrow.
[26:20.600 --> 26:25.320]  And when you bring the book back, you type in your name and you show them the title and they go, oh, okay.
[26:25.480 --> 26:26.700]  And then they hash both of those.
[26:26.860 --> 26:29.500]  And then they can delete that line and they can give you your cash back.
[26:30.220 --> 26:38.620]  So if you really want to be careful about things, if you want to make sure that there's no information in the database at all, then you can turn the crank that many times.
[26:42.600 --> 26:49.620]  One of the challenges I had was someone was reading my book and he came to me and said, well, you know, this is all interesting.
[26:50.320 --> 26:52.200]  But, you know, why would anyone use this?
[26:52.340 --> 26:59.880]  And someone actually wrote a couple pieces kind of saying, well, this is all nice in an ethereal sense.
[27:00.180 --> 27:01.440]  But is it really practical?
[27:01.640 --> 27:06.260]  And so I've been trying to push the fact that what I'm really doing here is just practical work.
[27:07.020 --> 27:08.860]  And it's practical evangelism.
[27:08.960 --> 27:12.320]  It's not, you know, anything... it's not really that hard to do.
[27:12.980 --> 27:17.120]  And one of the challenges I had with this friend of mine was he said... I said, well, I'll prove it to you.
[27:17.200 --> 27:22.060]  I will show that I can do everything that Amazon could do with a translucent system.
[27:22.280 --> 27:32.440]  So everything that I... and the reason I wanted to do that is because I think Amazon is a good example of a store that goes out of its way to do a great job for their customers and by building these huge dossiers.
[27:32.560 --> 27:34.040]  And I wanted to show that you could do that.
[27:34.420 --> 27:38.660]  And I went through it and I went through, you know, line by line all the features I could imagine that they do.
[27:38.820 --> 27:40.620]  And I could do all of them but one.
[27:41.200 --> 27:48.040]  And so... and the simplest technique is just to use your email and password as a surrogate.
[27:48.720 --> 28:02.560]  And so that, you know, when you show up the next time and it gets your email and your password and you log into the Amazon, they would be able to look up in their databases with a surrogate and then they'd be able to do whatever brilliance they do to suggest the books that you might want to look at.
[28:02.660 --> 28:04.880]  They could customize your page with that surrogate.
[28:07.280 --> 28:11.680]  Now, that takes care of a lot of the different... a lot of the different stuff that Amazon does.
[28:11.780 --> 28:12.980]  But what do you do about your shipping address?
[28:13.120 --> 28:16.840]  One of the nice things about Amazon is you go in there, you don't have to type in your shipping address each time.
[28:16.920 --> 28:18.460]  You don't have to type in your credit card number.
[28:19.780 --> 28:28.460]  My claim is what... the way Amazon should handle that is that they should use a slightly different version of the hash function with a different key or something like that.
[28:28.660 --> 28:30.280]  And you should encrypt your data.
[28:30.580 --> 28:39.020]  So the next time you show up, they can't figure out your address, they can't figure out your credit card number until you log in.
[28:39.280 --> 28:41.460]  And that gives them the ability to decrypt it.
[28:41.840 --> 28:50.480]  And they might keep it around until they ship the package and once that package goes out the door or until they print the shipping label, then the computers can forget the information.
[28:51.040 --> 28:56.240]  And I think that... you know they may not want to forget the information for whatever reasons.
[28:56.420 --> 29:01.920]  But it would be in their best interest to delete the information, because they don't have to worry about it anymore.
[29:02.020 --> 29:03.760]  They don't have to worry about the responsibility.
[29:04.620 --> 29:14.840]  The one feature that Amazon has, and I think it's questionable that it's a feature, is they spam you with suggestions for new books and they charge the publisher for this.
[29:14.960 --> 29:26.400]  So if the publisher comes out with a new If you have a new version of something, they want to advertise it, you can go to Amazon and you can pay $200, $500, and they will spam all the people who bought similar books in the past.
[29:28.400 --> 29:35.780]  So, I couldn't figure out an easy way to duplicate that with the simple systems I've built so far, but perhaps there's a mathematical way out there.
[29:35.920 --> 29:38.740]  So, if you guys are interested in a problem to solve, you might want to attack that one.
[29:39.340 --> 29:41.880]  But, you know, is that really a bug or is it a feature?
[29:44.160 --> 29:46.420]  I want to show you a few more examples.
[29:46.620 --> 29:48.300]  This is another example.
[29:48.700 --> 29:52.160]  This is one of the ones I was pointing to where it doesn't really matter if you have to create a new account.
[29:54.880 --> 30:00.780]  And this came up in a conversation with my wife and her friend, you know, say 1998.
[30:02.440 --> 30:10.940]  And her friend said, wouldn't it be great if you could go to a database or, you know, a website and it would tell you which one of your babysitters are going to be free on Friday night?
[30:11.660 --> 30:14.600]  Because, you know, to her, this was a real hassle.
[30:14.740 --> 30:20.320]  If she wanted to try to get someone for Friday night, she'd call up Chris and maybe Chris would take a day or two to call back.
[30:20.420 --> 30:23.060]  And then Chris would say, no, I can't go because I've got a date.
[30:23.600 --> 30:27.680]  And then, you know, she would call someone else and, you know, maybe it would take a day.
[30:27.800 --> 30:34.760]  There would be all this phone tag in between and she'd waste all this time trying to talk to people who weren't going to be free anyways.
[30:34.760 --> 30:40.740]  So, her ideal website was one that would tell her immediately who was going to be free on Friday night.
[30:42.120 --> 30:47.100]  But there's a real... and, you know, this was 1998 and I was immediately thinking, that is a $100 million idea.
[30:48.360 --> 30:54.800]  And so, I started thinking about it for a while and I realized, but is it really and do I want that responsibility?
[30:55.480 --> 31:03.140]  So, all of a sudden, you're going to have this schedule and your computer, your database is going to be filled with the schedule with all these 15-year-olds.
[31:03.760 --> 31:07.000]  And do you really want to keep track of which parents are going to be out of the house?
[31:07.160 --> 31:08.920]  Do you want this responsibility on your shoulder?
[31:09.060 --> 31:12.180]  And then I realized, well, this would be a good opportunity to kind of test this a little bit more.
[31:12.940 --> 31:14.540]  So, let me try to make this a little bigger.
[31:18.860 --> 31:22.240]  And you can kind of see the tables and then some of them are cut off.
[31:23.060 --> 31:26.180]  And I apologize for not being able to work this JavaScript a little bit better.
[31:28.240 --> 31:38.460]  But this is kind of a simple example of how you might use two tables and you can allow the babysitters and the parents to find each other when the time is right.
[31:40.500 --> 31:43.880]  But the sitter's information is not going to be available to insiders.
[31:43.880 --> 31:45.280]  It's not going to be generally available.
[31:45.420 --> 31:48.880]  And the sitter is going to have control over who sees the schedule for Friday night.
[31:49.400 --> 31:51.000]  So, we have the table on the left.
[31:51.000 --> 31:54.100]  And the table on the left has, you know, three columns.
[31:54.240 --> 31:58.280]  Like, is the person free or busy at a particular date range?
[31:58.440 --> 32:01.160]  You know, start date, end date kind of coding.
[32:02.240 --> 32:08.820]  And the key for that table is the sitter's name and the password hashed together.
[32:09.760 --> 32:12.640]  So, that's the kind of information that the sitter keeps up to date.
[32:12.780 --> 32:16.140]  And the sitter, maybe it syncs with the sitter's palm pilot or whatever you do.
[32:16.660 --> 32:22.240]  And essentially, if the sitter's going to be free and wants to advertise for work, the sitter can put the free slot there.
[32:22.400 --> 32:25.640]  If they want to block out time, they would block it out in that table.
[32:26.120 --> 32:28.580]  Now, how does the sitter control who sees that?
[32:30.160 --> 32:35.760]  And what the sitter controls, this is by saying, well, you know, some parents say, you know, geez, we really liked working with you.
[32:35.920 --> 32:38.120]  You know, we need you, we'd like to be able to see your schedule.
[32:38.340 --> 32:40.320]  And the sitter says, well, what's your password?
[32:41.420 --> 32:45.740]  And then the sitter goes and puts an entry in the table on the right.
[32:45.940 --> 32:48.120]  And this has just got two, this has two columns.
[32:48.120 --> 32:54.100]  The first one is the key to the table on the left, which is the sitter's name and password.
[32:54.400 --> 32:58.620]  And then the second one is the parent's name and the parent's password hashed together.
[32:58.920 --> 33:03.860]  So when the parents come in, the parents will say, they'll go to the website, they'll type in their name, their password.
[33:04.240 --> 33:09.120]  And that will give, then the database will search through the far right column.
[33:09.340 --> 33:14.220]  And it will then link to, you know, they'll be able to link and figure out which sitters they are able to see.
[33:14.320 --> 33:16.360]  And from that information, they'll be able to pull it out.
[33:17.160 --> 33:23.320]  And there are a lot more ways that you can turn the crank with this technology.
[33:23.860 --> 33:29.660]  I've actually built systems that have four or five tables that are all linked together with these hash keys.
[33:29.880 --> 33:34.200]  And as the person types in certain information, it unlocks the other information.
[33:34.400 --> 33:40.040]  So I contend that this is a really nice, elegant solution to a difficult problem.
[33:40.520 --> 33:52.420]  What we've got here is this database that protects the babysitters and protects their schedules from anyone who happens to get root, anyone who's an insider, anyone who happens to break in.
[33:53.120 --> 33:55.500]  And that is a problem in a lot of these places.
[33:56.160 --> 33:59.980]  But it still allows the babysitter to control what information the parent sees.
[34:00.500 --> 34:06.620]  Now, if the babysitter wants to cut someone off, they can take out the entry on the right table.
[34:06.660 --> 34:13.100]  Or the babysitter could just keep a different identity by changing the password, or changing the name, or changing both.
[34:13.100 --> 34:15.520]  All of a sudden, the babysitter can create a different identity.
[34:15.620 --> 34:17.300]  The babysitter could have two or three identities.
[34:17.780 --> 34:20.800]  And the family that the babysitter doesn't like to work with as much,
[34:23.880 --> 34:26.320]  the babysitter might give out a different schedule to.
[34:26.480 --> 34:29.140]  So the babysitter has lots and lots of control with this database.
[34:30.380 --> 34:33.600]  And the people who are the insiders have no control of what's going on.
[34:34.400 --> 34:42.000]  Now, I think this is actually a nice solution in this case, because babysitting is not a particularly lucrative world.
[34:42.440 --> 34:45.720]  And so there is not a lot of money to support a business like this.
[34:45.840 --> 34:55.180]  And this is something I realized, and I think we all realized, that all the $100 million ideas from the late 90s don't necessarily have all this money to support them.
[34:55.580 --> 34:58.680]  But in this case, that makes this solution even more valuable.
[34:58.680 --> 35:08.100]  You're not going to be able to afford all of the highly qualified Oracle sysadmins, the DBs, to maintain your database.
[35:08.240 --> 35:12.880]  You're going to be able to do this with a lot cheaper database, and you're not going to have to worry about keeping things as unbreakable.
[35:18.640 --> 35:23.820]  I'm going to just blip over this a little bit more quickly so we have time for questions.
[35:24.180 --> 35:28.920]  But steganography can create N-tiered databases, and you can read about this if you're curious.
[35:29.520 --> 35:39.960]  One of the thoughts I had is that there are some times where you want a database to reveal a certain amount of information to everybody, but you want more precise information to be revealed to only the select people.
[35:40.460 --> 35:57.240]  And I kind of imagined a world where you had these locations of naval ships, and you wanted to give out kind of coarse information to most people, but you only wanted to give out fine-grained information to people who knew, or people who have a reason to know,
[35:57.400 --> 35:59.260]  because that could be used for targeting.
[36:00.220 --> 36:06.160]  And the coarse information might be useful for planners, or general people, or maybe even to pass it on to family members.
[36:06.260 --> 36:07.240]  So they know that...
[36:07.240 --> 36:14.780]  Because people like to know that their loved one is somewhere in the Persian Gulf, but you don't have to give the exact location, so it could be targeted.
[36:15.840 --> 36:20.540]  And the way I did this is I used just an error vector that was driven by a hash code.
[36:23.760 --> 36:26.040]  You could also use backdoors if you wanted to.
[36:26.200 --> 36:28.080]  Now, I mentioned at the beginning that there...
[36:28.080 --> 36:29.040]  that you...
[36:29.040 --> 36:37.520]  when I was defining one-way functions, that the standard way is to use something like SHA, or these synthetic one-way functions, but you could use a public key cryptography.
[36:38.060 --> 36:47.220]  One of the things you could do is you can use public key cryptography, and when people want to use a hash function, they use the encryption function with public key cryptography.
[36:47.440 --> 36:51.000]  But only a few people have the private key that can use to decrypt stuff.
[36:52.040 --> 36:57.100]  So one of the nice advantages of asymmetric cryptography is that you can share one part of the pair.
[36:58.060 --> 37:03.920]  And this is a little bit computationally more intensive, but it's still, I think, useful.
[37:04.140 --> 37:09.800]  And one of the advantages of this technique is that most of the computation is done at the client.
[37:09.880 --> 37:14.200]  So you don't need as hefty a server farm to maintain this kind of security.
[37:16.000 --> 37:20.520]  Now the downside is that you have to keep a lot more bits, and it's a pain in the neck.
[37:22.560 --> 37:30.540]  The secret sharing, there's a lot of other standard crypto techniques where you can take a secret and you can split it up into four different databases.
[37:31.320 --> 37:36.520]  And all four of the people who control those databases have to agree to release the information.
[37:36.840 --> 37:38.380]  And I think that's pretty well known.
[37:40.600 --> 37:46.620]  Okay, so I think that there's a lot of work that needs to be done right now.
[37:46.700 --> 37:49.720]  And if you're interested in this, these are some directions you might want to go down.
[37:51.740 --> 37:54.000]  Are we really using the best hash functions?
[37:54.360 --> 37:58.320]  And is HMAC one of the best solutions?
[37:58.720 --> 38:03.180]  Are there other ways that we can use these hash functions to produce what I've done here?
[38:04.600 --> 38:06.260]  Can we defend against collisions?
[38:06.500 --> 38:15.680]  If you look at the kind of exciting research that's come out about finding these weaknesses in these one-way functions, what they do is that these people don't break the one-way function completely.
[38:16.180 --> 38:25.120]  They don't come up with an algorithm that allows you to say, if I have f of x, I can always run this computer and I can figure out what x is.
[38:25.320 --> 38:28.920]  What they come up with is this weakness, and what they say is they look for collisions.
[38:28.920 --> 38:33.260]  That is, they find two values, x and y, that hash to the same value.
[38:34.660 --> 38:37.040]  Well, there are ways we can work around that.
[38:37.240 --> 38:49.680]  We can use... we can define the structure of x and the structure of y, which forces them... forces the people who are using these algorithms to... and it kind of breaks them.
[38:49.680 --> 39:04.860]  So, for instance, if you force that... the input to the hash function should always have a structure that's well-defined, and if people find these collisions, they will... may not be... in fact, it's almost certain not to be in that structure.
[39:06.500 --> 39:14.360]  Now, you know, if you're more interested in some of these other things like Raven encryption, you know, it breaks it, but I don't think that... I think that's a little bit over the top.
[39:16.000 --> 39:22.140]  But I think some of the more crucial things that we have to do are social engineering.
[39:23.240 --> 39:36.080]  What we... I think all of us feel this way about data, and I think some people are moving over and changing their opinions of it, but most of the people who work with computers have this kind of pack-rat mentality.
[39:36.760 --> 39:45.360]  If the information... if they see the information coming through their system, they want to put it in their logs, they want to keep that information as long as they can, because you're never sure when you're going to need it again.
[39:45.800 --> 39:56.420]  And so they have huge, you know, collections of backup tapes, and, you know, this is, I think, what drives a lot of the kind of, you know, low-grade, big-brother kind of snooping.
[39:56.680 --> 40:01.960]  And this is that sysadmins like to just poke around, and they like to keep all the information around in case they...
[40:02.940 --> 40:04.080]  in case they could use it again.
[40:04.220 --> 40:13.740]  So when I've given these talks to some, you know, places, there are a lot of people who come up and say, well, you know, we need to help people, or we might need that information in the future, and we have to keep it.
[40:14.740 --> 40:17.680]  And my point is that you don't have to keep it.
[40:17.940 --> 40:19.780]  You can often get by without it.
[40:20.000 --> 40:24.100]  And you'll see that actually lawyers are figuring this out from the beginning.
[40:24.520 --> 40:36.840]  Like a lot of corporations now have these blanket rules, like you're not allowed to keep email after a month, which, you know, are kind of silly in a way, and they're really stupid because there are a few emails that you might want to keep.
[40:37.040 --> 40:40.540]  But the reason they have those blanket prohibitions is because they're worried about subpoenas.
[40:40.540 --> 40:46.060]  They're worried about the cost of going through all their systems and delivering every subpoena that...
[40:46.060 --> 40:48.360]  or every email that fits a particular description.
[40:48.860 --> 40:59.760]  And these subpoenas are just so absolutely broad that it's a real hassle to try to comply with them and give up whatever the court orders.
[41:00.040 --> 41:02.660]  And, you know, many times, I guess, today, you don't even get a subpoena.
[41:02.740 --> 41:04.600]  You're just still ordered to deliver this information.
[41:05.080 --> 41:10.420]  Well, that's why lawyers are into destroying all this information, and I think sysadmins could learn something from the lawyers.
[41:10.680 --> 41:14.500]  They should learn that if you keep the information around, you also have a responsibility to guard it.
[41:14.740 --> 41:19.300]  And if you would just wipe your data more often, you don't have to worry about someone stealing your laptop.
[41:21.100 --> 41:25.400]  And I think businesses still don't see the need, but I think there are more and more lawsuits that are changing that.
[41:26.220 --> 41:39.360]  So, you know, I'm encouraging people to examine these solutions because I think they have good practical uses, and I think we can build this kind of anti-Big Brotherism into these databases, and it's good for many, many situations.
[41:40.000 --> 41:43.040]  And, in fact, there's one group I have that's even using it in a strange way.
[41:43.140 --> 41:44.540]  They're trying to enforce a contract.
[41:45.240 --> 41:52.280]  I guess there's these two companies, and one of them has the data, and the other one wants to license the data and pay them only a small amount of monthly fee.
[41:52.480 --> 42:00.460]  And the first one is worried that the second one is somehow going to cache the data, and they're worried that it would be abused in the future, and eventually they wouldn't need the first one anymore.
[42:00.920 --> 42:03.800]  So they're using a translucent solution to fix that.
[42:04.880 --> 42:10.500]  But I think, overall, the main point of this talk is that we can build these systems.
[42:10.500 --> 42:21.580]  We can keep information locked up in a way that only the right users can get at it, and all of the casual users, the insiders, the snoops, the people who get root can't get it.
[42:21.640 --> 42:23.700]  And this is an ideal solution for many people.
[42:24.620 --> 42:27.100]  So if anyone has questions, I'm happy to take them.
[42:36.260 --> 42:37.680]  That was a great presentation.
[42:37.680 --> 42:38.720]  I appreciate that.
[42:41.620 --> 42:50.600]  From what I've noticed, like, you know, if you have a charge on your credit card that is not one of your charges, the bank will cover you on that, and, you know, they'll take care of it, right?
[42:50.720 --> 42:55.980]  But if they lose your information, and you suffer from identity theft, that's not really their problem.
[42:56.200 --> 42:57.240]  That's your problem, right?
[42:58.440 --> 43:02.360]  So, I mean, unless it's a massive cache of data, which is stolen.
[43:03.300 --> 43:03.740]  Right, yeah.
[43:03.740 --> 43:12.120]  So, I mean, it's not really viable for businesses to spend a lot of money on security when it's an exposure that they don't really have to pay for.
[43:13.060 --> 43:14.160]  So how do you feel about that?
[43:14.240 --> 43:20.120]  And the other question is, like, I noticed, I think your presentation at the Fifth HOPE was pretty similar type of concept.
[43:20.800 --> 43:23.200]  And what have you seen change, like, since the Fifth HOPE?
[43:24.060 --> 43:26.200]  Okay, so let's do the first one, and then the second.
[43:26.660 --> 43:32.640]  The first one is, I mean, you're absolutely right that businesses don't have, don't feel the pressure.
[43:32.780 --> 43:37.700]  And that's partially because if information leaks out, most of the time you don't know where it came from.
[43:37.920 --> 43:48.180]  And, yeah, we hear these kind of high-profile kind of discussions, and they say, oh, some laptop with all the information from the VFW leaked out.
[43:48.460 --> 43:52.460]  But that doesn't necessarily mean that it was used in a bad way, and it could be someone...
[43:52.460 --> 43:55.980]  if someone's identity is stolen, it could have been some other leak that caused it.
[43:56.140 --> 43:58.020]  So there's not a really good cause and effect.
[43:58.420 --> 44:02.520]  And his point, I think, is quite correct, is that the businesses don't feel the heat.
[44:03.320 --> 44:13.120]  Now, I think they should feel the heat, and I think part of the reason that these disclosure laws from California are good is because it forces them to at least think of the consequences of protecting their data.
[44:13.300 --> 44:17.180]  And if they feel that way, I think they can use this solution.
[44:20.360 --> 44:21.500]  So on to the second one.
[44:21.560 --> 44:25.400]  He pointed out that I gave pretty close to the same talk a couple of years ago.
[44:25.600 --> 44:30.840]  And I think that's because the people who are organizing this like the topic, and they asked me to give it again.
[44:32.180 --> 44:33.620]  What's changed since then?
[44:35.760 --> 44:39.040]  I find that there's more and more interest about this.
[44:39.040 --> 44:47.920]  And for instance, I get more invitations to give this talk than I did two years ago.
[44:48.160 --> 44:52.120]  The mathematics I put in here is not any different.
[44:52.360 --> 44:55.360]  I do know that there is some interesting work that's going on.
[44:55.480 --> 44:57.360]  For instance, if you're into...
[45:01.880 --> 45:03.860]  I guess transitive encryption.
[45:04.160 --> 45:05.740]  There's some encryption where...
[45:05.740 --> 45:13.860]  Some encryption functions where if you encrypt with key A before key B, you end up with the same result as if you encrypt with key B before key A.
[45:14.320 --> 45:19.160]  And those kind of solutions are very useful in this environment.
[45:19.160 --> 45:20.860]  And I'm curious about them.
[45:20.940 --> 45:24.500]  There are people at CMU who are doing research in this and a few other places.
[45:24.580 --> 45:28.620]  And I can send you pointers to their research if you give me your card and talk to me afterwards.
[45:28.980 --> 45:32.480]  But it just seemed a little bit too confusing to put into the talk right now.
[45:33.040 --> 45:34.440]  So I haven't done that.
[45:34.640 --> 45:39.020]  But that to me is what I'm most excited about is when you're using those kind of encryption functions that way.
[45:39.100 --> 45:42.520]  Because all of a sudden, people don't have to do things in the same order.
[45:42.660 --> 45:46.640]  And there are a lot of interesting algorithms for, say, dealing cards or playing poker online.
[45:46.920 --> 45:52.300]  And that you could also do interesting privacy things with those kind of encryption functions.
[45:55.970 --> 46:01.170]  Google now offers spreadsheets that can be shared.
[46:02.210 --> 46:03.610]  What would be the risk?
[46:03.930 --> 46:07.810]  And what would be, you know, using or sharing information?
[46:08.750 --> 46:11.890]  You know, how easy would it be to work with something like that?
[46:12.230 --> 46:17.990]  Well, I think if Google wanted to, Google could put a password on the spreadsheet data.
[46:18.330 --> 46:19.790]  And I don't know if they have.
[46:19.930 --> 46:24.090]  I mean, certainly the people there are all talented enough to do this if they want to or if they have the time.
[46:25.630 --> 46:34.950]  But there's no reason why that sharing can't be done in this kind of translucent way where the data that's stored at Google is useless to anyone who doesn't have that password.
[46:35.190 --> 46:38.010]  And that would just be a simple, straightforward use of encryption.
[46:38.330 --> 46:40.550]  But I think it would be a nice use in this case.
[46:40.970 --> 46:43.410]  And I don't know if Google cares enough to do that.
[46:43.410 --> 46:47.970]  You often get these kind of, you always get these nice platitudes about not being evil.
[46:48.170 --> 46:54.770]  But when you read through their privacy rules, you know, it's pretty clear that their feeling is that you can do whatever they want with your data.
[46:56.670 --> 46:58.210]  And I'll tell you a story.
[46:59.230 --> 47:04.270]  A friend of mine works at Google and he, I sometimes tell, I send complaints his way.
[47:04.590 --> 47:10.410]  You know, he seems to like it because he responds immediately and he says, oh, well, we'll try to fix that bug or whatever.
[47:10.410 --> 47:14.130]  And he seems to care when I send him this stuff.
[47:14.210 --> 47:14.630]  So it's good.
[47:14.990 --> 47:17.130]  And there was one time I was looking for an email.
[47:18.170 --> 47:21.230]  And I forwarded a lot of my email to a Gmail account there.
[47:21.370 --> 47:22.530]  And I couldn't find it.
[47:22.630 --> 47:26.530]  And usually Google's been the better source for me looking up back emails.
[47:27.090 --> 47:28.370]  And it just wasn't there.
[47:28.850 --> 47:31.130]  And so then finally I found it on my hard disk.
[47:31.270 --> 47:32.570]  And I found another copy of it.
[47:33.130 --> 47:43.210]  And no matter what I did, I couldn't find it in my Gmail, which really surprised me because it's clear that they want to keep track of, you know, they want to be the central file for all your email.
[47:44.050 --> 47:45.930]  So I wrote him a complaint note.
[47:46.070 --> 47:47.390]  And he goes, well, tell me more information.
[47:47.590 --> 47:52.050]  So I sent him the message ID, which is a perfect identifier.
[47:52.650 --> 47:59.110]  And within a half hour I got an email back saying, oh, that was deleted because it was classified as spam.
[47:59.110 --> 48:01.230]  And so it only stayed in the system for 30 days.
[48:02.650 --> 48:08.110]  So, you know, even though they're keeping log files of all this stuff.
[48:08.310 --> 48:18.150]  And even though I don't know where that email is, even though it looks like it's gone to me, they know when it was deleted, what time it was deleted, and where and, you know, why it was deleted.
[48:18.350 --> 48:20.610]  And so, you know, who knows what's going on.
[48:20.710 --> 48:29.890]  But I would encourage them to use more systems like this, if anything, just because I think it would be better for all of the users to push this kind of control to the edges.
[48:32.970 --> 48:36.070]  There are certain places where it's been legislated.
[48:36.710 --> 48:41.810]  Privacy and health care is a tremendous place where this technology would really fit in.
[48:42.470 --> 48:44.850]  Banks might not care or Amazon might not care.
[48:45.170 --> 48:58.150]  But with the HIPAA regulations, there's an awful lot of people that have access to specific medical information about what you had done that don't need to know your name and all that other stuff for statistics.
[48:58.410 --> 49:01.030]  So there's really, I think, a lot of applications for this.
[49:01.370 --> 49:02.610]  I think...
[49:02.610 --> 49:06.210]  And legal now, you know, all the privacy in litigation.
[49:06.910 --> 49:12.830]  See, the medical stuff's kind of interesting when I deal with it, because I've talked to this a lot of people, and it's not so cut and dried.
[49:12.990 --> 49:18.050]  I mean, obviously, you're right, that the principle would be wonderful in many cases because you want to protect this stuff.
[49:18.270 --> 49:29.430]  But the one objection I can't really deal with is, they say, well, what if you come in and you're in a coma, or, you know, you're knocked out or, you know, you're in an ambulance and they don't have that data.
[49:29.810 --> 49:34.370]  So, you know, you can't reveal your PIN number or your password, and so that's a problem.
[49:36.210 --> 49:38.810]  And they often say things like, you know, I want...
[49:38.810 --> 49:40.370]  The doctors want the data right away.
[49:40.490 --> 49:42.750]  They don't want to wait, you know, a half hour or whatever.
[49:42.810 --> 49:45.390]  But then you get into your tiered levels of information.
[49:45.610 --> 49:55.190]  There are so many people that access details of a hospital stay that you had five years ago for statistics, for revenue recovery, for a million different things.
[49:55.310 --> 49:58.690]  And there's just... I mean, that's... I know because I work in that, but that would be terrific.
[49:59.030 --> 49:59.710]  I think so.
[49:59.830 --> 50:02.230]  And there are a lot of people who have done a lot of neat research on this.
[50:02.330 --> 50:07.710]  I know, for instance, that there's these rules about releasing medical study information that are kind of neat.
[50:07.830 --> 50:11.910]  They have kind of principles like the data you release about a person can't...
[50:12.470 --> 50:14.310]  It has to be...
[50:15.630 --> 50:16.070]  When...
[50:16.070 --> 50:17.190]  It's going to define a set.
[50:17.370 --> 50:18.130]  And that's the size...
[50:18.130 --> 50:20.870]  The number of people in that set has to be greater than five or ten.
[50:21.270 --> 50:23.790]  So if you give, say, the street number...
[50:23.790 --> 50:24.730]  You can't get...
[50:24.730 --> 50:34.030]  If you give the street number in the street, you can do something like that in New York City because there are going to be maybe a thousand people who live at, you know, 800 and...
[50:34.030 --> 50:35.630]  Or 1313 Mockingbird Lane.
[50:35.990 --> 50:43.010]  But if you go out into the countryside, and, you know, there may only be five people who are living on an entire street.
[50:43.030 --> 50:46.510]  So you can't even keep the street name, much less the number in the database.
[50:46.790 --> 50:48.090]  And so it's kind of an interesting principle.
[50:51.540 --> 50:52.720]  Are there any more questions?
[50:56.620 --> 50:56.980]  Okay.
[50:57.060 --> 50:58.320]  Well, I really enjoy being here at HOPE.
[50:58.440 --> 51:00.400]  I always enjoy the spirit of the...
[51:00.400 --> 51:01.340]  Everyone who's in the audience.
[51:01.540 --> 51:04.780]  Please talk to me afterwards if you have something you want to talk about offline.