I just asked Andrew Stillman and Jesse Spevack privately, but I thought I would share it with this community as…

I just asked Andrew Stillman and Jesse Spevack privately, but I thought I would share it with this community as well, as I know how many of you folks might have insights too.

 

In Denver, we are in our first full year of implementing GAFE and are really trying to do a tightrope walk of Student Data privacy. I wanted to ask about the “Drive Apps” that you can globally allow or disallow for Google Drive within the GAFE domain. The settings is shown below.

We currently have this turned off because we are very aware that Google Drive apps have a variety of permissions that they request, and we are trying to figure out how to best comply with our guidance for Student Data Privacy and only allowing the “good apps” to have the permissions they need in order to do the great work allowed within Google Drive.

Do you have any thoughts around how to ensure we can do right by our kids in terms of access to the right tools and ensure that we aren’t giving out student (or teacher, for that matter) data to the “third party apps”? 

Thanks in advance for any help you might be able to provide.

cc

Josh Allen Joshua Allen Kirk Anderson Kirk Anderson Nate Obee 

12 Comments

  1. I’m curious as to what insights Andrew Stillman or Jesse Spevack offered. This helps after the fact http://googleappsupdates.blogspot.com/2014/11/increased-visibility-and-control-with.html

    but we need a way to be proactive. Ideally we need a way to pre-approve apps AND add-ons that do not collect student data (beyond a username). Without that piece in place I don’t see how one can be FERPA compliant and allow students to add apps and add-ons at their discretion.  

  2. I’m curious as to what insights Andrew Stillman or Jesse Spevack offered. This helps after the fact http://googleappsupdates.blogspot.com/2014/11/increased-visibility-and-control-with.html

    but we need a way to be proactive. Ideally we need a way to pre-approve apps AND add-ons that do not collect student data (beyond a username). Without that piece in place I don’t see how one can be FERPA compliant and allow students to add apps and add-ons at their discretion.  

  3. I’m curious as to what insights Andrew Stillman or Jesse Spevack offered. This helps after the fact http://googleappsupdates.blogspot.com/2014/11/increased-visibility-and-control-with.html

    but we need a way to be proactive. Ideally we need a way to pre-approve apps AND add-ons that do not collect student data (beyond a username). Without that piece in place I don’t see how one can be FERPA compliant and allow students to add apps and add-ons at their discretion.  

  4. I’m curious as to what insights Andrew Stillman or Jesse Spevack offered. This helps after the fact http://googleappsupdates.blogspot.com/2014/11/increased-visibility-and-control-with.html

    but we need a way to be proactive. Ideally we need a way to pre-approve apps AND add-ons that do not collect student data (beyond a username). Without that piece in place I don’t see how one can be FERPA compliant and allow students to add apps and add-ons at their discretion.  

  5. Here’s what I had to say:  

    “Unfortunately “Allow users to install Drive Apps” is a blanket, all-or-nothing, domain-wide setting.  E.g. it’s not even OU-granular.  Furthermore, Add-ons that rely on the Drive API are lumped into “Drive Apps” for the purposes of security.

    I could understand there being a couple of arguments here.  

    I’m not a lawyer, but my understanding is that FERPA asks schools and districts to take reasonable precautions to protect student privacy within the context of their educational mission, not to eliminate all exposure risks at all costs.  I think this means that LEAs have a fairly wide berth to interpret how FERPA applies to technology policy.  

    One interpretation vis a vis Drive app installations could be for the district to review the TOS and privacy of various popular Drive Apps and maintain and distribute a whitelist to teachers… perhaps also providing a way for teachers to request new Apps to be added to the list.   

    Whether or not you monitor user behavior could be up for interpretation.  If this is considered an important precaution, you could opt for something like CloudLock Apps Firewall and auto-disable Drive Apps not on the whitelist.

    I’d also strongly recommend logging a support ticket (feature request) with Google support and also pressing the issue with the EDU product managers at Google, since you are a large district and this “all or nothing” quality of Drive Apps really doesn’t stand up to a more risk-averse interpretation FERPA. If you are assertive on this stuff (and it doesn’t hurt to be a reasonably large district, and a strong influencer in the community like y’all) Google will listen.”

    I’ve since learned that domain whitelist for Add-ons is in the works (no timeline available) and that this will pre-empt the Drive App settings for those apps, so districts will be able to blanket approve specific Drive-enabled Add-ons without giving carte blanche to users on all Drive Apps.

  6. Here’s what I had to say:  

    “Unfortunately “Allow users to install Drive Apps” is a blanket, all-or-nothing, domain-wide setting.  E.g. it’s not even OU-granular.  Furthermore, Add-ons that rely on the Drive API are lumped into “Drive Apps” for the purposes of security.

    I could understand there being a couple of arguments here.  

    I’m not a lawyer, but my understanding is that FERPA asks schools and districts to take reasonable precautions to protect student privacy within the context of their educational mission, not to eliminate all exposure risks at all costs.  I think this means that LEAs have a fairly wide berth to interpret how FERPA applies to technology policy.  

    One interpretation vis a vis Drive app installations could be for the district to review the TOS and privacy of various popular Drive Apps and maintain and distribute a whitelist to teachers… perhaps also providing a way for teachers to request new Apps to be added to the list.   

    Whether or not you monitor user behavior could be up for interpretation.  If this is considered an important precaution, you could opt for something like CloudLock Apps Firewall and auto-disable Drive Apps not on the whitelist.

    I’d also strongly recommend logging a support ticket (feature request) with Google support and also pressing the issue with the EDU product managers at Google, since you are a large district and this “all or nothing” quality of Drive Apps really doesn’t stand up to a more risk-averse interpretation FERPA. If you are assertive on this stuff (and it doesn’t hurt to be a reasonably large district, and a strong influencer in the community like y’all) Google will listen.”

    I’ve since learned that domain whitelist for Add-ons is in the works (no timeline available) and that this will pre-empt the Drive App settings for those apps, so districts will be able to blanket approve specific Drive-enabled Add-ons without giving carte blanche to users on all Drive Apps.

  7. Here’s what I had to say:  

    “Unfortunately “Allow users to install Drive Apps” is a blanket, all-or-nothing, domain-wide setting.  E.g. it’s not even OU-granular.  Furthermore, Add-ons that rely on the Drive API are lumped into “Drive Apps” for the purposes of security.

    I could understand there being a couple of arguments here.  

    I’m not a lawyer, but my understanding is that FERPA asks schools and districts to take reasonable precautions to protect student privacy within the context of their educational mission, not to eliminate all exposure risks at all costs.  I think this means that LEAs have a fairly wide berth to interpret how FERPA applies to technology policy.  

    One interpretation vis a vis Drive app installations could be for the district to review the TOS and privacy of various popular Drive Apps and maintain and distribute a whitelist to teachers… perhaps also providing a way for teachers to request new Apps to be added to the list.   

    Whether or not you monitor user behavior could be up for interpretation.  If this is considered an important precaution, you could opt for something like CloudLock Apps Firewall and auto-disable Drive Apps not on the whitelist.

    I’d also strongly recommend logging a support ticket (feature request) with Google support and also pressing the issue with the EDU product managers at Google, since you are a large district and this “all or nothing” quality of Drive Apps really doesn’t stand up to a more risk-averse interpretation FERPA. If you are assertive on this stuff (and it doesn’t hurt to be a reasonably large district, and a strong influencer in the community like y’all) Google will listen.”

    I’ve since learned that domain whitelist for Add-ons is in the works (no timeline available) and that this will pre-empt the Drive App settings for those apps, so districts will be able to blanket approve specific Drive-enabled Add-ons without giving carte blanche to users on all Drive Apps.

  8. Here’s what I had to say:  

    “Unfortunately “Allow users to install Drive Apps” is a blanket, all-or-nothing, domain-wide setting.  E.g. it’s not even OU-granular.  Furthermore, Add-ons that rely on the Drive API are lumped into “Drive Apps” for the purposes of security.

    I could understand there being a couple of arguments here.  

    I’m not a lawyer, but my understanding is that FERPA asks schools and districts to take reasonable precautions to protect student privacy within the context of their educational mission, not to eliminate all exposure risks at all costs.  I think this means that LEAs have a fairly wide berth to interpret how FERPA applies to technology policy.  

    One interpretation vis a vis Drive app installations could be for the district to review the TOS and privacy of various popular Drive Apps and maintain and distribute a whitelist to teachers… perhaps also providing a way for teachers to request new Apps to be added to the list.   

    Whether or not you monitor user behavior could be up for interpretation.  If this is considered an important precaution, you could opt for something like CloudLock Apps Firewall and auto-disable Drive Apps not on the whitelist.

    I’d also strongly recommend logging a support ticket (feature request) with Google support and also pressing the issue with the EDU product managers at Google, since you are a large district and this “all or nothing” quality of Drive Apps really doesn’t stand up to a more risk-averse interpretation FERPA. If you are assertive on this stuff (and it doesn’t hurt to be a reasonably large district, and a strong influencer in the community like y’all) Google will listen.”

    I’ve since learned that domain whitelist for Add-ons is in the works (no timeline available) and that this will pre-empt the Drive App settings for those apps, so districts will be able to blanket approve specific Drive-enabled Add-ons without giving carte blanche to users on all Drive Apps.

Leave a Reply