Refactoring the Mozillians.org authorization scheme

[Justin Crawford]

I wrote a blog post[0] proposing that we refactor the Mozillians.org authorization scheme, for reasons outlined in the post (among others). Summary:

"Mozillians.org has become a mature platform and a valuable source of information about people who contribute to Mozilla’s products and mission, and it is likely to be important to Mozilla’s ambitious contributor goals over the next decade. But Mozillians.org has outgrown the authorization paradigms it started with. Therefore, in order to prevent data safety issues and questions about product integrity, we must design and implement an authorization system that accommodates current and future data and users. We should apply this system evenly to both the UI and the API."

I also created a tracking bug for this and a couple blocking bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=926644

Let's use this mailing list thread as a forum for discussion. Looking forward to hearing other perspectives on this!

Justin

[0] http://hoosteeno.com/2013/10/14/refactoring-the-mozillians-org-authorization-scheme/

--
Justin Crawford
Web Product Engineer | Mozilla
hoos...@mozilla.com

[aust...@gmail.com]

Great post Justin.

I think the web service should just expose the same rights to the data that you have via the web interface. That was the original design with the LDAP backend, which had built in access control and limits on data output.

Additional rate limiting could be added (which was not in the original LDAP backend).

Any Mozillian could click "get API key" and the rights would be derived from their account. No bugzilla ticket needed.

For websites or services that don't fit this model, a bug would be filed and a custom user would be setup with fine tuned ACLs which match their use cases. Of course a data safety review would be part of that bug.

Benefits: Today, I could write an Addon that does much of what the web service API does. It is only limited by the protections that the web interface provide. The point of the web service is to enable us machine to machine access to this same data in a simpler way.

[Axel Hecht]

Hi,

I think you've nailed some good problems, but I don't understand yet
what you actually want to do. Or if you know that yet.

I'm just generally unsure what's the next step for whom.

Also, do we have enough of the consumers on this list? Do you have a
list of folks to reach out to?

Axel

[Justin Crawford]

----- Original Message -----
> From: "Axel Hecht" <l1...@mozilla.com>
> To: mozilla-dev-c...@lists.mozilla.org
> Sent: Thursday, October 17, 2013 8:42:13 AM
> Subject: Re: Refactoring the Mozillians.org authorization scheme

<snip>

> I think you've nailed some good problems, but I don't understand yet
> what you actually want to do. Or if you know that yet.
>
> I'm just generally unsure what's the next step for whom.

Thanks for asking! You're quite right, we haven't proposed a specific solution yet. The challenges posed by the problems the blog post identifies are at least 50% philosophical/conceptual, and we're thinking about it and listening right now. Here's what I mean:

Example question: If we say that "vouched" is no longer the right way to become a member of the platform, then what does it take to become a member? Can anyone join?
Example answer #1: In order to join the platform, a user must check a checkbox next to every item in the manifesto, and click a button saying, "Yes, I am a Mozillian!"
Example answer #2: In order to join the platform, a user must have a bugzilla.mozilla.org account and

That's the kind of question we're going to have to answer before talking about technical solutions. So, our rough next steps are...

1) The Mozillians dev team is listening for any feedback that might guide our approach to solving these problems.*
2) I've created a tracking bug (https://bugzilla.mozilla.org/show_bug.cgi?id=926644) that has two functional blockers, one relating to authorization groups and one relating to how they are applied in the API. It also has a process blocker -- review by legal, security and data. I'm hoping that each bug generates conversation that we can incorporate into a specification.
3) We'll keep moving forward, proposing solutions based on the best ideas we can come up with and/or attract on all channels during Q4. We aim to start coding in Q1.

> Also, do we have enough of the consumers on this list? Do you have a
> list of folks to reach out to?

So far this conversation has been published here, on planet, in a tracking bug, on twitter, and in the #commtools channel on IRC. When we have a bit more content around next steps, we'll also share it with the weekly meeting or with that same population somehow else. We're approaching the conversation itself as an iterative process that expands as it improves.

*You've given me an idea about how to tackle the conceptual questions this work raises: Perhaps we should identify those questions and pose them to a general audience? Hmm!

