[MUSIC PLAYING]
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
that you teach in that security doesn't really mean much just by virtue
of seeing something.
Somebody sees a padlock icon in their browser in, let's say,
bankofamerica.com, that doesn't necessarily mean
that anything that they see is secure.
DAVID MALAN: Yeah, well that too.
I mean, there too, we humans learned, years ago, well maybe we
shouldn't be putting padlocks in places that
have no technical meaning for exactly that reason.
People just assume it means something that it doesn't, so we seem doomed,
as humans, to repeat these mistakes.
And this isn't to say that I think this is a bad feature.
Frankly, I wish that I could somehow signal to recipients of emails
I send, sometimes, please don't forward this to someone else
because it's not going to reflect well or it's going to sound overly harsh
or whatever the email is.
You sometimes don't want other people to see it,
even if it's not the end of the world if they actually do.
But short of writing in all caps, like, do not forward this email,
at the very start of your message, most people might not realize.
So I think having a software mechanism that says
don't, not forwardable, isn't bad.
But, you know, it should probably be like, please don't forward, and not
imply that this is confidential and no one else is going to see it.
COLTON OGDEN: Do you think that there is some sort of risk involved
in making these emails self-destructive, in as much as maybe
it will bite people sort of in the future when maybe they
want to look back on records that are important like this?
DAVID MALAN: Could be.
I mean, there too, I suspect there are business motivations for this,
for retention policies, where there might be laws or policies in place
where companies do or don't want to keep information around
because it can come back to bite them.
And so maybe it's a good thing if emails do expire after some amount of time,
so long as that's within the letter of the law.
But I presume it's motivated, in part, by that.
So this is a software technique that helps with that.
And so, in that sense, you know, confidential
does have that kind of meaning, but it's not secure
and I worry that you put a padlock on it-- that doesn't necessarily
mean to people what you think.
I mean, so many people, and kids especially,
might think or once thought that Snapchat messages are indeed ephemeral
and they'll disappear.
But ah, I mean, they're still on the servers.
COLTON OGDEN: Undoubtedly.
DAVID MALAN: They can be on the servers.
You can snap-- screenshot them or record them with another device.
So I think we do humans a disservice if we're not really upfront as
to what a feature means and how it works, and I
think we should label things appropriately so as to not oversell
them.
COLTON OGDEN: And it sort of takes unfortunate advantage
of those who are not as technically literate as well, allowing
them to sort of-- or at least capitalizing
on people taking for granted these things that they assume to be true.
DAVID MALAN: Yeah.
I mean, we've been doing this, honestly, as humans,
for like, what, 20, 30 years with DOS.
You might recall that when you format a hard drive, which generally means to--
kind of means to erase it and prepare it to have something new installed
on it, the command, back then, when you used to delete it or fdisk it
or whatever it was, was are you sure you want to proceed?
This will erase the entire disk, something like that,
and I think it actually was in all caps.
But it was false, technically.
Right?
All it would do is rewrite part of the headers on disk,
but it would leave all of your zeros and ones from previous files
there in place.
And there, too, we said it would delete or erase information, but it doesn't.
And so, for years maybe to this day, do people
assume that when you delete something from your Mac or PC
or empty the Recycle Bin or whatnot, that it's gone?
But anyone who's taken CS50 knows that's not the case.
I mean, we have students recover data in their forensics homework alone.
COLTON OGDEN: You have a background, certainly, in this too.
You did this for a few years.
DAVID MALAN: Yeah, or a couple, a year or two.
Yeah, yeah, in graduate school.
COLTON OGDEN: If you were to advise our listeners on the best way
to sort of format their hard drive and avoid this fallacy,
what would be your suggestion?
DAVID MALAN: Drop it in a volcano.
[LAUGHTER]
COLTON OGDEN: So then, are you insinuating
that there is no truly safe way to clean a hard drive?
DAVID MALAN: No, no.
Well, in software, it's risky.
COLTON OGDEN: In software.
DAVID MALAN: I think if you really want peace of mind
because you have personal documents, financial documents, family documents,
whatever it is that you want to destroy, physical destruction is probably
the most safe.
And there are companies that allow you to physically destroy hard drives.
They drill holes in it or they crush it or whatnot,
or you can take out a hammer and try to break through the device.
But it's difficult, as we've seen in class when
we've disassembled things, you and I, for CS50's Introduction to Technology
class.
It's hard just to get the damn screws open.
So that's the most robust way, is physical destruction.
You can wipe the disk in software.
Frankly, it tends not to be terribly easy.
It's easier with mechanical drives, hard disk drives that spin around.
But with SSDs, the Solid State Drives that are purely electronic these days,
it's even harder.
Because those things, in a nutshell, are designed
to only have certain parts of them written to a finite number of times.
And eventually, the hard drive, after a certain number of writes
or after a certain amount of time, will stop using certain parts of the disks.
And that does mean you have a slightly less space available, potentially,
but it ensures that your data's still intact.
That means that even if you try to overwrite that data,
it's never going to get written to because the device isn't
going to write to it anymore.
COLTON OGDEN: Oh, I see.
It closes off certain sectors--
DAVID MALAN: Exactly.
COLTON OGDEN: --that might have data written in.
That's interesting.
I didn't know that.
DAVID MALAN: So you're better off just destroying that disk, at that point,
too.
So it's wasteful unfortunately, financially,
but if you want true peace of mind, you shouldn't just wipe it with software.
You shouldn't hand it off to someone and assume that Best Buy
or whatever company is doing it for you is going to do it properly as well.
You should probably just remove the device if you can,
destroy it, and sell the rest of the equipment.
COLTON OGDEN: I think this is reflected too,
in Mr. Robot, where he microwaves an SD card that he
trusts I'll get off of his--
DAVID MALAN: Did he?
I Don't know if I saw that episode, then.
COLTON OGDEN: This was, I think, the second episode.
DAVID MALAN: That's probably not the right way to do it.
That's probably just very dangerous.
COLTON OGDEN: That's probably very-- yeah, I think it exploded in the video,
but yeah.
DAVID MALAN: You don't put metal thing-- for our CS50 listeners
out there, don't put metal things in microwaves.
COLTON OGDEN: Yeah, generally not advisable.
DAVID MALAN: No, I think never advisable.
[LAUGHTER]
COLTON OGDEN: Yeah, so off of the-- well,
I guess sort of related to the topic of security,
there was an article recently published on Gizmodo
about how the FCC admitted in court that it can't track who
submits fake comments to its database.
DAVID MALAN: Yeah, I was reading that.
And as best I could tell, it sounded like they had a web-based form
to solicit feedback on, what was it, net neutrality or some topic like that,
and they claimed that they couldn't trace
who it was because apparently there were millions of bogus comments generated
by script kiddies or just adversaries who wrote programs
to just submit comments again and again and again and again.
And as best I could infer, it sounds like they
were weren't logging, maybe, who they were coming from,
maybe it's IP address.
It sounded like maybe they didn't even have a CAPTCHA in place
to sort of force a presumed human to answer some challenge like a math
problem or what is this blurry text or click
all of the icons that have crosswalks in them or something like that.
COLTON OGDEN: Right.
DAVID MALAN: And so they just don't have much metadata,
it seemed, about who the users were.
So short of looking at the text that was submitted alone,
it sounds like they can't necessarily filter things out.
It's a little strange to me because it sounded
like they do have IP addresses, at least in the article that I read,
and the FCC doesn't want to release that for reasons of privacy.
But you could certainly filter out a good amount of the traffic,
probably, if it all seems to be coming from the same IP.
I'm guessing many of the adversaries weren't as thoughtful
as to use hundreds or thousands of different IPs,
so that's a little curious too.
COLTON OGDEN: Is it all related to onion routing?
And this is more of my sort of lack of knowledge of Tor and onion
routing, but is this sort of how onion routing works in that you can
spoof your IP from a million locations?
DAVID MALAN: Not even spoof your IP.
You just really send the data through an anonymized network such
that it appears to be--
that it is coming from someone else that's not you.
So yeah, that's an option.
I've not used that kind of software in years
or looked very closely at how it's advanced, but that's the general idea.
Like, you just get together with a large enough group of other people
who you presumably don't know, so n is large, so to speak,
and all these computers are running the same software.
And even though you might originate a message in email or form submission,
that information gets routed through n minus 1 other people, or some subset
thereof, so that you're kind of covering your tracks.
It's like in the movies, right, when they show a map of the world
and like the bad guys' data is going from here to here to here
and a red line is bouncing all over the world.
That's pretty silly, but it's actually that kind of idea.
You just don't have software that visualizes it.
COLTON OGDEN: And that's why it looks-- that's why they call it onion routing,
because it's like layers of an onion, kind of going all around?
DAVID MALAN: Oh is it?
I never thought about it.
COLTON OGDEN: I thought that that was why it was called onion routing.
DAVID MALAN: Maybe.
That sounds pretty compelling.
So sure, yes.
COLTON OGDEN: They apparently, per the article,
the API logs contain dozens of IP addresses
that belong to groups that uploaded millions of comments combined.
So to your point, it does sound like that indeed is what happened.
DAVID MALAN: Oh, so that's presumably how they know minimally
that there were bogus comments?
COLTON OGDEN: Yeah.
DAVID MALAN: And but hard to distinguish maybe
some of the signal from the noise.
COLTON OGDEN: Folks concerns were that people
were sort of creating these bogus comments that
were propaganda, essentially malicious-- maliciously-oriented comments.
DAVID MALAN: Yeah, well this is pretty stupid then,
sounding then because, honestly, there are
so many like available APIs via which you can at least raise
the barrier to adversaries.
Right, using CAPTCHAs so that, theoretically, you
can't just write a program to answer those kinds of challenge questions;
a human actually has to do it.
So you might get bogus submissions, but hopefully not thousands or millions
of them.
COLTON OGDEN: Yeah.
No, it sounded more like a technical--
I might not want to--
I don't want to stretch my words here-- but it
sounded like there was a little bit of potential technical illiteracy involved
at least in this.
DAVID MALAN: Could be.
COLTON OGDEN: Potentially.
DAVID MALAN: It could be.
COLTON OGDEN: I want to try to sound as diplomatic as possible.
DAVID MALAN: Good thing they're making all these decisions around technology.
COLTON OGDEN: Ah, yeah, exactly.
Right?
And I have a picture--
OK, I'm not going to go in that direction, but--
DAVID MALAN: I don't think we can show pictures on this podcast, though.
COLTON OGDEN: Another topic sort of related
to this was-- and John Oliver sort of did
a skit on this related to robocalls-- is, well, robocalls.
For those that-- do you want to maybe explain
what robocalls are for our audience?
DAVID MALAN: Yeah.
I mean, a robocall is like a call from a robot, so to speak.
Really, a piece of software that's pretending to dial the phone,
but is doing it all programmatically through software.
And it's usually because they want to sell you something or it's
an advertisement or it's a survey or they
want to trick you into giving your social security number
or that you owe taxes.
I mean, they can be used for any number of things and, sometimes, good things.
You might get a reminder from a robocall from like an airline saying hey,
your flight has been delayed an hour.
That's useful, and you might invite that.
But robocalls have a bad rap because they're often unsolicited
and because I have not signed up for someone to call me.
And indeed, these have been increasing in frequency for me
too, on my cell phone in particular, which theoretically is unlisted.
And I added the Do Not Track thing, years ago,
but that's really just the honor system.
You don't have to honor people who are on those lists.
COLTON OGDEN: They just supposedly have to check the list, right,
but they can still call you afterwards?
DAVID MALAN: Yeah, and I mean certainly if the problem is with bad actors,
then, by definition, those people aren't respecting these lists
in the first place.
So it's the good people who you might want to hear from who you're not
because they are honoring the Do Not Call lists.
COLTON OGDEN: I've noticed that I've received a great many as well.
Most of them from--
DAVID MALAN: Oh, yeah, sorry about those.
COLTON OGDEN: Most of them from 949, which is where I grew up in California,
and that's where the bulk of all the messages are coming from.
DAVID MALAN: But well, per-- seem to be coming from.
I've noticed this too.
I get them from 617, which is Boston's area code, too.
They're doing that on purpose.
I just read this, and it makes perfect sense, now,
in retrospect why I keep seeing the same prefix in these numbers.
because they're trying to trick you and me
into thinking that, oh, this is from a neighbor or someone
I know in my locality.
No it's just another obnoxious technique, to be honest.
COLTON OGDEN: I live in Massachusetts now,
so I know that it's not a neighbor, definitely, if they're 949.
DAVID MALAN: Yeah.
COLTON OGDEN: Likely.
DAVID MALAN: Well, the thing is, I don't know anyone's number, now.
So if I don't, it's not in my contacts, I know it's probably a robocall.
So no, it's really awful and, I mean, I think
one of the primary reasons this is becoming even more of a problem
is that making calls is so darn cheap.
I mean, you and I have experimented with Twilio,
which is a nice service that has, I think, a free tier but a paid tier
too where you can automate phone calls, hopefully for good purposes.
And I was just reading on their website that they actually
deliberately, though this certainly is a business advantage for them
too, charge minimally by the minute, not by the second,
because they want to charge even potential adversaries at least
60 seconds for the call.
Though, of course, this means that if you and I are
writing an app that just needs a few seconds of airtime,
we're overpaying for it.
But it's a hard problem because calls are just so cheap.
And this is why spam has so proliferated, right?
Because it's close to zero cents to even send a bogus email, these days.
And so those two are dominating the internet, too.
And thankfully, companies like Google have
been pretty good at filtering it out.
You know, we don't really have a middleman filtering out our phone
calls, and it's unclear if you'd want a middleman-- software
picking up the phone figuring out if it's is legit
and then connecting them to you.
COLTON OGDEN: Right.
DAVID MALAN: It feels a little invasive and a time-consuming, too.
COLTON OGDEN: And it's kind of alarming just
how easy it is for your average person, your average beginning programmer
to set up an automated robocall system.
This was illustrated, and again, back to the John Oliver segment,
this was illustrated on there where they had literally had--
they were showing a clip of somebody who wrote a little command line script
or something like that.
And even John Oliver made light of it in this skit
where he said that his tech person took only 15 minutes to sort
of bomb the FCC with phone calls.
But I mean, the demonstration showed writing a simple script,
20 phones just light up on the table.
And this can be scaled and, you know, however large you want to go with it.
DAVID MALAN: No.
And, fun fact, I actually did this in CS50 once, a few years ago,
and have not done it since because this blew up massively on me.
Long story short-- and we have video footage of this if you dig through--
several years ago, maybe if it's 2018, most recently,
it's probably 2014, give or take.
In one of the lectures, mid-semester, we were talking about web programming
and APIs and I wrote a script in advance to send a message via text--
well, technically, via email to text.
It was sent through what's called an email
to SMS gateway that would send a message to every CS50 student in the room.
And at the time, I foolishly thought it would
be cute to say something like, where are you?
Why aren't you in class?
Question mark.
And the joke was supposed to be, because if anyone were,
you know, cutting class that day and weren't
there they'd get this message from CS50's bot thinking,
oh my God, they know I'm not there.
When, really, everyone else in the classroom was in on it
because they saw me running the program and they knew what was going to happen.
And it was pretty cool in that, all of the sudden,
a whole bunch of people in the room started
getting text messages with this, I thought, funny message.
But I had a stupid bug in my code, and essentially my loop
sent one text message, the first iteration;
Then two text messages, the second iteration;
then three text messages, the third iteration.
Whereby the previous recipients would get another and another and another
because I essentially kept appending to an array or to a list of recipients
instead of blowing away the previous recipient list.
COLTON OGDEN: It's like a factorial operation.
DAVID MALAN: Well, a geometric series, technically.
COLTON OGDEN: [INAUDIBLE].
DAVID MALAN: Or if you did it--
I did, I think I did out the math.
If I had not hit Control-C pretty quickly
to cancel or to interrupt the process, I would have sent 20,000 text messages.
And they were going out quickly.
And I felt horrible because this was enough years ago where some people were
still paying for text messaging plans.
It wasn't unlimited, which is pretty common, at least in the US these days,
to just have unlimited texts or iMessage or whatever.
So, you know, this could have been costing students $0.10 to $0.25
or whatever.
So we offered to compensate anyone for this,
and I did have to single out a $20 bill I think to one student whose phone I
had overwhelmed.
But, there too, it was also, phones were old enough that they only had finite--
well, they always had finite memory.
They had terribly little memory, and so when
you get a whole bunch of text messages, back in the day,
it would push out older text messages and I felt awful about that.
COLTON OGDEN: Oh.
DAVID MALAN: Kind of overwhelming people's memory.
So anyhow, this is only to say that even hopefully
good people with good intentions can use robocalls or robotexting accidentally
for ill.
And if you're trying to do that deliberately,
maliciously, it's just so darn easy.
COLTON OGDEN: So solutions to this then?
DAVID MALAN: Don't let me in front of a keyboard.
[LAUGHTER]
COLTON OGDEN: Do we-- so there is a little bit of reading I was doing,
and it might have been in this same article,
but cryptographically signing phone calls,
is this something that you think is possible?
DAVID MALAN: Yeah.
I mean, I don't know terribly much about the phone industry
other than it's pretty backwards or dated
in terms of how it's all implemented.
I mean, I'm sure this is solvable.
But the catch is how do you roll it out when you have old-school copper phone
lines, when you have all of us using cell phones on different carriers?
It just feels like a very hard coordination problem.
And honestly, now that data plans are so omnipresent and we decreasingly
need to use voice, per se--
you can use Voice over IP, so to speak--
you know, I wouldn't be surprised if we don't fix the phone industry,
but we instead replace it with some equivalent of WhatsApp or Facebook
Messenger or Skype or Signal or any number of tools
that communicate voice, but over software.
And at that point, then yes, you can authenticate.
COLTON OGDEN: OK, that makes sense.
And especially if this keeps scaling, I feel like this is an eventuality.
DAVID MALAN: I imagine, yeah.
I mean, even now, right, like I don't get calls via any of those apps--
well, some of them, the Facebook ones I do--
from people that aren't in your contacts.
Sometimes, it just goes to your other folder or whatnot.
But I'm pretty sure you can prevent calls
from people who weren't on your whitelist on those apps like Signal
and WhatsApp that do use end-to-end encryption.
COLTON OGDEN: Sure, yeah.
That makes sense.
DAVID MALAN: So we shall see.
COLTON OGDEN: There is a--
so away from the, I guess, the security, which
has been a major theme of the podcast today,
towards something a little bit different actually-- and this is pretty cool
and I'm, particularly for me because I'm into games--
but Google actually announced a brand-new streaming service
that people are really talking about.
DAVID MALAN: Yeah, that's really interesting.
You probably know more about this world than I do, since I am a fan of the NES,
the original.
[LAUGHTER]
COLTON OGDEN: Well, it's called Stadia, and I've
done a little bit of reading on it, not terribly,
because there's actually not that much about it, right now.
DAVID MALAN: OK.
COLTON OGDEN: Because it just was announced maybe two or three days ago
and, actually, Karim, one of our team, actually kindly showed it to me
because I wasn't aware.
This is going on at a live event.
DAVID MALAN: OK.
COLTON OGDEN: But it's essentially an idea that's been done before.
The companies have done this sort of, we process all the games
and then we stream the video signal to you and you play,
and there's this back and forth.
My initial sort of qualm about this is that we're fundamentally
dealing with streaming latency.
DAVID MALAN: Yeah, of course.
COLTON OGDEN: And it's--
I find it highly unlikely that we can-- especially for a geographically distant
locations amongst servers and amongst consumers--
that we can deal with less than 13 milliseconds of latency
in between a given frame and the input on someone's machine.
DAVID MALAN: Maybe right now, but this seems inevitable.
So I kind of give Google credit for being a little bleeding edge here.
Like, this probably won't work well for many people.
But it feels inevitable, right?
Like eventually, we'll have so much bandwidth and so low
latency that these kinds of things seem inevitable to me, these applications.
So I'm kind of comfortable with it being a bit bleeding edge,
especially if it maybe has sort of lower quality graphics, more Nintendo
style than Xbox style which-- or at least with the Wii, the original Wii,
was like a design decision.
I think it could kind of work, and I'm very curious to see how well it works.
But, yeah, I mean, even latency, we for CS50's IDE
and for the sandbox tool and the lab tool
that to support X-based applications, which
is the windowing system for Linux, the graphical system,
it doesn't work very well for animation.
I mean, even you, I think, implemented Breakout for us a while ago.
COLTON OGDEN: A while back.
DAVID MALAN: And tried it out and, eh, you know, it's OK,
but it's not compelling.
But I'm sure there are games that would be compelling.
COLTON OGDEN: Yeah.
I know that in their examples, they were doing things like Assassin's Creed
Odyssey, you know, very recent games that are very high graphic quality.
I mean, I would like to--
I would definitely like to see at work, if possible.
DAVID MALAN: Yeah.
No, I think that would be pretty cool.
One less thing to buy, too, and it hopefully lowers the barrier to entry
to people.
You don't need the hardware.
You don't need to connect something else.
You don't need to draw the power for it.
I mean, there's some upsides here, I think.
COLTON OGDEN: I think especially if they are doing this at scale--
and Google already does this, surely-- but, you
know, they have a CDN network that's very--
and it's very, maybe a US-centric thing at first,
and then can scale it out to other countries.
Maybe the latency between any given node on their network
is either-- or the gap is small enough such that the latency is minimal.
DAVID MALAN: Yeah, hopefully.
COLTON OGDEN: As long as it's less than 13 milliseconds, though.
That's the one in 60-- one's over 60, which is the--
typically, the games are 60 frames per second--
that's the amount of time it needs to be to process input
and feel like it's a native game.
DAVID MALAN: Well, to be honest, I mean this
is similar to their vision for Chromebooks
which, if you're unfamiliar, is a relatively low-cost laptop that
is kind of locked down.
It pretty much gives you a browser, and that's it,
the presumption being that you can use things like Gmail and Google
Docs and Google Calendar, even partly offline, if you're on an airplane,
so long as you pre-open them in advance and sort of cache some of the code.
I mean, that works well so long as you have good internet.
But we've chatted with some of our high school students and teachers
whose schools use Chromebooks and it's not great
when the students need to or want to take the laptops home.
Maybe they don't have or can't afford their own internet access at home,
so there's certainly some downsides.
But I don't know.
I feel like within enough years, we'll be at the point
where internet access of some sort is more commodity like electricity
in the wall and so long as you have that kind of flowing into the house,
that it'll be even more omnipresent than it is now.
COLTON OGDEN: Sure.
Yeah that makes total sense.
I would definitely like to see it happen.
I hope it does.
DAVID MALAN: Yeah, so.
COLTON OGDEN: Well, I think that's all the topics
that we've sort of had lined up.
We covered a nice sort of breadth of them.
This was great.
I like this format.
DAVID MALAN: Yeah.
No, hopefully you're still listening because I
feel like we should offer a couple bits of advice here.
I mean, one, on the Facebook password front,
I mean, even I did change my password.
I don't know if mine was among the millions that were apparently
exposed in the clear, and it's not clear that any humans noticed
or used the password in any way, but changing your password's
not a bad idea.
And as you may recall from CS50, itself, if you've taken the class,
you should probably be using a password manager anyway and not
just picking something that's pretty easy for you to remember.
Better to let software do it instead.
And on the robocall front, I, mean there's a couple defenses here.
I mean, even on my phone, I block numbers once I realized, wait a minute,
I don't want you calling me.
But you can also use things like Google Voice,
right, where they have a feature which seems a little socially obnoxious where
Google will pick up the phone for you and they
will ask the human to say who they are.
Then you get, on your phone, a little preview of who it is,
so it's like your own personal assistant.
COLTON OGDEN: That's kind of interesting.
I actually didn't realize that was thing.
DAVID MALAN: It's an interesting buffer, but it's kind of obnoxious.
COLTON OGDEN: Yeah.
DAVID MALAN: Right, to have that intermediate.
COLTON OGDEN: You could have a whitelist, surely though, that--
DAVID MALAN: For sure.
COLTON OGDEN: Yeah.
DAVID MALAN: No, so for unrecognized calls,
but people tried rolling this out for email, though, years ago,
and I remember even being put off by it then.
If I email you for the first time, we've never met,
you could have an automated service bounce back
and say, oh, before Colton will reply to this, you need to confirm who you are
and click a link, or something like that.
And at least for me at the time-- maybe I
was being a little, you know, a little presumptuous-- but it just felt like,
ugh, this is, why is the burden being put on me to solve this problem.
COLTON OGDEN: Also, a little high and mighty, potentially.
DAVID MALAN: Yeah.
But, I mean, it's an interesting software solution,
and that's what Google Voice and there's probably
other services that do the same thing.
So you can look into things like that.
And as for like Stadia, I'll be curious to try this out
when it's more available.
COLTON OGDEN: Yeah, me too.
Me too.
DAVID MALAN: Yeah.
You know, I think it's worth noting that podcasting is how CS50 itself ended up
online, way back when.
Long story short, before CS50, as Colton knows,
I taught a class at Harvard's Extension School, the Continuing Ed program,
called Computer Science E-1, Understanding Computers
and the Internet.
And we, in 2005, I believe, started podcasting
that course, which initially meant just distributing MP3s,
which are audio files, of the lectures.
And then, I think one year later, when the video iPod, of all things,
came out, we started distributing videos in QuickTime format and Flash format,
probably.
COLTON OGDEN: Definitely MOVs.
DAVID MALAN: Yeah, of the course's lectures.
And it was really for the convenience of our own students
who might be commuting on a train or maybe they're on a treadmill,
and it was just kind of trying to make it easier for people
to access the course's content.
And, long story short, a whole bunch of other people
who weren't in the class online took an interest, found the material valuable.
And certainly, these days, there's such a proliferation
of educational content online.
But it was because that course we started
podcasting that when I took over CS50 in 2007,
it just felt natural, at that point, to make the course's
videos available online as well.
And even though we've kind of come full circle now and taken away the video
and replaced it just with audio, I think it really
allows us to focus on the conversation and the ideas
without really any distractions of visuals or need to rely on video.
So hopefully, this opens up possibilities
for folks to listen in, as opposed to having to be rapt
attention on a screen.
COLTON OGDEN: And what I like is this is a more current events focused talk,
too.
Yeah, we have so much other content, it's
nice to sort of have a discussion on the things that are relevant in the tech
world, or otherwise.
You know, it fits this format very well.
DAVID MALAN: Yeah, absolutely.
Well, so this was Episode Zero of CS50's podcast.
We hope you'll join us soon for Episode 1, our second podcast.
Thanks so much for CS50's own Colton Ogden, whose idea this has been,
and thank you for spearheading.
COLTON OGDEN: And thanks, David, for sort of leading the way here.
DAVID MALAN: Yeah, absolutely.
Talk to you all soon.
COLTON OGDEN: Bye-bye.