0:04
[MUSIC]
Hey Aaliyah.
You know it's my friend's birthday and you have such a great voice.
>> Yeah. >> Would you mind calling her for
her birthday?
>> Yeah, totally.
Yeah. >> Sure, here you go.
Here's the phone.
And here's the number.
Let me just get this right for you.
Okay, there's the number.
>> Okay.
[MUSIC]
[SOUND] [FOREIGN].
>> What?
Wait! She, she doesn't speak French!
[CROSSTALK] What, what happened?
Who did you call?
>> [FOREIGN]
>> [MUSIC]
>> Hey Aaliyah, it's my friend's birthday and she speaks great French,
she would love it if you would just wish her a happy birthday in french.
Could you do that for her?
>> Yeah, yeah.
>> Oh great sure, let me just dial the number.
[SOUND].
>> Here you go.
>> [FOREIGN]
[MUSIC]
>> Hi, everyone.
In this lecture we're going to be talking about authority and
how it relates to security.
Authority is access to resource or information that the user controls.
So we're going to be looking at when the user grants access to their information or
resources, how the system grants that access and
how we can make sure that the user is in control, as much as possible,
with the granting of authority to their resources and information.
In the little vignette that you just saw, we had two scenarios.
In one, the user granted authority to dial the phone.
And in the other they didn't, and that affects the security of their system.
When you're building a system, were going to look at some guidelines about how
to grant authority to keep systems more secure.
The first guideline is to match the easiest way to
do a task with the least granting of authority.
So some questions that you should think about with this is, first,
what are the typical user tasks?
When a person is using the system, what are the kind of things they have to do?
Then, what's the easiest way for the user to accomplish each task?
2:52
Then you need to think about what authority is granted to software and
other people when the user takes the easiest route to completing the task.
And finally, how can the safest ways of accomplishing the task be made easier and
vice versa?
How are the easiest ways made to be also the safest.
Essentially what you're doing here is creating a system where the natural easy
way a user would do a task becomes the way that also is most secure.
3:25
So consider the login screen for the Washington Post.
There's nothing specific about the Post's website,
it's just one of many examples that has the sign in with Facebook button.
So if we're coming to this site,
and we've never created an account before, we can't simply sign in here.
Now, we can register an account, so we can click on that link.
And you see from there we can put in an email address, password, pick a whole
bunch of other information, potentially link to a home delivery account.
And while this isn't a particularly onerous form,
there's a lot of information that the user needs to add here.
On the other hand, we can just come back to this main page and
click Sign in with Facebook.
4:11
When we do that this window pops up.
We have an example account logged in here.
And all I have to do is say OK and I'm signed in.
It's a much simpler process to log in with Facebook than it
is to register an account.
And probably even than it is to sign in with an existing account that
has a username and a password.
As a result, the easiest way for users to go, is to log in with Facebook.
But are they actually granting more authority than they want to in that case?
Let's go back and take a look at what information appears there.
4:46
I've signed us out so we can see the log in screen again.
Now, let's compare the information that we're granting access to
when we register as opposed to when we sign in with Facebook.
If we register, the information that we're giving is e-mail, a password, the country,
zip code, the year that we were born, our gender and information about our industry.
So essentially we have email password, a little bit of personal information,
and some work information.
5:22
if we try to log in with Facebook we can see the information that gets shared.
We click that link.
And it says that the Washington Post will get information from our public profile,
it will get our friend list, and it gets our email address.
Now the email address is something that we provide when we register.
Our friend list from Facebook is totally new information, so we're granting
additional access through Facebook plus there's this public profile information.
If we mouse over that, we see that has our name, our picture, our age,
gender, language, country and other public info.
Now, a lot of the first things in that list are things that we're asked when we
register anyway.
But other public info is quite broad, and
in fact that includes all the information that we've decided to make
public on Facebook, which can include our favorite books and movies, our likes, and
potentially even other posts that we've made public.
So logging in through Facebook is easier, but it does grant access to a lot more
information then we would allow access to if we registered through the site.
Thus the easiest way actually grants more authority and
more access to our information.
Maybe this isn't the most secure that we can set the site up.
Users are granting more authority than they necessarily have to if
they use the easiest path.
Let's look at one more example and the principle that goes along with it.
In 1975 Saltzer and Schroeder wrote a paper on computer security, and
they proposed a design principle called the Principle of Least Privilege,
which basically says that a system should be given the minimum amount of
information necessary to accomplish its task.
Here we're looking at the Budweiser website.
Since this is an alcoholic beverage website in the US, they're required to
verify that a user is over 21 years of age before they let them into this site.
Like a lot of alcohol providers, their site asks you for
your birthday when you come in.
Now there's nothing that actually checks to
make sure the birthday you enter here is accurate.
You can totally make one up.
So, it's not a very secure way of keeping underaged people out of the website.
They can just lie and say that they're older.
But, let's say that people are going to
actually enter their real birthday on this page.
7:43
Do they actually need to give their full and
exact birthday in order to enter the site?
Well, no, they can just make up any birthday they want.
So, essentially you're just asking for
their birthday to see if they're over 21 or not.
Providing an exact birthday actually gives a lot of information.
There's 365 days in a year, but
you're also providing the year of your birth here.
So, there's not just a one in 365 chance that someone will have your birth date,
the chance is much smaller than that because you're entering the year.
Combining that with, say, information that can be accessed from your IP address about
your location, you're actually helping a website, like Budweiser, narrow down
the exact person who could be accessing their website, quite specifically.
In fact, there have been research papers that have shown that if you
have someone's zip code, which is along the lines of the location information you
can get from an IP address, along with their birth date and
their gender, you can uniquely identify almost 85% of the population.
So granting access to your exact birthday is actually giving a huge amount
of information.
All the site needs to know to make its decision about whether to
let you in is whether or not you are over 21.
Instead of asking for your birth date,
the principle of least privilege would say, they just ask are you over 21 or not?
If someone is going to lie, it's no more difficult to
lie with an exact birthday than it is to lie about being over 21.
And the site's actually much more secure from the user's perspective if it
doesn't ask for this extra information.
9:48
When the phone was handed over, the user didn't understand that
she was also granting authority to dial anyone you wanted.
She gave a phone number, and
she expected that her friend would dial the number that she'd given.
Instead, she gave authority to dial any number that wanted, and
that was a real problem.
So we want to grant authority only when the user has given consent for
that authority to be had.
Some questions to think about here is,
when does the system give access to the user's resources?
So when is the system allowing other people to
access something that the user has.
10:48
So perhaps user takes an action that a programmer decides will indicate access,
but the user doesn't understand that they're granting authority to something.
An example of where this went terribly wrong was with social readers.
Here we're looking at the authority granting section for
the Washington Post Social Reader but in fact, there were a lot of
different news websites that partnered with Facebook to create social readers.
Essentially, when you would click on an article that went to one of
these news websites, for example, if you were on Facebook and
you clicked an article from the Washington Post, this would come up,
and it would say, you're looking at the Washington Post Social Reader.
Do you want to read the article?
If you clicked Cancel, you wouldn't be taken to the article, so
people would say okay, let's read it.
11:52
That's not too bad, and I may be willing to share that information,
which is pretty much public anyway, in order to be able to click through and
read articles that my friends are sharing.
But then, we have this little thing at the bottom here, that says this app may
post on your behalf, including articles you read, people you liked and more.
And again, I may not be suspicious of that because there are a lot of apps that
get access to post to my account, but they don't post without asking me first.
12:29
People didn't understand what this meant.
If you clicked OK, to read the article,
which a lot of people did without even reading the text in the grey box,
you were giving authority to the Washington Post to post something to
your timeline every time you clicked on an article in the Washington Post website.
What was shown on Facebook is for example,
if I had done this it would say Jen Bulbeck read the following articles and it
would show a list of every article I had clicked on on the Washington Post website.
I didn't have to take any explicit action to share them on Facebook.
I didn't need to like them.
Just the act of clicking on an article within the Washington Post,
shared it on Facebook.
There is a huge backlash against this because people would click on things that
weren't bad, but it was maybe embarrassing to share that with their friends.
And ultimately, these social readers got refined and a lot of them got phased out.
But this was an instance where
13:39
You're granting that authority by saying okay let me read the article here.
But most users didn't understand that.
And that is really why people were upset about what this app was doing.
Some may have willingly granted that information, but
because users felt like they were mislead, that they had
granted access that they never intended to grant, there was a lot of backlash, and
ultimately, these apps needed to be severely refined.
14:07
Finally we want to offer the user ways to reduce others' authority to
access the user's resources.
So if I've granted say an app access to my Facebook profile and
I don't want it to have that access anymore, can I revoke that?
Even in a more detailed way could I revoke some of the privileges that it
has access my profile, but not others?
Some things to keep in mind as you're designing are first,
what kinds of access does the user grant to software and other users?
Then, which types of access can be revoked?
14:50
Here we're looking at the profile page of an example account for
a guy named Malcolm.
He has given access to the Washington Post as a way for
him to log in to their website.
And he wants to revoke that access, so
his account on Facebook is no longer linked to his Washington Post account.
How does he get to that information to revoke the access?
This is ultimately an interface design question.
In this case, we hope we can go up here and find some information.
Now there's some privacy shortcuts, maybe this one gives us some information.
If we go to all the settings, then we can look up information here.
15:36
It's really not clear.
This is information about how private or public our posts are on Facebook.
We also have information like who can contact us or
look us up, but there's nothing in here about websites.
If we look over in the left menu bar, there's also no mention of
websites that we've connected to using our Facebook accounts.
Now, I happen to know that those websites are listed under apps, but
the average user's unlikely to know that a website like the Washington Post,
16:07
where you've logged in, actually counts as an app.
Once we go here, we can see the Washington Post is listed as one of
the sites that has access to our information, and from there,
we can edit what they're able to see.
So we can change the visibility of the app here,
we can see the information that it's getting, but we can't change any of that.
But we can remove the app, and
that allows us to revoke the app's access to our information.
Is this interface well-designed to allow people to
change the authority that software to access their resources?
It's not very well designed,
unless an average user knows that apps also refer to external websites,
it's very hard to find the place that you can control and revoke that access.
This is the kind of thing you want to keep in mind when you're designing software.
Make it easy for users to change the authority that they've given to
software other users to access their information.
17:08
So in summary, when you are designing software and you want to make it
more secure from users perspective, first follow the principle of least privilege.
Don't ask for any more information than you absolutely need in order for
your system to accomplish its task.
As you're doing that,
first make the easiest way to complete a task the most secure.
Users want to do things in the easiest and fastest way, so make sure,
the way that they're going to go, the easy way, is also one that provides the least
amount of authority, to software other people, for the task to be completed.
Two, make sure the user consents to the access that they allow.
If the users going to allow access to their resources or
information, they should be very clearly aware that they're granting that access.
And finally, it should be easy for the user to revoke or
reduce the access that software or other people have to their data.
Following these guidelines will make it easy for
users to act naturally within a system and to keep their information secure.