[wrey...@mozilla.com]

Justin, thanks for starting this conversation and capturing the issues around this topic in your blog post.

Austin, I agree about providing a web service that exposes the same rights to the data that you have via the web interface. I especially like the idea that any Mozillian can click "get API key" and get the necessary rights without filing a bugzilla bug. The impact of that would be hugely positive for using mozillians.org data in creative, valuable ways.

Axel and Justin, I think identifying the questions and then posing them to a broader audience is a great approach.

In response to the "1 million Mozillians" goal promoted at the Summit, there is a team being put together in the next couple weeks that will be tasked with that goal. I think that is a team which can help us figure out some of those questions and answers.

I'll pose a question: if simply having vouched/unvouched is not adequate, do we switch to a model where there are different types of users on mozillians.org? What are those types of users?

This question was actually brought up today at the Grow Mozilla meeting [1], when the group talked about having "1 million Mozillians" and there was a discussion about who we define as a Mozillian. The general consensus at the meeting is there are already three types of Mozilla contributors that are documented [2], though there is still an open question about which of those levels should be counted towards the "1 million Mozillians" goal. The group didn't talk about this in the context of users on mozillians.org, but I think those types of contributors is a good starting point for identifying more questions and solutions.

Another question: how do we handle Mozilla contributors who stop contributing?

Mozilla alumni are a good-sized (and growing) group, and many of those people want to stay connected with Mozilla and potentially contribute again or mentor others. They would also like to stay in touch with Mozillians and other alumni.


[1] https://wiki.mozilla.org/Grow/Meeting_10_17_13
[2] https://wiki.mozilla.org/Community

[Justin Crawford]

> In response to the "1 million Mozillians" goal promoted at the Summit, there
> is a team being put together in the next couple weeks that will be tasked
> with that goal. I think that is a team which can help us figure out some of
> those questions and answers.

Great! Who is forming the group, and how would someone join it if they wished to?

[Axel Hecht]

There's also been the summit sessions ` What does "Mozillian" mean?`.
Seems folks are still digesting that,
https://wiki.mozilla.org/Summit2013/Sessions/Friday#What_does_.22Mozillian.22_mean.3F
is probably a good link.

In the session I attended, we ended up kinda feeling we're doing it the
wrong way around. First trying to find out what a mozillian is, and then
figuring out what to do with them.

It might be more constructive to first find out what we want to do with
the list, and then figure out how to get people on and off the list.

Something similar could hold for mozillians.org. Are there different
use-cases? Are those different enough that we need different groups?

"I need a volunteer in X for Y" would be one.

"Who's working on Z?".

"pretty confidential video or email" is likely one.

conference invites. summit vs local community?

Does such a list make sense? Does it help?

Axel

[Giorgos Logiotatidis]

In principle I agree that getting a key should be as easy as clicking a
button. Also that the key should give access to the data that I already
have access to, with the same permissions. Otherwise I can do, as austin
says, a html scrapper and get the data.

This is how things work on other websites too. E.g. on github you click
get API key and you get a key. You can -using your key- make public *your*
private data if you want, or parse and display other users public data.
What you can't do is get private data out of repositories that you don't
have access too. Which is of course the obvious thing to happen.

In mozillians.org we do have a special situation though:

As a vouched Mozillian you are being granted to possible private data
that's *not yours*. You shouldn't be using publicly exposing that data
or even privately exposing them to other who are not mozillians.

For example, I get an API key and create a public page of users in the
'beards' group. This is not a valid use of the data.

Moreover if I do create a mozillians only page (using API to check if
one is vouched or not), I still have to be very careful not to expose
data that are not supposed to be accessed by all mozillians.

For example, I as an mozillians.org admin, I do have access to see all
data on the site. If I click 'get API key', I shouldn't be exposing
T-Shirt sizes to other users, even if these users are vouched
mozillians. Because they don't have access to that information in the
first place.

I do think that this is serious issue we need to address and hopefully
we can address it on the technical level, to avoid (accidental) release
of private data.

Best,
Giorgos

[Austin King]

