DAVID MALAN: This is CS50.

Hello, world.

This is the CS50 podcast my name is David Malan,

and this is Episode Zero, our very first,

and I'm joined here by CS50's own Colt--

COLTON OGDEN: Yep.

[LAUGHTER]

Colton Odgen. This is an interesting new direction that we're going.

DAVID MALAN: Yeah, it's one in which we clearly haven't rehearsed.

COLTON OGDEN: Yeah.

DAVID MALAN: So, but what we thought we'd do with the CS50 podcast is really

focus on the week's current events as it relates to technology,

use this as an opportunity to talk about the implications

of various technologies, and really explain things as it comes up,

but really in a non-visual way.

And so, perhaps, I think the topics Colton

and I'll hit on here will focus on things you, yourself, might have read

in the news that maybe didn't register necessarily

or maybe you didn't really understand how it pertains to technologies

that you, yourself, use.

COLTON OGDEN: Yeah, and I think that's ties as well to prior, when

we did CS50 live, and this was kind of the same idea.

DAVID MALAN: Yeah, absolutely.

Whereas CS50 Live, when we did it on video, was much more visual--

we prepared slides, we actually looked at sample videos and such--

here, we thought we'd really try to focus on ideas.

And it'll be up to you to decide if this works well or not well,

but we come prepared with a look at some of the past week's news.

And why don't we get right into it?

COLTON OGDEN: Yeah, absolutely.

One of the things I noticed, actually, is--

I put together this list of topics, but the one thing

that I didn't put in here that you actually found and put in here,

today, was something about Facebook passwords.

DAVID MALAN: Yeah, so a website named Krebs on Security, the author of this,

was contacted apparently by some employee-- presumably

and a current employee of Facebook-- who revealed

to him that during some recent audit of their security processes,

they discovered that for like seven years,

since 2012, had one or more processes inside of Facebook

been storing passwords-- users' passwords, like yours and mine

potentially, in the clear, so to speak, clear text, not

cipher text, which means unencrypted-- in some database or some file

somewhere.

COLTON OGDEN: Typically, people will use some sort

of hashing algorithm to store things cryptographically and much more

securely?

DAVID MALAN: Indeed, even like ROT13, like rotate every character 13 places,

would have been arguably more secure.

And there's not a huge amount of technical detail out there.

If you go to krebsonsecurity.com, you can actually

dig up the blog post itself.

And then Facebook actually did respond, and I

think there's a link in Krebs on Security to the Facebook announcement.

But to be honest, the Facebook announcement which is

on newsroom.fb.com, pretty, to be honest,

it's pretty nondescript and really doesn't--

I mean, it's kind of disingenuous.

They seem to use this as an opportunity to talk about best practices

when it comes to passwords and all of the various other mechanisms

that they have in place to help you secure your password.

And yet, they really kind of didn't address the topic

at hand, which is, well, despite all of those mechanisms,

you were storing our passwords in the clear, or at least

millions of Facebook users, particularly on Facebook Light,

lighter-weight version of the app that's useful in low bandwidth locations

or where bandwidth is very expensive or slow.

COLTON OGDEN: So this strikes you sort of as an opportunity for them to,

what, hand wave over the issue and sort of distract people?

Is that sort of how it-- this rubs you?

DAVID MALAN: Yeah, maybe.

I think they, you know, acknowledged the issue,

but then used this as an opportunity to emphasize all

of the things that are being done well.

And that's fine, but I think the world is done a disservice

when companies aren't just candid with their mea culpas

and what they got wrong.

I think there's learning opportunities and, as I read this,

there's really little for me as a technical person

or as an aspiring program to really learn from,

other than the high order bit which is, encrypt your passwords.

But how did this happen?

What are the processes that failed?

I mean if companies like Facebook can't get this right,

how can little old me, an aspiring programmer,

get these kinds of details right?

I wonder.

COLTON OGDEN: So an article more about how they failed

and how they could address it, and how other companies could address it,

you think that would've been more productive?

DAVID MALAN: I think so.

I mean, postmortems, as they're called in many contexts, including in tech,

and I've always really admired companies that when they do

have some significant mistake or human error, where they own up to it

and they explain in technical terms exactly what went wrong.

They can still have a more layman's explanation

of the problem too, where most people might only take

an interest in that level of detail.

But for the technophiles and for the students

and the aspiring technophiles out there, I think it's just appreciated.

And these are such teachable moments and all

that-- but I would respect the persons, the company all the more

if they really just explained what it is they failed so that we can all learn

from it and not repeat those mistakes.

COLTON OGDEN: If a large company like Facebook is doing something like this,

how prevalent do you think this practice is in the real world?

DAVID MALAN: Yeah.

Oh my God.

I mean, probably frighteningly common, and it's

just if you have fewer users or fewer eyes on the company,

you probably just notice these things less frequently.

But I do think things are changing.

I mean with laws like GDPR in the EU, the European Union,

I think there's increased pressure on companies now, increased

