Monthly Archives: June 2020

News

The Zooniverse: A Quick starter guide for research teams

Leave a comment

Over the past several months, we’ve welcomed thousands of new volunteers and dozens of new teams into our community.

This is wonderful.

Because there are new people arriving every day, we want to take this opportunity to (re)introduce ourselves, provide an overview of how Zooniverse works, and give you some insight on the folks who maintain the platform and help guide research teams through the process of building and running projects.

Who are we?

The core Zooniverse team is based across three institutions:

  • Oxford University, Oxford UK
  • The Adler Planetarium, Chicago IL
  • The University of Minnesota-Twin Cities, Minneapolis MN

We also have collaborators at many other institutions worldwide. Our team is made up of web developers, research leads, data scientists, and a designer.

How we build projects

Research teams can build Zooniverse projects in two ways.

First, teams can use the Project Builder to create their very own Zooniverse project from scratch, for free. In order to launch publicly and be featured on zooniverse.org/projects, teams must go through beta review, wherein a team of Zooniverse volunteer beta testers give feedback on the project and answer a series of questions that tell us whether the project is 1) appropriate for the platform; and 2) ready to be launched. Anyone can be a beta tester! To sign up, visit https://www.zooniverse.org/settings/email. Note: the timeline from requesting beta review to getting scheduled in the queue to receiving beta feedback is a few weeks. It can then take a few weeks to a few months (depending on the level of changes needed) to improve your project based on beta feedback and be ready to apply for full launch. For more details and best practices around using the Project Builder, see https://help.zooniverse.org/getting-started/.

The second option is for cases where the tools available in the Project Builder aren’t quite right for the research goals of a particular team. In these cases, they can work with us to create new, custom tools. We (the Zooniverse team) work with these external teams to apply for funding to support design, development, project management, and research.

Those of you who have applied for grant funding before will know that this process can take a long time. Once we’ve applied for a grant, it can take 6 months or more to hear back about whether or not our efforts were successful. Funded projects usually require at least 6 months to design, build, and test, depending on the complexity of the features being created. Once new features are created, we then need additional time to generalize (and often revise) them for inclusion in the Project Builder toolkit.

To summarize:

Option 1: Project Builder

  • Free!
  • Quick!
  • Have to work with what’s available (no customization of tools or interface design)

Option 2: Custom Project

  • Funding required
  • Can take a longer time
  • Get the features you need!
  • Supports future teams who may also benefit from the creation of these new tools!

We hope this helps you to decide which path is best for you and your research goals.

Technical

Caesar Subject Rule Effect Vulnerability Report

Leave a comment

In the beginning of April 2020, we were notified that subjects from one Zooniverse project were appearing in the subject set of a separate project where they did not belong. In our investigation of the issue, our team determined that this behavior was being caused by a Caesar configuration mistake that used an incorrect Subject Set ID. Project owners using Caesar were able to create Subject Rule Effects that added subjects to collections or subject sets, even without proper subject set editing permissions. We have rectified the issue surrounding Subject Rule Effects and eliminated this vulnerability, and would like to share the details for anyone who is interested.

The issue was raised by project lead James Perry (@JamesPerry), who reported that subjects that didn’t belong to his project were appearing in his subject sets.  Due to a mistyped subject set ID in a Caesar `add_to_subject_set` effect for an unrelated project, that Subject Rule Effect was sending subjects from that project to one of James’s subject sets instead of the correct target.

Our immediate course of action was to fix the project impacted by the vulnerability, and push out a temporary code fix to prevent the vulnerability from being exploited. 

  1. To fix the affected project, we updated the incorrect subject set id for the project that was incorrectly sending subjects to the wrong project and removed the unwanted subjects from the set. 
  2. On April 3rd we deployed a temporary code fix to disable Subject Rule Effect creation and modification for all but admin users (see PR #1109). This change was communicated to affected teams that were most impacted by the change, and teams that reached out after seeing our notification banner or encountering a Caesar interface error.

On May 15th we pushed out a permanent fix that checked the user has permissions to send data to the target subject set or collection. Specifically, the updated validation code checks that the user has update permissions on the project the subject set or collection is linked to. (see PRs #1115, #1129 and #1131). 

For anyone running their own hosted copy of Caesar, we recommend pulling these changes as soon as you’re able.