On Friday, October 18, 2013 7:15:25 AM UTC-7, Giorgos Logiotatidis wrote:
>
> In mozillians.org we do have a special situation though:
>
> As a vouched Mozillian you are being granted to possible private data
>
> that's *not yours*. You shouldn't be using publicly exposing that data
>
> or even privately exposing them to other who are not mozillians.
>
> For example, I get an API key and create a public page of users in the
>
> 'beards' group. This is not a valid use of the data.
>
> Moreover if I do create a mozillians only page (using API to check if
>
> one is vouched or not), I still have to be very careful not to expose
>
> data that are not supposed to be accessed by all mozillians.
>

> I do think that this is serious issue we need to address and hopefully
>
> we can address it on the technical level, to avoid (accidental) release
>
> of private data.

This is a very important point, thanks for raising it.

The thing with data... once the cats out of the bag, you can't use technology to contain it. Only social pressure. There are API nuances such as rate limiting and filtering data, but this only adds friction to extracting the data.

I do not think this can be effectively solved at a technical level.

I think that terms of use for the API and clear guidelines for developers, so that they are aware of the serious nature of their data access is a good tool for protecting these resources.

[Justin Crawford]

>
> I do not think this can be effectively solved at a technical level.
>
> I think that terms of use for the API and clear guidelines for developers, so
> that they are aware of the serious nature of their data access is a good
> tool for protecting these resources.

I agree with the above. There are two sides to this expectation setting:

1) Setting expectations for appropriate use of data (API guidelines, etc.) that will inform API consumers
2) Setting expectations for exposure of data (interface cues, language, themes) that will inform users who input data

We've begun to address the first of these in the most recent API documentation[0].

Addressing the second is what we're doing right here. :)

When we say things like "visible to vouched Mozillians," we imply that there's an intimate, closed and trusted group of potential viewers for the data you share in the platform. But that's not really true anymore, as the blog post says, and it may not be as scalable or as inclusive as we might like. "Getting Vouched" also doesn't mirror the real-world way that people become real-world Mozillians. In fact, people can become real-world Mozillians by contributing, and they do not need to ask for the community to grant them permission to do so.

If we instead built an interface and used words that communicated, "A large group of people who believe in the Mozilla Manifesto," or "The many people who've contributed in any small way to Mozilla," we would be closer to the truth. For example, if the barrier to entry into Mozillians.org was simply that you had to click, "I agree with the Manifesto!", we probably wouldn't call Mozillians.org users "vouched". In that case, some Mozillians.org users would share differently, because they would expect the data to be exposed more broadly -- to anyone who cared to see it.

I assert in my blog post that the barrier to entry is practically that low already, which is why the word "vouched" inaccurately characterizes the network. By building "vouched" into our interfaces, we're inviting people to share with an intimate group, when they're actually sharing with an inclusive group.

[0] http://mozillians.readthedocs.org/en/latest/api.html#using-api-data

[wrey...@mozilla.com]

On Thursday, October 17, 2013 1:47:19 PM UTC-7, Justin Crawford wrote:
> > In response to the "1 million Mozillians" goal promoted at the Summit, there
>
> > is a team being put together in the next couple weeks that will be tasked
>
> > with that goal. I think that is a team which can help us figure out some of
>
> > those questions and answers.
>
> Great! Who is forming the group, and how would someone join it if they wished to?

It looks like David Boswell will be leading this group, and creating a plan for the "1 million Mozillians" goal will be a big part of the community building meetup happening in December.

You can get involved by adding your name to this etherpad by October 24 (tomorrow) if you wish to attend.

https://etherpad.mozilla.org/community-building-meetup-late-2013

[jcra...@mozilla.com]

In case you haven't seen it, there is a lively thread on governance that is quite related to this one. I link here to a recent post in that thread, in which someone confirms my assertion that "vouching" and "being vouched" is not meaningful any more.

https://groups.google.com/d/msg/mozilla.governance/UsgIRmdv9Kk/KuOyU_1_rMoJ

[Shane Caravęo]

