NARRATOR: One year ago in this is
quiet library in this cozy studio,
something happened,
something so frightening--
[SCREAMING]
NARRATOR: Something so
deadly, something so evil--
[SCREAMING]
NARRATOR: We prayed it
would never happen again.
Now, from the creators of
CS50 Live comes CS50 Live.
DAVID: Hello, world.
This is CS50 Live,
season one, zero indexed.
That's right.
We've been picked up by
Harvard for another season.
And boy!
Do we have an amazing
episode for you today.
First, we'll take a look back
at the most popular passwords
of this past year.
We'll look at a nasty bug in
a popular gaming platform.
We'll give you a new
definition of the word evil.
And we'll pay a visit to
our friends at Google.
No relation.
But first, let's take a
look back at season wha--
Hello, world.
This is--
ROBOT: CS--
RAMON: 50 Live.
I am Ramon Galvan.
Filling in today for David.
DAVID: Who has lost his voice.
RAMON: Today, he'll be the Andy
Richter to my Conan O'Brien.
DAVID: And now, for our first bug fix.
This is, of course, season zero's
look back, and not season one.
But what else is new?
Well, turns out not much
in the world of passwords.
In fact, the most popular
password in this past year
was, as before, 123456,
followed closely in second place
by the old school "password."
However, in third place
this year, up 17 places
is our old favorite, 12345,
which you may remember
from such films as this one here.
Now, in 17th-- in 25th place,
meanwhile, is a newcomer, "dragon."
Perhaps, because of
such films as this one.
Now, in 25th place-- and now, for
our second bug fix of the season.
Whereas that was in ninth
place, "dragon," we're
now going to take a look
at 25th place, "trustno1."
Now, if you think you've been oh
so clever by using 1, the number,
instead of "one," the
word, in your password,
well, rest assured that so
have millions of other people.
Now, you may recall this expression
from such films as this one here.
And speaking of Scully, we'd
like to welcome aboard to CS50,
CS50's newest team member, Scully,
pictured here in a recent field trip
to a CS50 ice skating rink.
In fact, can we enhance?
No.
Can we enhance?
Yes, indeed.
That is our Scully.
Welcome aboard.
And now, a nasty bug
in a popular software
from our friends at
Valve software called
Steam, which is a platform for
downloading and then playing
popular video games.
Well, turns out that a user recently
reported to the Linux community
for Steam's clients the following bug.
He moved his local
share Steam directory.
He ran Steam, and it deleted
everything on the system owned by User.
In other words, simply by moving one
of his folders for this game, Steam,
for this platform gaming-- for
this gaming platform, Steam,
he ended up deleting all of
the files on his hard drive.
Now, it's fascinating.
If you take a look at
this thread on GitHub.com
is you'll see that the community
chased down the bug to this line
here, which declares a so-called
environment variable on the left,
assigns it the value here on the
right, but unfortunately, it turns out,
if you do move a certain
directory, this value
can evaluate to just quote, unquote,
or the so-called empty string.
Now, unfortunately, later in the file
is this very dangerous line here.
rm -rf and then STEAMROOT/*.
Unfortunately, if STEAMROOT is itself
the empty string, this becomes just /*,
which of course has the effect of
saying remove recursively and forcibly
everything in the root of my hard drive.
Now, thankfully, this particular
fellow had backups of all this data.
So not all was lost, but if
you'd like to take a closer
look at this bug and the
resulting fix therefore,
go ahead to Github's URL here.
And now a word from our old friend
Cookie Monster, who is holding in his
hands here Verizon, who gives us today
our new definition of the word "evil."
You may recall a few months
back that Verizon, as well
as another popular cell
phone company in the US,
AT&T, were injecting so-called
super cookies into the mobile HTTP
traffic from folks like me, who are
using phones to access the internet.
Specifically, they were
introducing into our HTTP traffic
a header called UIDH, which essentially
inserted a unique value associated
somehow to my cell phone and
perhaps your cell phone so
that any website that receives that
value can know that this is me again,
and again, and again.
Of course, this
effectively allows websites
to track me under the
premise of serving up
more effective advertising, but
nonetheless, a maliciously potentially
keeping track of who I am.
Because in fact, even if I
delete all of my phone's cookies,
and even if I use my
browser's incognito mode
this UIDH header is still being
injected by a company like Verizon.
Now, thankfully, Verizon
recently announced
that they're going to
let us finally opt out
of this horrible, horrible practice.
And yet all along,
they've been ensuring us
the UIDH was designed with
privacy protections in place.
It changes automatically
and frequently and does not
contain any customer information.
Now, the last of those
claims might be true,
but this is ridiculous to claim
that by changing it periodically
and automatically you're
actually protecting us users.
Consider, after all,
how a malicious website
can figure out who we still are.
If this is me here on the left,
trying to visit a website like this
on the right, and suppose
for the sake of discussion
that this website on the right
happens to be running PHP,
and therefore uses session cookies
and gives me a value called
PHPSESSID to remember who I am as
with one of those digital hand stamps.
Well, the next time I make an
HTTP request to the server,
I'm going to present that hand stamp,
PHPSESSID, and it might equal abcd.
But meanwhile, Verizon, as the
so-called man in the middle,
is going to be injecting
a little something
like this, UIDH: 1234, which is my
unique identifier so long as Verizon
is concerned.
Now, so long as this website remembers
that, he can correlate, of course,
abcd with 1234.
But suppose the next
time I visit the website,
I again send that same cookie,
abcd, but Verizon's now
claiming that they're protecting me
by changing my value to, say, 5678.
Well, it doesn't take a particularly
sophisticated line of code
to realize abcd used to be 1234.
Now, abcd is 5678.
Let me update my own database so
that I realize that 1234 and 5678 are
and have always been the same person.
It's not much protection indeed.
Now, for more details and to learn
more about these kinds of threats,
head to this URL here.
And if you'd like to be
paranoid-- and you should now
be-- head to amibeingtracked.com.
And now for a new segment altogether.
You know that depictions
of technology are
quite popular in today's films and
TV, but they're not necessarily
always accurate.
In fact, let's take a look at a popular
film from yesteryear, "Weird Science,"
and pass a little CS50 judgment.
Let's roll film.
Here we have two fellows trying to
hack into computer systems using an age
old modem, by putting the
phone on top of the computer.
This man is now defending
himself against the attack.
If you ever wondered what it
means to hack, this, of course,
is what it truly is.
Those are some backup tapes.
Access.
That's what happens
when access is denied.
Now, wait for it.
Wait for it.
Bowling alley effect.
And now, we have to choose.
How are we going to hack the system?
We're going to hack to the left.
No.
That was the wrong choice.
Let's try again.
Back up.
Let's go down the middle.
Here we go.
All right.
Wait for it.
Wait for it.
I wonder what time it is.
Oh.
Oh, and physics, of course, is relevant.
GARY: We're in.
DAVID: No.
No.
We're not in.
That's-- that's enough of that.
But if you'd like to learn a bit more
about this, google "Weird Science."
And in fact, speaking
of Google, we recently
headed out to Mountain View, California
to meet with two of our friends
from Google to talk with them about
what it's like to develop software
in the real world.
In fact, we met with them
outside of the actual building
in which Android software is developed.
Let's take a look.
ANDREW: My story starts senior
year of college in 2007.
I was a chemistry major and
planning to go to medical school.
I signed up for CS50.
This was the first year
that David was teaching.
I loved it.
I loved every minute of it.
David was nice enough to invite me
back the next year to be a TF for CS50.
I bounced around a
little bit after college.
I didn't end up going
to medical school, and I
decided to teach myself
more about computer science.
And I ended up getting a job at Google,
and I'm now on the Android team.
JOHN: Here at Google, I work in the
Anti-Abuse Engineering department
in our product quality operations
group, specifically fighting
click fraud on our ad networks.
ANDREW: Recently, I'd
been working on a website.
And of course, at Google
developing a website
means you want to be able
to serve millions of users.
So we have to get things
like load balancing in place.
We have to make sure that the static
content gets served very quickly
and is optimized for all of our users.
And in order to test this,
one of the things we do
is we write integration tests.
So we have to bring
up all of our servers,
including the login servers,
the static content servers.
Bring those all up, and then
test that our website loads.
So we use a framework called
Selenium, which is open source.
And it allows you to fire up a browser
and actually load your website in it
and then perform actions on it.
The interesting challenges
are digging into those logs,
figuring out what's going on and
that's what I've been wrestling
with the last week or so actually.
JOHN: Ran into an
interesting problem where
we were dependent on date and time,
and when you think about date and time,
you usually only think about your local
system, because you're coding on it.
And you compile on
it, and you run on it.
But what happens is when you have a
global footprint with data centers
all over the world, local time
doesn't really mean anything anymore.
So we realized that local time
was actually causing problems,
because the database that all of our
data was stored in had a timestamp.
And so timestamps now were
very time zone independent,
which none of the code accounted for.
And so we ended up realizing
was that all of a sudden jobs
were running-- that they thought were
running eight hours in the future
were actually running presently.
The end result was to
just normalize any time
we're using day times to make sure
they're in either UTC timestamps
so that we normalize the time,
or just double check to make sure
that we're running in an environment
that is known at the time
so that we don't run into these sorts
of weird math time calculation problems
that we did.
ANDREW: Hello, world.
I'm Andrew Sellergren.
JOHN: And this is CS50.
DAVID: And now for a special treat.
At Harvard, there's a
tradition of shopping
for courses whereby students
can take a look at classes
for the week at the
start of the semester
before actually enrolling
in those classes.
We thought we'd honor this tradition
by producing CS50's first ever music
video toward an end of
getting students and hopefully
you excited about what awaits in CS50.
This is Funk 50.
[MUSIC PLAYING]
That's it for CS50 Live.
Thanks so much to Oleg,
and Joe, and Padrick,
and to Dan, Shelley, Colton, Ramon,
and our newest team member, Scully.
This was CS50.