legal pressure, on them to disclose when these kinds of things happen,

to impose penalties when it does, to therefore

discourage this from even happening.

And you know, I'm wondering why this audit detected this in 2019, and not

in 2012 or 2013 or 2014 and so forth.

COLTON OGDEN: GDPR, did that happened back in 2012?

Oh no, that was--

DAVID MALAN: No, this was recent.

COLTON OGDEN: That one Came onto force--

OK.

DAVID MALAN: Recent months, actually, has this been rolled out.

COLTON OGDEN: Was this-- is this related at all

to the proliferation, now, of cookie messages that you see on websites?

DAVID MALAN: That's US-specific, where I believe it's now being enforced.

Because that actually has been around for quite some time in Europe.

Anytime you took your laptop abroad, for instance,

would you notice that almost every darn site asks you,

hey, can we store cookies.

And honestly, that's a very annoying and almost silly manifestation of it

because the reality is, as you know, I mean

the web doesn't work without cookies or at least

dynamic applications don't work.

And anyone who's taken CS50 or who's and a bit of web programming,

really, in any language, know that the only way

to maintain state in most HTTP-based applications is with cookies.

So, I mean, we've created a culture where people just

dismiss yet another message, and I don't think that's a net positive either.

COLTON OGDEN: I think I see a lot, too, of the messages that say,

by continuing to use this site, you acknowledge

that we have access to whatever information, using cookies, and so on.

So I almost think that they do it already and sort of legally

can get away with it by having this message visible.

DAVID MALAN: Yeah, I mean, it's like cigarette ads

which, abroad, as well, there was--

before the US, there was much more of, I presume,

law around having to have very scary warnings on packages.

And companies somewhat cleverly, but somewhat tragically, kind of

steered into that and really owned that and put the scariest of messages.

And it-- you almost become desensitized to it because it's just so silly

and it's so over the top, you know, smoking kills.

And then, here's the price tag and here's the brand name.

Like, you start to look past those kinds of details too,

so I'm not sure even that is all that effective.

But someone who's looked at this and studied it

can perhaps attest quantitatively just how effective it's been.

COLTON OGDEN: Yeah, indeed.

Well, scary to know that our passwords may

have been reflected visibly on somebody's server,

a big website like Facebook.

Related to that, another of the topics that I sort of dug into a little bit

yesterday-- or not yesterday, a few days ago,

was Gmail Confidential Mode, a new feature

that they're starting to roll out.

DAVID MALAN: Yeah.

Yeah, I saw that, just in March, one of the articles on Google's blog

discussed this.

What, so do you understand what the--

what they're offering now as a service?

COLTON OGDEN: I have to reread back through the article.

So from what I understood, though, it was encrypting not P2P emails,

but encrypting the emails sort of towards a sort of proxy,

towards a center point, and then forwarding

that encrypted email to the other person on the receiving end.

But I remember reading in the article that P2P encryption wasn't something

that they were actually going to start implementing just yet.

DAVID MALAN: Yeah, and this is--

I mean, this is kind of the illusion of security or confidentiality.

In fact, I was just reading, after you sent me

this link on the EFF's website, the Electronic Frontier Foundation who

are really very progressively-minded, security-conscious, privacy-conscious

individuals as a group, they noted how this really isn't confidential.

Google, of course, still has access to the plain text of your email.

They don't claim to be encrypting it Peer-to-Peer,

so they're not being disingenuous.

But I think they, too, are sort of creating and implying

a property, confidentiality, that isn't really there.

And what this does, for those unfamiliar,

is when you send an email in Gmail, if you or your company

enables this feature--

I think it might still be in beta mode or in trial mode.

COLTON OGDEN: I don't think it's officially fully deployed yet,

but yeah, [INAUDIBLE].

DAVID MALAN: Yeah, so you can opt into it if you have a corporate account,

for instance.

It gives you an additional, like, Lock icon on the Compose window

for an email, where you can say that this message expires, sort of James

Bond style, after some number of hours.

You can add an SMS code to it so the human who is receiving it

has to type in a code that they get on their cell phone.

And so it also prevents users from forwarding it, for instance,

therefore accidentally or intentionally sending it to someone else.

But there's the fundamental issue because you

start to condition people, potentially, into thinking,

oh, this is confidential.

No one can see the message that I'm sending or that I've received.

And that's just baloney, right?

And you or I could take out our cell phone, right

now and not screenshot, but photograph anything on our screen.

You could certainly highlight and Copy-Paste it into some other email.

And so I think these kinds of features are dangerous if users don't really

understand what's going on.

And honestly, this is going to be a perfect topic

in CS50 itself or CS50 for MBAs or for JDs at Harvard's graduate schools.

Because if you really push on this, what does confidential mean?

Well, not really much.

You're just kind of-- it's more of a social contract between two people.

Like, OK, OK, I won't forward this.

It's just raising the bar.

It's not stopping anything.

COLTON OGDEN: Part of this kind of reminds me, too, of the point

you like to mention in most of the courses