I was replying in bug 1011276 where the wiki link [ https://wiki.mozilla.org/Mozillians/API-Access ] was posted, but then decided that this was a better forum since my thoughts around this have not solidified yet. I'm excited to see an expansion of Mozillians.org (have some hacky idea's of my own I'd like to pursue), but have some concerns from what I read on the wiki.

I'm fine with a vouched 3rd party app getting API access to public data. As well I'm fine with internal apps having full access. The following thoughts are around the "reviewed" app mentioned in the wiki page.

ISTM that the API will work a quite different than what I am used to. I'm used to granting an app access to my data by installing an app or granting oauth access, however here it seems that apps will be granted access to my data by Mozilla without my involvement. Is that correct? If not, much of what I say below is wasted space and I apologize in advance.

My primary concern is that under this proposal I [as a user] am relinquishing control over who has access to my [non-public] data to Mozilla. 3rd Parties get automatic access to more than my public data after someone else has reviewed their app/code/whatever. The "reviewed" app doesn't have to convince me of it's value so that I choose to give it more of my personal data.

I see a certain sense in having apps be able to get at larger sets of data to make them interesting, getting each user to opt-in to each app before the value manifests is an incredible barrier. It seems that this is the issue that the "reviewed" app is trying to solve.

Without having thought about this as deeply as the Justin & the mozillians team has, I think I'd like to see an architecture that works more like this:

- internal trusted apps
- under mozilla purview (privacy/data policies/etc)
- runs on mozilla infrastructure
- by mozilla, automatic data access, part of the "mozillians platform"
- by 3rd party, automatic access to some medium level of data,
- user opt-in to granting more access,
- user opt-out (unsure what that would mean here)
- since this is internal, 3rd party apps may be a false dichotomy

- external untrusted apps
- easy API key access to vouched users
- apps having access to public data via API
- opt-out available to user (per app? all untrusted apps?)
- opt-in to a specific app by a user may provide the medium level of data access that the above "internal 3rd party" apps have

In the above model "reviewed" apps would instead be 3rd party trusted apps running on mozilla infrastructure. This keeps actual access to the data under one roof. Any "vouched" for mozillian can get a key and run an untrusted app anywhere, and users have to opt-in if those apps require more than public data.

Shane

[Justin Crawford]

Thanks Shane for thinking about this and for starting the conversation!

> My primary concern is that under this proposal I [as a user] am
> relinquishing control over who has access to my [non-public] data to
> Mozilla.

This concern doesn't seem to be addressable, to me. In all 3 cases
(current, under the proposal in the wiki, and in your modifications),
users relinquish control to Mozilla over who has access to their
non-public data in Mozillians.org. I think that's inevitable, so I'm
going to move on to the other details you describe.
>> 3rd Parties get automatic accessto more than my public data
I think this is an assumption you're making about the proposal that is
not supported by the proposal. Instead, the proposal suggests 2 levels
of access, one very broadly granted ("vouched") and one very tightly
controlled ("reviewed"). Whether 3rd parties ever are granted the
"reviewed" type of access is TBD.

I suggest 3rd parties should only ever be granted access to the
"reviewed" level if we are as assured about their stewardship of data as
we are about 1st-party apps. I think this may be very difficult or
impossible for most 3rd-party apps to achieve. Still, I would not
suggest we categorically exclude 3rd-party apps; instead, I would simply
suggest that we set very high standards for "reviewed" apps since we're
sharing data with them that has been shared only within a trust network.

While the "review" part of "reviewed" remains to be specified, I think
it should ensure that "reviewed" apps are...

> - under mozilla purview (privacy/data policies/etc)
> - runs on mozilla infrastructure

and also that...
- application owners have demonstrated (through conversation or
even contract) that they understand, will respect, and will perpetuate
the privacy levels associated with non-public data

In other words, I think the proposal's idea of "reviewed", while
unspecified, sets a very high bar. It's high enough that I agree with
you when you say
> - since this is internal,3rd party apps may be a false dichotomy
It may help to know that our initial list of apps likely to pass
"review" includes only a small number: Air Mozilla, BMO, a few others.
Internal tools whose need for this data is easy to justify and whose PII
stewardship is already demonstrated.
> - external untrusted apps
> <snip>

> - opt-out available to user (per app? all untrusted apps?)

I think the proposal in the wiki is elegant because it does not require
this additional opt-out, and it thereby saves our users the pain of
trying to stay on top of per-application API grants (and allows us to
plug some gaping holes without blocking while we build this more complex
UI). It specifically doesn't require this opt-out because the fields
available to "vouched" level API keys are public -- they have been set
to public by the user. Users who share profile data publicly have
already made the data programatically available to the entire internet.
The data there is leaked, but the API is not the source of the leak.
Users who wish to hide data from other Mozillians who have API keys
should first hide it from the entire internet; and in the proposal on
the wiki, the same setting (change "public" to "Mozillians" on the
field) does both things.

Shane, I really appreciate your feedback. To be honest, I was hoping
that someone from the security team would be interested in helping to
design the review process. Would you be up for helping us articulate
what it ought to look like?

--
Justin Crawford
Web Product Engineer | Mozilla
hoos...@mozilla.com

> Shane Carave;o <mailto:mixed...@gmail.com>
> May 17, 2014 6:35 PM

> _______________________________________________
> dev-community-tools mailing list
> dev-commu...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-community-tools

[Shane Caravęo]

On Saturday, 17 May 2014 19:06:31 UTC-7, Justin Crawford wrote:
> Thanks Shane for thinking about this and for starting the conversation!

No problem. I keep looking at Mozillians wishing it would do "this or that" so having a way to hack around with it interests me.

> > My primary concern is that under this proposal I [as a user] am
> > relinquishing control over who has access to my [non-public] data to
> > Mozilla.
>
> This concern doesn't seem to be addressable, to me. In all 3 cases
> (current, under the proposal in the wiki, and in your modifications),
> users relinquish control to Mozilla over who has access to their
> non-public data in Mozillians.org. I think that's inevitable, so I'm
> going to move on to the other details you describe.

I don't think I clearly expressed myself here. My concern isn't about data I give directly to a Mozilla controlled website such as Mozillians.org, or about mashups hosted by mozilla between mozilla owned properties, but about Mozilla passing that data to an external 3rd party without the users express permission. As I understood the wiki page (and I may be wrong based on your other responses), the review process essentially replaces the oauth dialog for external 3rd party websites.

I don't care about data I marked as public, but it's implied that reviewed sites would get more than the data I marked public. Regardless of the review process, if that 3rd party is external, gets access to more than what is public data, and the user doesn't somehow have control over that, I think it's an issue that needs more a lot more clarity.

cutting this short since it *is* the weekend and I *should* do something else... :) I'll re-read this stuff when I'm actually working.

