Closed Bug 574200 Opened 14 years ago Closed 14 years ago

Create public phonebook for mozilla 2010 summit attendees

Categories

(mozilla.org Graveyard :: Webdev, task)

Product:
mozilla.org Graveyard
Component:
Webdev
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: beltzner, Unassigned)

References

Details

A precursor to the eventual solution in bug 571881 - to be implemented using the same front-end code that's used in ldap.mozilla.org/phonebook but data stored in a separate database that's initially populated with summit attendees drawn from the "reservations" database (where coming=1) - bonus points for merging over data from LDAP where we have it.

This application needs to be:

 - password protected
 - populated with Mozilla 2010 Summit attendees only

The data fields required are:
 - their name (firstname, lastname from reservations)
 - their email address (pref_email from reservations)
 - their hometown and country (city, country from reservations)
 - indicate their IM and IRC information (ircnick from reservations, merged from LDAP where available)
 - phone number (DO NOT AUTOMATICALLY POPULATE)
 - fill in a "What I work on" section (merged from LDAP where available)
 - fill in an "Other" section (merged from LDAP where available)
 - upload a picture (merged from from LDAP where available)
Any idea how you want to do password protection?  Will a single shared login + http basic auth do?
(In reply to comment #1)
> Any idea how you want to do password protection?  Will a single shared login +
> http basic auth do?

Like, one username and password for all attendees? Or username/password per attendee? Honestly, I'm fine with either.
(In reply to comment #2)
> (In reply to comment #1)
> > Any idea how you want to do password protection?  Will a single shared login +
> > http basic auth do?
> 
> Like, one username and password for all attendees? Or username/password per
> attendee? Honestly, I'm fine with either.

one for all
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Any idea how you want to do password protection?  Will a single shared login +
> > > http basic auth do?
> > 
> > Like, one username and password for all attendees? Or username/password per
> > attendee? Honestly, I'm fine with either.
> 
> one for all

and all for one!
Where is this marvelous `reservations` database that is mentioned? Eventually I'm going to have to write an importing script and I'd like to be able to see what the table looks like.
I have a copy of the DB.  We'll figure that part out when the app is ready.
(In reply to comment #5)
> Where is this marvelous `reservations` database that is mentioned? Eventually
> I'm going to have to write an importing script and I'd like to be able to see
> what the table looks like.

http://viewvc.svn.mozilla.org/vc/projects/rsvp.mozilla.com/trunk/sql/rsvp.sql?view=co
Hey, I wasn't aware of this bug until just now but have been working on something that fits the same use case.

Right now I'm calling it the "Summit Identity Pal", but it's meant to be a custom identity provider that allows apps/mashups to be built on top of it. I built-in a phonebook sort of interface as a base, but the "real" purpose for it was to make either a client app or built-in functionality that allows folks to see what sessions their friends are attending.

The scheduling app was originally prototyped using Twitter OAUTH as the IDP:

  https://hg.mozilla.org/users/avarma_mozilla.com/mozsummit-scheduler/raw-file/proof-of-concept/index.html

More information on that is available in the "About This App" tab of the page.

After talking to some of the Summit Organizers, though, it became apparent that not everyone attending the summit uses Twitter, nor does everyone necessarily want all their info to be public (but they would like to share it with some folks), so I started working on the Identity Pal, which is currently hosted here:

  https://secure.toolness.com/summit/

It's passwordless, in that it asks for the user's email, emails them for confirmation, and the verification URL permanently stores a 256-bit token in localStorage instead of making the user sign up with a username/password.

Let me know if you want to join forces or something.
Oh, the IDP also allows client apps/mashups to store small amounts of JSON data for the currently logged-in user, making it possible to create simple social apps without requiring any server-side setup on the part of the developer. (The Twitter-based prototype accomplishes the same thing via a generic component I wrote that gives every Twitter user 20k of JSON storage on my server.)
Atul, thanks, it looks useful to me.  Beltzner, what do you think?

It's missing a couple fields, e.g. hometown and phone

Atul, we need to mass import data.  Could you work with Wilson on that?
(In reply to comment #10)
> Atul, thanks, it looks useful to me.  Beltzner, what do you think?

Sure, that works for me.

> It's missing a couple fields, e.g. hometown and phone

Not essential, but I agree that they're nice to have as opt-in attributes.

> Atul, we need to mass import data.  Could you work with Wilson on that?

Why don't I just share the list of email addresses with Atul, and he can send an IdentityPal signup email to everyone. If they choose to click it, that's their opt-in.

Atul - I can work with you on the text for that sign up email, I guess.
Sure, that works. Deb already sent me a list of everyone who's signed up to receive the summit newsletter; not sure if that is the same as the one you've got, though, so you might as well send it to me just in case it's different.

The data in my app is stored in JSON format, so it shouldn't be too hard to mass import/export data.
(In reply to comment #12)
> Sure, that works. Deb already sent me a list of everyone who's signed up to
> receive the summit newsletter; not sure if that is the same as the one you've
> got, though, so you might as well send it to me just in case it's different.

Will do; gonna generate a new version for Deb, too. BTW, you'll want to support some form of search. It's 600 people.

> The data in my app is stored in JSON format, so it shouldn't be too hard to
> mass import/export data.

Let's not do mass import here - I prefer the opt-in mechanism of emailing everyone a link that ends up being their userID and password (yay, localStorage!)
Cool. What should the URL for this new place be? Should I work with zandr to set up a subdomain on mozilla.org or mozillalabs.com, or should I not worry about that right now?
I don't really think I care - if you can get a mozilla.org URL hooked up, so be it, but I'm fine with it living on secure.toolness and just linking there or redirecting there.

My feeling is that it's likely to be trickier to get it staged on a mozilla server, but maybe abuchanan can weigh in here?

(I sent Atul the email list and suggested intro email text, copied below:)

--------------------------

Subject: Mozilla 2010 Summit - tell everyone about yourself!

Body:

Atul Varma has put together a little application that can only be seen by Mozilla Summit attendees which lets you share information about who you are, and what you do within the Mozilla community. It's secure, and completely optional, but if you'd like to tell your fellow Summiteers about yourself, please click on the link below and fill out whatever details you want:

<URL HERE>

--------------------------

Also, Atul: Kaie is saying that the page doesn't work in Firefox 3.6.4 - known issue?
When accessing the page using Firefox 3.6.4 / Linux, the page shows only an image, but no text at all.

I get the login form using a trunk build, only.
Hmm, that's odd, because I've actually been developing and using it on 3.6.6 and the latest production versions of Safari and Chrome.  Will take a look... There may also be some extraneous console.log() messages hanging around the code that are crashing it on browsers without Firebug installed.

Do any errors show up in your JS Error Console when you open it in 3.6.4, Kai?
Ok, the culprit is a preference in my primary profile.
I disallow DOM storage.
The error console shows Security error = NS_ERROR_DOM_SECURITY_ERR

Firefox 3.6.4 works for me using a default profile.
dom.storage.enabled = false
(In reply to comment #15)
> It's secure, and completely optional

Without a security review from infrasec, I don't think you should say it's secure...
Since we will be storing all of the attendees personally identifiable information we should perform a security review of the app and system. Also, it would be preferred for this application to run on a mozilla server. Otherwise we'll need to thoroughly review the external host (configuration, other admins, other apps, etc).

The information needed to begin a security review can be found here: https://intranet.mozilla.org/SecurityReview/ReviewRequest
(In reply to comment #21)
> Since we will be storing all of the attendees personally identifiable
> information we should perform a security review of the app and system. Also, it

We'll be storing as much of it as they opt-in to storing. This new application does not need, nor should be, prepopulated with content from the invitations DB. Actually, Alex, if you could delete that from your system, that'd be great, as it's no longer needed for this task.

> would be preferred for this application to run on a mozilla server. Otherwise
> we'll need to thoroughly review the external host (configuration, other admins,
> other apps, etc).

I'm happy to have it run on a Mozilla Server, as I expect, is Atul. How do we expedite this process? He's local to MV, so if someone can just sit with him and go through it, that'd be best. Time is of the essence.
I just asked around and the quickest way is to file the bug to server-ops and also copy jeremy.orem+bugs@gmail.com (yes, include the +). You can mark it as "major" too.
This app is a Labs experiment, and as such, we need to be able to deploy it and iterate very quickly on it.  I've just spoken to my team about this, and we'd like to host this on mozillalabs.com to ensure that mozilla.com/.org domains can't be compromised by a vulnerability in the app's infrastructure.

If you like, we can certainly put a disclaimer on the site about these implications so users opting-in know exactly what they're getting into.
I'm ok with that approach and I think the disclaimer is a good idea too. It doesn't have to be too intimidating, just a note so people are aware this is under rapid development and not fully through the development cycle yet.

But, do let me know when its ready so I can take a look at the current security of the app.
Awesome, thanks Michael--we will definitely do that, and it'll be very helpful to have your security feedback once the app is ready.
There is sensitive data in here, so we should take this seriously.
This means to me (correct me if I'm on crack):
* not on labs servers
* on a separate domain is fine, but we should have some structure around this (even if that means on rackspace and isolated)
* security review before deploying publicly
* https?
Spoke with morgamic. Sorry to go back against what I said, but I agree. We don't have enough control of the security of lab servers to use those with this public data.  So, continue iterating on labs until you are ready to go live. Then we will need to move it over to a mozilla (non-labs) server.

I can begin the security review while its on labs, but will need to still double check a few configs once it is on the mozilla server.
(In reply to comment #22) 
> We'll be storing as much of it as they opt-in to storing. This new application
> does not need, nor should be, prepopulated with content from the invitations
> DB. Actually, Alex, if you could delete that from your system, that'd be great,
> as it's no longer needed for this task.

done
(In reply to comment #29)
> Then we will need to move it over to a mozilla (non-labs) server.

Can we put it on a special-purpose domain, like mozillasummit.com/org or mozilla2010.org or something? then we don't have to worry about being in the mozilla.org/com domain.
Yeah, alternate domain is still a valid idea.  I'm pretty flexible on stuff, I just don't want to put it on labs servers if there's something sensitive in there.
(In reply to comment #29)
> Spoke with morgamic. Sorry to go back against what I said, but I agree. We
> don't have enough control of the security of lab servers to use those with this
> public data.  So, continue iterating on labs until you are ready to go live.
> Then we will need to move it over to a mozilla (non-labs) server.

This sounds to me that we're turning a mole hill into a mountain -- given that this is a side-project for Atul who just wanted to help the Summit organizers with an awesome app plus the fact that the app will only live for a couple of days (during the Summit), this seems to turn into project management mayhem.

If we absolutely require that this goes through a proper security review plus hosting on mozilla.com servers, etc I suggest we stop the work now and don't release it (as Atul has higher priority things to work on).
(In reply to comment #32)
Many other Labs projects that have stored sensitive data have started by coming through Labs (c.f., Test Pilot). Ubiquity had known major security vulnerabilities which came along with a big red warning sign. As long as there is a proper disclaimer that this is a quick Labs project that will undergo rapid iteration than we are fine. The web-app is entirely opt-in.

Morgamic, while I believe that making sure Mozilla maintains out users trust, I think Pascal is right: This heavy-handed response has a drastically chilling effect on creativity within our community.
I hesitate to enter this train wreck, but I note that if we give Atul a list of email addresses to put into the app, the app cannot be described as opt-in.

(As an aside: it's just a phone book, not exactly the bleeding edge.)
Let's put a stop at this - it's getting complicated and we have better things to do with our time.
My opinion:

- let's pick an access password that will be mailed to everyone, 
  but that will not published on web pages, not in the wiki, 
  not mentioned in the newsletter

- tell everyone on the web page:
  "Don't enter any information you consider sensitive and wouldn't publish
   on a public website.

   We'll try to keep this site's content private, 
   but we can't guarantee it will stay that way,
   (We hope that none of the attendees will pass on the access password,
    nor copy and paste the data elsewhere. Please don't.)

   When in doubt, limit the information to the bare minimum.
   And remember, this is opt-in, so if you're worried, don't enter your data."
My proposal in comment 38 is an attempt to keep things simple, but still offer the service to all attendees.

I don't need to know a lot of information about the other people, but I think it would be really helpful to have a place to look for names and faces.

If you're really completely worried, then my backup proposal is:
Limit the page to picture and name.
Wow - this really did get kinda off the rails.

Regarding user data: if we're hosting this off mozilla.com and without a security review, then we should make it clearer (both in the introductory email and in the application itself) that we make no guarantees of data security, and in fact that the data will be made available through many APIs. In fact, we should probably do that wherever it lies.

We can do without the framing of these requests as heavy-handed or accusations in either direction of not being willing to move forward or care about the children. They get us nowhere. There are valid concerns about user data here, and about presenting this as a Mozilla based service to users.

Let's take a moment to clear our heads, everyone.
OK, cooler heads? Great.

Let's pretend comment 33 didn't happen, and this didn't escalate into ultimatums. Has the review happened? Can that happen? You're all in the same building, can you guys just sit next to each other and go over things and see if we can get that part covered so we at least know if this is the type of thing that could be deployed on an internal server?
(In reply to comment #36)
> (As an aside: it's just a phone book, not exactly the bleeding edge.)

Also as an aside, it actually didn't start as that: it actually started as an alternative identity provider that my summit scheduler app [1] could use instead of Twitter, since not everyone attending the Summit has (or wants to have) a Twitter account. After I built the basics and added the notion of user profiles, I showed it to Deb and she pointed me at this bug, which I didn't know existed.

Ultimately I thought it'd be interesting to play around with this idea of an identity-provider-cum-privacy-preserving-mashup-platform, which sounds pretty crazy, but that's why it's a Labs experiment. It would also be incredibly hard to experiment with if every change required security review, so maybe I'll just play around with the idea on my own time as a personal project.

For anyone who's interested, here's the code:

  http://hg.toolness.com/summit-idp/

Feel free to do what you like with it.

[1] https://hg.mozilla.org/users/avarma_mozilla.com/mozsummit-scheduler/raw-file/public/index.html
(In reply to comment #42)
> For anyone who's interested, here's the code:
> 
>   http://hg.toolness.com/summit-idp/
> 
> Feel free to do what you like with it.

Truly, the worst and least collegial outcome, impacting everyone and benefitting no-one. Applause all around, everyone. We all lose.

I'm astonished that we, as a group of people with the same aims and desired outcomes, could not arrange a 30 minute meeting and review of the code to ensure that it met the quality and values that we all hold and care about.

Also: disappointed. I liked Atul's application a lot, and thought it would be a boon to Summit attendees.
(In reply to comment #42)
> (In reply to comment #36)
> > (As an aside: it's just a phone book, not exactly the bleeding edge.)
> 
> Also as an aside, it actually didn't start as that: it actually started as an
> alternative identity provider that my summit scheduler app [1] could use
> instead of Twitter, since not everyone attending the Summit has (or wants to
> have) a Twitter account. 

Hey Atul, your app is cool.  All I meant was that all that was asked for in this bug was a phonebook.  

I'd be happy to participate in a security review of the code if that helps make this happen faster.
(In reply to comment #43)
> Truly, the worst and least collegial outcome, impacting everyone and
> benefitting no-one. Applause all around, everyone. We all lose.

My sincere apologies.  This bug (and project) turned into a mud-fest where I had my fair share of mud-throwing.

Now - let's get the cow off the ice (as we say in Germany):  Atul, can you work with Laura and the WebDev team to get your code security reviewed?  WebDev team - can you let Atul know where and how we can deploy the app in a way which makes sense both from a security PoV as well fits with Atul's need to continue iterating on the app?

Thank you. :)
(In reply to comment #42)
> It would also be incredibly hard
> to experiment with if every change required security review, 

We should just review the version that is planned to be deployed for the summit
("production").    (Security reviews don't get in the way of innovation on the
webdev team, don't fear the reaper ;) )
Just to be clear about the role of security, one of our missions is to protect information; and in this case, it is the employees and community members personal data. Besides the obvious public disclosure aspects of having this information compromised, we should make every effort to make sure it is secure. While I say this our mission, it should be everybody's mission.

So moving forward, we will start the review of this application, it doesn't look that complicated and as Laura has kindly pointed out, it also isn't painful. We are talking about a few hours of security review which isn't much time all things considering. 

Given this is the location of the code, we will start the review now and will post the finding to this bug. 

http://hg.toolness.com/summit-idp/
Sorry for the misunderstanding, everyone. I'm still a bit unclear on how some things will work, but I understand that it's really important that we do our best to ensure that our users' personally-identifiable information isn't compromised.

I've just added a README that will hopefully help with the code review:

  http://hg.toolness.com/summit-idp/file/5cf375ec179e/README.md

Please let me know if you have any questions or suggestions.
Security testing of the application (for major issues) is complete. Most everyone was copied on the security tracker bug (bug 575790)
(In reply to comment #45)
> Atul, can you work
> with Laura and the WebDev team to get your code security reviewed?  WebDev team
> - can you let Atul know where and how we can deploy the app in a way which
> makes sense both from a security PoV as well fits with Atul's need to continue
> iterating on the app?
> 
> Thank you. :)

I wanted to check in here and make sure everything is moving forward ok.  The security review is complete and Atul is on top of making the few changes. 

Also, Atul, do you have everything you need to get the app deployed on a server? I mentioned in comment 23 that you can file a bug to server ops to get that server. If you copy me I will also keep on top of it to ensure it gets resolved quickly.

(from comment 23)
I just asked around and the quickest way is to file the bug to server-ops and
also copy jeremy.orem+bugs@gmail.com (yes, include the +). You can mark it as
"major" too.
I would probably suggest asking for staging + prod servers, just so you have somewhere to test stuff.  Typical setup is staging autosyncing from your repo, but production changes only on a release.
Thanks Laura and Michael, I've created bug 576128 as the server request.
Separately from this discussion I was chatting with Atul about the application, and set up the application to be deployed with Silver Lining, and I have a test deployed onto a Rackspace Cloud server instance.  To use this instance as more than a test it would need a domain name, and if we want to use https then a cert to go with the domain name.  Given the simplicity of the application running staging and production on the same server instance (with different domain names) will be no problem, and I could guide Atul through that, as well as helping Atul do ongoing deployments.

No one has done a security review of the server configuration I'm using.  While a review of that would be great, it may be infeasible before the Summit given the scope (though the server is entirely programmatically configured, so it's fairly reviewable IMHO).  Because the server itself is in no way connected to Mozilla infrastructure the only danger would be a release of the data itself, no compromise of the server could affect anything else at Mozilla (any more than any other compromised server could).

The server itself is in most respects a plain Ubuntu Karmic configuration, and the tools to deploy interact via ssh, so while the configuration is unreviewed it's not an unusual server setup.

Nevertheless, I don't want to derail this process further if Silver Lining adds another complication, so if it gets deployed on an internally-configured server that's fine and I can just delete the instance I have running.
Thanks for this option.

We have the bug in for an internal server and am pushing to get that resolved quickly. Unless we have an unforeseen difficulty the Mozilla hosting route should work and will also provide SSL for the site.
People have mentioned on the IRC channels there is need for something like this, helping people to match faces to names.

Has this died? Any change this can put online today, announce it today, and allow people to find each other tomorrow?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.