> Shane, I really appreciate your feedback. To be honest, I was hoping
> that someone from the security team would be interested in helping to
> design the review process. Would you be up for helping us articulate
> what it ought to look like?

To be clear, I'm not on the security team. I'm in the same part of the org as the privacy team, and work with them where I have the opportunity, thus jumping on that bug. I'd be happy to be involved in discussions on this.

Shane

[Shane Caraveo]

On 2014-05-19, 12:59 PM, Justin Crawford wrote:
>> Regardless of the review process, if that 3rd party is external,
>> gets access to more than what is public data, and the user doesn't
>> somehow have control over that, I think it's an issue that needs
>> more a lot more clarity.

> Right now I know of no such 3rd party or use case. So I suggest we
> handle this concern by including in the review process some
> requirement about "internal" that satisfies this concern, and wait
> for a justifiable use case to drive a more complex 3rd-party
> solution.
>
> Will that work? If so, what language would you specifically suggest
> for the "internal" requirement? Does "Running on Mozilla
> infrastructure in a Mozilla datacenter and satisfying Mozilla's
> current data security, data privacy and legal standards for web
> applications" work?

Absolutely.

>> To be clear, I'm not on the security team. I'm in the same part of
>> the org as the privacy team, and work with them where I have the
>> opportunity, thus jumping on that bug. I'd be happy to be involved
>> in discussions on this.
>

> Sorry for the mix up. You're exactly who we need to help us, so
> thanks!

No problem :) Just pull me into any conversations.

Shane