Virtual Classrooms and Real Harms - arXiv
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Shaanan Cohney, Ross Teixeira, Anne Kohlbrenner, Arvind Narayanan, Mihir Kshirsagar, Yan
Shvartzshnaider, and Madelyn Sanfilippo
Virtual Classrooms and Real Harms
Abstract: Universities have been forced to rely on re- surfacing a deeper disconnect between educational goals
mote educational technology to facilitate the rapid shift and the incentives of the software platforms.
to online learning. In doing so, they acquire new risks of We begin by documenting how different ac-
security vulnerabilities and privacy violations. To help tors in educational settings—students, educators, and
universities navigate this landscape, we develop a model administrators—each bring their own set of preferences
that describes the actors, incentives, and risks, informed and concerns about platforms. These concerns conflict,
by surveying 105 educators and 10 administrators. Next, leaving educators and students frustrated that the plat-
arXiv:2012.05867v1 [cs.CR] 10 Dec 2020
we develop a methodology for administrators to assess forms do not meet their needs. We identify specific pref-
security and privacy risks of these products. We then erences and concerns from surveys we conducted of 105
conduct a privacy and security analysis of 23 popular educators and 10 administrators, primarily from the US,
platforms using a combination of sociological analyses of leaving a survey of students for future work.
privacy policies and 129 state laws, alongside a technical Next, we compare the privacy and security practices
assessment of platform software. Based on our findings, of platforms identified in the survey to the concerns
we develop recommendations for universities to mitigate of our stakeholders. To do so we evaluate both client-
the risks to their stakeholders. side software and platform policy documents, including
50 Data Protection Addenda (DPAs). We analyze client
software by examining relevant executable binary fea-
tures and capturing network traffic to check if the im-
1 Introduction plementations adhere to best practices. In contrast, our
discussion of privacy uses a sociological framing to eval-
The COVID-19 pandemic pushed universities to adopt uate how the legal documents in our corpus reflect gover-
remote communication services. But most of these plat- nance. We find that there are substantial gaps between
forms were not designed with universities in mind. the expectations of our stakeholders and the reality of
While these platforms allowed institutions to fill an ur- the platforms they use.
gent need, they caused novel and well-publicized secu- Our results allow us to identify three underlying fac-
rity and privacy problems. While the media has reported tors that contribute to the problems we observe. First,
on a subset of these problems (among them the penetra- there are unresolved tensions between the needs of the
tion of tracking features into the virtual classroom and different stakeholders—as extracted from of our survey
“Zoombombing”), the underlying causes of these prob- of educators. For example, educators’ stated preferences
lems have gone unexamined. Our work identifies institu- for students’ cameras to be left on conflicts with stu-
tional structures that make these incidents more likely, dents’ privacy concerns about misuse of their video feeds.
Second, there are significant gaps between users’ prefer-
ences for platform behavior and the actual practices of
the platform.
Shaanan Cohney: Princeton University, A recurring theme in our survey was that defaults
shaanan@cohney.info matter. While developers may include a configuration
Ross Teixeira: Princeton University, rapt@cs.princeton.edu toggle for stricter security settings (such as storing call
Anne Kohlbrenner: Princeton University, akohlbren-
recordings locally vs. to a cloud), if this toggle is not
ner@cs.princeton.edu
turned on by default or communicated clearly to educa-
Arvind Narayanan: Princeton University,
arvindn@cs.princeton.edu tors, its usefulness is significantly hampered. A related
Mihir Kshirsagar: Princeton University, mi- issue is that faculty often adopt tools on their own ini-
hir@princeton.edu tiative, outside official procurement processes which de-
Yan Shvartzshnaider: Princeton University / New York prives them of protections afforded to large organiza-
University, yansh@cims.nyu.edu
tions. Third, there is a regulatory gap created because
Madelyn Sanfilippo: Princeton University / New York Uni-
versity, madelyns@illinois.edu the existing educational privacy and data security regu-
lations were written for an era of paper-based records inVirtual Classrooms and Real Harms 2
physical classrooms and are not a good fit for regulating recognition of the variety of roles that individuals in
practices arising out of remote learning. that class may play.
Our construction of a threat model is complicated
by the fact that a platform component may seem both
Contributions: a ‘feature’ and a ‘threat’ to different actors (e.g. video
recording). Platform developers must not only build a
• We build a novel threat model that corresponds to secure product, but one that mediates between the dif-
university and user expectations. We ground our ferent interests of their users. As a result, our model
model in two qualitative surveys we conduct of edu- moves beyond a trusted/untrusted dichotomy to exam-
cators and college and university IT administrators ine the incentives and interests of all actors.
located mostly in the United States. We begin by describing our threat model to under-
• We assess the privacy and security practices of 23 stand how the participating actors view their interests.
of the most popular platforms identified in our sur- Next, we model the different risks that platforms must
vey. In particular, our analysis identifies a mismatch mitigate to help fulfill the educational mission of the
between user expectations and platform behavior, software. Finally, we conclude by analyzing the survey
finding notable differences between platforms oper- results that inform our threat model.
ated under contract with universities, and the same
platforms provided to users free of charge. While
it is natural to expect some divergence in features 2.1 Actors
between enterprise and free versions, we find that
contracts negotiated with universities can lead to We divide the participating actors into internal actors
additional, significant differences in data handling (students, educators, administrators), and external ac-
from university to university, as well as from plat- tors (third parties and adversaries). While each class of
form to platform. In particular, we find that DPAs internal actors has incentive to maintain the integrity
are a powerful tool to shape platform behavior to- of the educational system, we recognize that all inter-
wards the interests of the stakeholders. nal actors may engage in adversarial behavior. In addi-
• We use our research to provide policy guidance. tion, our survey shows how the priorities of the internal
We recommend that universities should not focus actors may differ—leading to behavior by one internal
their energies on an expensive and thorough selec- actor which may be considered adversarial by another
tion process. That is an unrealistic and inefficient actor.
model given the speed with which user practices Incentives. Students enroll for reasons beyond the pur-
and platform features change. Instead, we recom- suit of education goals. Further, diplomas have a creden-
mend building a system for incorporating continual tialing function which for some students may incentivize
improvements based on user feedback and allowing cheating. Mixed incentives may therefore cause a stu-
educators to select features that are relevant to indi- dent to act contrary to other stakeholders’ interests.
vidual educational missions. Recognizing the impor- Administrators who do not use platforms do not
tance of defaults, we recommend that each institu- share the personal stakes of educators and students. As
tion evaluate the default settings given to educators. non-participants in the digital classroom, administra-
We also recommend strengthening regulatory mech- tors may be more willing to sacrifice the privacy con-
anisms to provide appropriate baseline privacy and cerns of students and educators for institutional con-
security protections. cerns such as cost efficiencies and auditing or reporting
capabilities. Administrators commonly endorse cloud so-
lutions such as Canvas which monetize aggregate data
2 Actors, Incentives, & Risks about students, representative of trade-offs between dif-
ferent actors’ priorities.
In the domain of education technology, actors within the While our model groups all administrators together,
system simultaneously embody potential threats and they too are not homogeneous. Those whose roles focus
principals to protect. A useful threat model should there- on compliance and risk assessment have incentives to
fore specify the level of trust to assign to each actor, in prioritize security and privacy concerns, while others
prioritize usability and teaching outcomes. This high-
lights a limitation of our model, which draws boundariesVirtual Classrooms and Real Harms 3
or unintentional when platforms leak sensitive infor-
Students Educators/
mation (such as indicators of socio-economic status
Institutions leaked via video streams).
end-to-end
encryption • Educators and administrative staff. Such ac-
tors generally manage instances of the various plat-
forms (such as individual chat rooms/streams), and
stu nviro
me e
are thus privileged and trusted to a significant ex-
on om
possible
leakage
e
de nm
nt
vir ’ h
nts en
tent. Yet, even well-intentioned educators may in-
en ents
’ ho t
advertently breach student or institutional expecta-
d
me
stu
tions of privacy when faced with the unfamiliar set-
ting of the virtual classroom. Similarly, educators
Platforms “Z can precipitate security breaches if their accounts
l
are over privileged.
ria
ata
oo
co
all
ate
mb
urs
td
stu
• Service providers and their third-party affili-
em
en
om
em
de
tud
bin
urs
nt
ates. We assume that service providers and their af-
ate
s
da
g”
co
ria
all
ta
filiates will act to maximize their economic interest
l
Third Parties Adversaries within the bounds of their contractual and legal obli-
gations. Platforms may share metadata with third
Data from Data from Data from
educators students adversaries parties for advertising and other business purposes,
and course material for services like captioning.
= appropriate flows
• External adversaries. External adversaries may
seek to steal student data and course content, and
Fig. 1. We model typical data flows between our stakeholders as may interfere with live classes (“Zoombombing”).
mediated by online platforms. A flow is considered appropriate if
Adversaries may act for profit, entertainment, or
it corresponds to a legitimate flow under the Contextual Integrity
framework we develop in Section 3. The flow marked end-to-end other motives.
encryption represents data that is not ordinarily accessible to
the platform. However, poor configuration, implementation, or Figure 1 depicts these actors and their interactions.
metadata collection may cause data to leak to platforms.
2.2 Survey Results
between educators, administrators, and students, when
there are often instances in which those roles overlap— We surveyed 105 higher education educators to learn
for example, graduate students who teach or TA or se- about what remote learning platforms they use, the fea-
nior faculty who serve as administrators. tures they value in a platform, and their concerns (and
Under these assumptions, we produce the following those of their students), with particular emphasis on
set of descriptions about the behaviors of our actors: privacy and security. We recruited participants through
• Students. Students authenticate their identities a public Slack group for educators teaching remotely,
and participate in courses by joining live virtual ses- as well as through social media. We report the number
sions and submitting work. Students may also col- of educators using each platform, as well as whether
laborate and share work with each other. Students they use a personal version or an institutionally pro-
may share extraneous information—including their vided version in Figure 2, motivating our examination of
home environment—through video conferences that the divergences between school-supported and personal
propagate to instructors (and which may leak to versions of platforms. Separately, we surveyed ten uni-
platforms if conferences are not end-to-end en- versity administrators about their schools’ procurement
crypted). We do not assume that students are processes for new learning platforms. As administrators
trusted. That is, people with student-level permis- with influence and understanding of the procurement
sions may try to access or change data not autho- process are harder to reach, our sample size was limited
rized for them, or to prevent access to systems. We to 10 participants.
also note that students may participate in privacy We find that the concerns of educators generally
violations [34]. Violations may be intentional when touch on three major themes, with some instructors
students exploit the data-rich platforms we consider mentioning multiple themes. First, students’ personalVirtual Classrooms and Real Harms 4
Fig. 2. Survey results for usage counts for remote teaching platforms divided by institution-supported versions and personal versions.
Our results show that many educators eschewed institutionally-licensed software in favor of free versions.
data is more easily captured and visible to educators, issues consistently. Notably, each of our five freeform
platforms, co-inhabitants, and other students from a questions, including those unrelated to privacy or se-
virtual classroom. This includes students broadcasting curity, received at least two responses that we manu-
their home environments (and socioeconomic indicators ally coded as pertaining to a privacy or security con-
therein) through video, private chats which may leak to cern. Fourteen discussed concerns that private chats
instructors, and co-inhabitants hearing sensitive class or videos were not private; eleven were concerned
material. It also includes proctoring services that hi- that platforms did not adequately secure meetings
jack students’ computers while monitoring their envi- against intrusion, while two specifically mentioned
ronment. concerns about theft of intellectual property.
Second, personal data is more easily disseminated • Educators were concerned about the surveillance im-
by platforms to third parties, with little recourse for plications of using remote learning tools. For exam-
students or educators who wish to limit data sharing. ple, five educators noted they were concerned plat-
Instructors were concerned that platforms may sell stu- forms might share data with third parties, with par-
dent metadata to advertisers or leak data to services like ticular emphasis on course data and personal data of
video captioning, and that law enforcement may request students. Another respondent denounced potential
student data from platforms. data sharing with law enforcement. Thirteen educa-
Third, platforms are vulnerable to attack from unin- tors reported a general discomfort with video record-
tended adversaries that threaten to steal data and inter- ings, comparing it to surveillance. Relatedly, sixteen
fere with courses, due to poor authentication and other educators reported it was important that platforms
security measures by platforms. provided the ability to save local (rather than cloud)
Specific highlights from our educator survey in- recordings of the video feeds for students who were
clude: unable to participate synchronously.
• Respondents also expressed concerns about the abil-
• The responses of the 43 educators who expressed ity to control features of the platform. Seven instruc-
specific concerns about privacy or security fell tors noted their frustration with features which are
largely into a bimodal distribution, splitting be- actually configurable (such as poor video conference
tween educators that sought features and functions security). We hypothesize that these instructors did
to replicate experiences within physical classrooms not realize that they could change the platform’s be-
as well as possible, and educators that wanted to havior in these cases. Three respondents mentioned
redesign courses and optimize for the online setting. missing features of a platform which were available
The former group expressed greater dissatisfaction at another institution, while 14 were dissatisfied
with default settings and raised more concerns. with the privacy or security features of tools avail-
• Respondents did not clearly delineate between secu- able at their institution. This extends to the differ-
rity and privacy, but expressed concerns about those ence between individually licensed versions of soft-Virtual Classrooms and Real Harms 5
ware (that our survey shows educators often use), 3 Privacy Analysis
and institutionally supported versions.
As students attend a remote lecture or communicate
While our administrator survey had only 10 respon- with their peers, platforms can collect and analyze their
dents, it surfaced issues about how their institutions attention, location, chat, and video. Because the cost of
select software—issues other universities are likely to data collection is low and there is less friction to col-
share. Five administrators reported that their institu- lect such data compared to the offline context, the plat-
tions did not have a formal process for selecting new forms end up collecting vast amounts of data through
platforms, while one reported a price threshold for in- user interactions. These practices, despite ostensibly be-
voking a more formal process. The survey showed that ing compliant with the existing regulations, can conflict
the platform selection process was driven by Faculty and with with contextual educational privacy norms and ex-
IT staff. Two administrators reported having processes pectations.
for collecting feedback from faculty on learning plat- Given that the expectations and interests of the rele-
forms, but one emphasized that re-evaluation of whether vant actors are complex, conflicting, and overlapping (as
a platform met needs would only happen at the time discussed relative to incentives in Section 2.2), we adopt
of “contract renewal.” Further, “legal obligations” were descriptive institutional analysis frameworks [27, 51]
only moderately important to administrators, implying to structure our analysis of governance. We also use
that other actors are likely responsible for compliance. the Contextual Integrity framework to understand how
Four administrators rated a platform’s privacy features stakeholder expectations change when the physical class-
as extremely or very important. Three of those four con- room becomes digital. CI views privacy as the appro-
sidered security equally important, while one found se- priate flow of information, where appropriateness is de-
curity only slightly important. Three administrators de- fined by the governing contextual norms. We draw on
scribed negotiating for more privacy guarantees such as the survey responses to identify which information han-
DUO and HIPAA compliance. dling practices are appropriate in the educational con-
One administrator also noted that sharing responses text. Our analysis begins by identifying the preferences
to HEVCATs (Higher Education Community Vendor and expectations of educators, administrators, and stu-
Assessment Toolkit) [25] between universities enabled dents that coalesce as contextual educational norms. We
them to better assess platforms’ suitability. According then analyze structures and constraints that govern how
to our administrators, the most significant change rel- actors in that setting behave. We describe the rules en-
ative to COVID-19 was not procurement of additional forced and norms formalized in federal and state level
video platforms, as that infrastructure had already been regulations; norms, rules, and strategies defined in uni-
licensed and could service that demand. Rather, admin- versity contracts and prescribed by platform privacy
istrators experienced demand to fill new needs, such as policies; and norms articulated by educators.
proctoring software for “high-stakes testing.”
The next two sections discuss the primary risks iden-
tified in our surveys. In Section 3, our privacy analy- 3.1 Law
sis uses the lens of Contextual Integrity (CI) [39] to
understand where the pandemic has disrupted norms Legal regulations have a significant role in shaping the
for appropriate information flows. We observe that the governance of the privacy practices of large internet plat-
traditional privacy norms regarding paper educational forms. Yet, current laws do not sufficiently control plat-
records (or their digital equivalents) are poorly suited form behavior to conform to the privacy norms of higher
to the ‘data exhaust’ that online communication gener- education. For a university to achieve the kind of control
ates [64]. In Section 4 we discuss the security threats over a platform’s information practices that fits within
that compromise digital systems through unauthorized the spirit (if not the actual application) of federal and
access. We examine how unauthorized third parties state laws, it must take active and intentional supple-
could gain access to (or disrupt) educator-student com- mentary governance interventions, such as by customiz-
munications by looking at network traffic, evaluating ing DPA as we discuss in Section 3.3.
mobile device permissions, and assessing the security
characteristics of the desktop software. We also discuss
how developers have responded to known vulnerabilities
to protect systems from unauthorized access.Virtual Classrooms and Real Harms 6
3.1.1 Background information types and information recipients. But the
rules and formal norms do not translate well to the
We provide a brief overview of the primary legal frame- digital environment, and do not specify transmission
works in the United States that apply specifically to principles—when transmitting data is appropriate or
student privacy. who are permissible senders or recipients of data trans-
Federal Regulation. The Family Educational missions [64]. In particular, FERPA does not supply
Rights and Privacy Act (FERPA) [9] protects defined any specific guidance about what educational technol-
categories of student records and data connected with ogy platforms can do with the data they generate and
enrollment at an educational institution [47]. The law, collect about students. However as “designated school
enacted in 1974, was designed for a paper-based record officials” they may only share that data with other such
system with discrete and limited set of records. Critics officials. The implication is that other third-party shar-
argue that the law struggles to regulate the transition ing is not permissible.
to an digital environment that constantly generates a State Regulations. State privacy legislation af-
stream of records related to the student [64]. fects platform practices. This includes both general pri-
FERPA requires schools and universities to keep vacy laws (most prominently the California Consumer
records of each external disclosure of student informa- Privacy Act (CCPA) [10]) as well as specific laws that
tion and requires the records to be available on request regulate student privacy. Specifically, 45 states (which
by the subject [9]. FERPA regulates information sharing for our purposes includes Washington D.C.) have more
by requiring that the institution gets explicit affirmativethan 129 educational privacy laws [13, 20], some of
consent to share data with third parties that fall outside which regulate school and student interaction or data
listed exceptions. If the documentation a platform pro- collection by digital platforms [13].
vides does not concretely describe how it shares user Many state laws take inspiration from California’s
data with partners or advertisers, it may run afoul of Student Online Personal Information Protection Act
the regulation. (SOPIPA) [5] of 2014, which was intended to compre-
FERPA only applies to organizations that receive hensively cover K-12 student privacy concerns. SOPIPA
federal funds under certain educational programs. It is was notable as it imposed responsibilities on platforms
mainly enforced when the Department of Education de- and providers, in addition to schools. That direct liabil-
termines that a school or university is in violation. The ity on platforms and providers was in notable contrast
department then enforces FERPA by withholding fed- to FERPA, which imposed burdens only on the educa-
eral funds until they come back into compliance. tional institutions.
FERPA specifies what student information can be
shared with whom and under what conditions, distin-
guishing between situations in which consent is required, 3.1.2 Findings
and those in which it is not. The act permits schools to
disclose records to contractors under certain conditions: We aggregated 129 state educational privacy laws, as
third-parties must be under the educational institution’s tracked by Student Privacy Compass [20] and the Center
direct control, and must be designated as school officials for Democracy and Technology (CDT) [13] and coded
having “legitimate educational interests.” them to identify and compare information flows and
FERPA’s other notable carve out for data sharing governance patterns, through a combination of manual
is for directory information—“name, address, telephone and hybrid tagging, drawing on established methodolo-
number, date and place of birth, honors and awards, and gies [23, 54]. We present summary data and publish
dates of attendance”—which can be shared so long as ad- the corpus alongside this work at https://github.com/
equate notice and opportunity to request non-disclosure edtech-corpus/corpus.
is provided [9]. Note that Universities must maintain Almost all states in the corpus had laws that re-
records of when they share directory information shar- quired significant transparency about data sharing prac-
ing. In all other instances, explicit consent is required, tices. 5 states out of the 50 allowed students and fam-
corresponding to a norm that privileges student privacy ilies to opt-out of personal information sharing across
without informed consent. FERPA reinforces this norm the board without making a case-by-case determination.
throughout its provisions on disclosure and consent. 11 states require affirmative consent, opting-in, to share
While broad in scope, FERPA is limited to a general some categories of or all personal information with any
set of expectations that addresses specific categories of recipients outside the school district. 21 state laws in-Virtual Classrooms and Real Harms 7
cluded bans on targeted advertising. 6 states were not
– Apple Classroom – GoToMeeting
present in our data set as they had not passed any ap-
Apple Facetime – Microsoft Teams
plicable student privacy laws. Apple Schoolwork Microsoft Skype
Many of the state privacy laws define student data – Blackboard – Microsoft Skype for Busi-
quite broadly without regard to the technology used. As – Blackboard Collaborate ness
a result, the regulations do not provide specific guidance – BlueJeans – Panopto
– Canvas – Piazza
for how to manage the types of data transmitted and
– Jitsi – Slack
stored during an online lesson. An alternative approach
– G Suite for Education – WebEx Meetings
tried by some states was to exhaustively list education Google Classroom – Zoho Meeting
technologies foreseeable at time of passage of their law – Google Hangouts – Zoom
and provide more specific guidance. But these regula- Google Meet
tions typically exclude or overlook video-conferencing.
Table 1. The 23 platforms whose policies we examined. There
Among the laws we evaluated, those of Rhode Island were fewer policies than products, as some firms (such as Mi-
and Virginia were among the few that made explicit al- crosoft) have monolithic policies that apply to groups of prod-
lowances for video technology, so long as platform data ucts.
practices remained within rigid context-specific parame-
ters for educational uses. In contrast, the broad prohibi-
tions against the use of social electronic communication Universities can fill gaps by introducing their own
technology between students and educators in Texas, un- polices and rules, as well as by extracting binding com-
der Education Code §38.027, could be read to prohibit mitments from commercial partners through contracts.
the use of video communications between teachers and We explore use of these binding commitments in Sec-
students [40]. tion 3.3.
A more pervasive issue underlying these laws is that
they have limited enforcement mechanisms or penalties
for misconduct. State laws had no “private right of ac- 3.2 Privacy Policies
tion”, meaning that the laws did not grant students or
their guardians the right to sue if a provider violates Platforms self-regulate through self-imposed privacy
the law. The main path to enforcement is left to state policies, which we evaluate in this section.
attorneys general, who have limited resources to pursue Platforms structure and disclose sharing with other
breaches. Thus, there are few incentives to police com- third-parties through these privacy policies, which both
pliance with state legal requirements. may restrict information flows while containing broad
language that hedges on specifics. Common sources of
flows to third parties include integration between plat-
3.1.3 Analysis forms or sharing of data for analytics and marketing.
Regulation at the state level is often more precise than
FERPA in addressing specific aspects of digital infor- 3.2.1 Findings
mation flows, limiting platforms as information senders
and recipients, as well as articulating clearer transmis- We manually coded privacy policies for 23 platforms,
sion principles. Although state level regulations tend to which corresponded to 17 integrated policies as shown
specify more details with respect to permitted informa- in Table 1.
tion flows in and out of the respective platforms, this Of the platforms, 13 were mainly available as enter-
layer of governance varies across states and places the prise products, typically requiring institutional support,
burden of compliance on universities rather than the and 10 could be adopted at will by individual educators.
platforms. Moreover, these state laws were primarily de- We annotated each policy based on the parameters
signed for the the K-12 context, leaving substantial gaps of Contextual Integrity to classify and describe infor-
in the regulatory framework. mation flows between users, platforms, and third-party
As FERPA does not regulate how platforms use entities.
data, focusing instead on schools and universities, plat- The policies we collected serve both as a source of
forms used in higher education have leeway to use and empirical information about patterns in platform prac-
abuse educational data once it enters their custody.Virtual Classrooms and Real Harms 8
tices and a series of case studies that reflect differing Description Frequency
governance practices. Third Party Sharing
We summarize our results in Table 2. Burden on users to monitor third-parties 9 (52%)
May share personal data with advertisers 7 (41%)
Third Party Sharing. 9 of 17 platforms explic-
Bi-directional sharing 6 (35%)
itly informed users that the burden was on the user May collect personal data from social media 7 (41%)
to monitor third party firms whose products were in- Location Sharing
tegrated with the primary platform. 3 platforms spec- Explicitly permit location tracking 10 (58%)
ified that agreements with third-party providers pro- May share location data with third-parties 4 (23%)
vided some privacy protections. The remaining 11 were Collect location data outside device-provided 5 (28%)
unclear about third party sharing. Table 2. We identified the privacy practices of 23 platforms from
Where a policy applied to EU citizens, the text 17 different privacy policies. There are fewer policies than plat-
forms as products owned by a common firm typically shared a
would typically specify that third parties were also
policy, indicated by a single bullet spanning multiple platforms1.
bound to the protections offered by the platform.
While sharing an ID may seem innocuous, student
IDs in have long served multiple functions, many of
Location Sharing. Of the 17 policies we evalu-
them security sensitive. Blackboard’s integration policy
ated, 10 policies permitted location tracking, 4 explicitly
notably permitted Blackboard to share school-provided
stated they did not track location, and 1 was unclear.
student IDs with partners.
Of the 10 that collected location data 4 policies al-
7 of 17 platform policies allow the platform to share
lowed data sharing with third parties. Reasons for shar-
personal information with advertisers and marketers. 3
ing and uses permitted varied from the relatively benign
of 17 policies contained inconclusive language. Only 2
(sharing to a mapping company for displaying maps)
platforms did not share personal data with third parties
to the worrisome (sharing for marketing and advertis-
for any purpose other than those mandated by law.
ing). Other policies provided broad discretion for uses
Notably the sharing was in some instances bi-
of anonymized location data. Among the policies with
directional, with services like Panopto combining data
broad language were Google, and the typically privacy-
that they collect with “data about our Customers from
conscious Apple whose policy allowed them to share lo-
third-parties” for “tailored advertising and Services.”
cation data with “partners and licensees to provide and
Seven policies allowed platforms to collect user infor-
improve location-based products and services.”
mation from social media, with Zoho going even noting
5 of 17 privacy policies mentioned capturing loca-
that “once collected, this information may remain with
tion data using mechanisms other than mobile-device
us even if you delete it from the social media sites.’
provided location. Notable examples were Slack, which
Slack’s policy contained text representative of what
approximated location using information gathered from
we saw across many platforms, which we include here
third parties, and Google, which referenced search data.
for illustration: “[Slack] may receive the user name and
4 policies did not disclose how they implemented loca-
email address of Authorized Users, along with additional
tion tracking.
information that the application has elected to make
Many policies we examined did not clearly explain
available” and that they require partners “to disclose all
why they collected location data, beyond minimal ex-
permissions for information access in the Services” but
amples under the umbrella category “improving our ser-
that Slack “does not guarantee that they do so.” The
vices.” Moreover, the language of the privacy policies
burden falls on users to “check the permissions, privacy
could encompass uses that educators and students might
settings, and notices for these third-party Services or
object to—such as Piazza’s policy which permits uses
contact the provider for any questions.”
“as required or permitted by law.”
There was significant variation in what privacy poli-
cies described. We would hope for clarity and trans-
parency in platform policies that include detailed expla-
3.2.2 Analysis
nations of when, to whom, and under what conditions in-
formation is shared, though such information risks over-
Our results show that the the governance of platforms
loading the average user. Yet such detail was not present
and the needs of our stakeholders are not aligned by de-
in the majority of policies.
fault. For that reason, considerable negotiation or gov-Virtual Classrooms and Real Harms 9
ernance is necessary at the university level to platforms’ gotiate with the platforms. DPAs can specify local rules
behavior with our stakeholders’ needs. and characterize additional responsibilities and expecta-
Our finding that some platforms use a broader tions for institutionally supported platforms.
range of tracking techniques beyond device provided lo- Providers offer template DPAs to make it easier
cation services strips choice away from users. By bypass- for enterprises, including hospitals and universities, to
ing device-based restrictions on obtaining location data, adopt a given platform. Zoom provides their own tem-
platforms subvert users’ expectations. plates, emphasizing FERPA and HIPAA obligations, as
As advertising and marketing third parties are inte- do Microsoft Teams, Google Hangouts, and Skype for
gral parts of the digital economy it is unsurprising that Business. The differences between public universities
many apps we examined interact with third-parties for that negotiate their own agreements and those that use
marketing or advertising purposes. Policies often failed templates are not obviously correlated with factors such
to enumerate the categories that constituted personal as endowment or student body size.
information, leaving platforms with broad discretion to We analyzed 50 publicly available DPAs from a
what is appropriate to share. cross section of 41 public universities, as well as 4 private
One notable finding was that platform sharing universities, for whom DPAs were not available under
with third parties was in some instances bidirectional— FOIA or similar laws. Many universities in our dataset
platforms received user data from social networks and also had other non-public agreements, including with
other parties, while at the same time transmitting user some of the same platforms, as described in the DPAs
data to these parties. For example, BlueJeans’ policy analyzed and in public FAQs. We coded these policies
permits collection of user data from “other Service to identify strategies, norms, and rules about specified
users, third-party service providers...resellers, distribu- information actors, attributes, transmission principles,
tors, your employer, your administrator, publicly avail- and complete information flows. We compared where in-
able sources, data enrichment vendors, payment and de- stitutional practices conflict with the terms of platforms’
livery service vendors, advertising networks, analytics privacy policies, revealing where universities either ac-
providers, and our business partners”—a list that incor- cept platform practices or negotiate improvements.
porates any conceivable third party. The policies did not To the best of our knowledge, this represents the
specify which particulars were shared. Platforms may first academic evaluation of DPAs used in any context.
thus be able to build profiles of their users in ways that
violate student and institutional expectations, which are
derived without this knowledge. 3.3.1 Results
The defaults reflected in these privacy policies gen-
erally applied to individually licensed versions of these We found that 11 of the 50 agreements negotiated dif-
tools (which are free or low-cost). When institutions en- ferent sets of rules for educational, organizational, hu-
gage contractually with platforms, they can negotiate man subject research, and medical uses (relative to uni-
around these provisions. But, when individual educa- versity hospital use) within the same document. 10 of
tors use these platforms they not realize that default these 11 specifically differentiate between educational
licenses do not have the necessary privacy protections or enterprise media data and additional protections or
that may accompany institutionally licensed versions. scrutiny for university hospital data, such as the docu-
In the Section 3.3 we assess the effect of changes to ments negotiated between Zoom and the University of
default terms, that can help bridge the divide between Florida, or WebEx and Iowa State University. Other no-
default practices and institutional requirements. table term modifications were Zoom’s commitment to
allow the University of Illinois to self-host the platform.
4 DPAs for Zoom and 2 DPAs for WebEx were con-
3.3 Data Protection Addenda sistent across 6 different universities, including the Uni-
versity of Minnesota and the University of Pittsburgh.
Universities are not tied to the default practices and These instances correspond with instances in which a
policies of platforms. By using their leverage as large platform’s suggested DPA was employed. In contrast, 18
organizations, they can extract concessions that bring universities had unique DPAs that correspond with mul-
platforms into coherence with local norms and values. tiple platforms and vendors, including some additional
Universities commonly extract these commitments technologies that we did not include. These correspond
through Data Protection Addenda (DPAs) that they ne-Virtual Classrooms and Real Harms 10
to instances in which universities developed a templates Software Version
that corresponded with university policies. W i n d ow s / m ac O S
DPAs reflect the institution selecting additional pro- Zoom 4.6.10
tections that go beyond the default platform terms. For Slack 4.5.0 (64bit) / 4.4.2
example, under the DPA between Zoom and the Uni- BlueJeans 2.19.791 / 2.19.2.128
versity of Virginia, Zoom’s obligations “survive termi- Jitsi 2.10.5550
Cisco WebEx Meetings 40.2.16.14
nation...until all until all University Data has been re-
Cisco WebEx Teams 1.0.0.2
turned or Securely Destroyed”. Microsoft Teams 1.3.0.8663
As these agreements are negotiated with individual
Table 3. Software Evaluated in this study (Desktop Applica-
institutions with diverse policies and requirements, we tions) We evaluate a set of commonly used platforms in remote
found significant variation in access to data and dura- learning environments. Separate Windows/macOS version num-
tion of data retention. While we conjecture that private bers are given, where necessary, throughout this work.
institutions likely engage in similar bargaining, we were
only able to obtain contracts from public institutions.
For example, the DPAs negotiated by the Univer- (E2E) encryption, and one was considering switching
sity of California exhibit similarity as they are designed from Zoom to Jitsi for its E2E encryption.
to comply with the University’s Electronic Communi- We address the paucity of existing security analy-
cations Policy [58], showing the impact of local policy. ses by performing a deeper analysis of the top video-
The same constraints can be seen in the DPAs nego- conferencing and collaboration tools, limiting this por-
tiated by Florida State University, which employs in- tion of our analysis to software that can be installed
formation classification guidelines drawn from Florida’s on desktop devices. We list the tools and respective ver-
public record laws. As a result FSU’s agreements include sions we evaluated in Table 3.
consistent language and requirements for all platforms Our analysis spans four metrics, chosen to maximize
through which student data is collected, stored, or pro- ease for an administrator to replicate our procedures in
cessed [6]. This shows how state regulations can shape a resource constrained environment.
behavior, even when they don’t apply directly.
In some public institutions, such as the University
of Connecticut (UConn), a DPA negotiated by the state 4.1 Network Traffic Analysis
with a platform applies not only to the university but
to all other public institutions. Besides restraining plat- We captured network traffic to and from desktop soft-
forms’ practices, rules can impact how universities select ware packages from each platform to determine with
features and defaults. In the case of UConn and Zoom, whom the application communicated and whether and
the agreement also places expectations on users (such how it encrypted these flows.
as obligations to use a passcode and regularly update We used application-layer traffic analysis in two
software), which are enforced by platform settings [21]. ways: to search for any qualitative security red-flags
(such as obvious failures to encrypt data-in-transit, poor
choice of TLS cipher suites), and to look for information
4 Security flows to third parties. We also ran the Qualys SSL Labs
tests against servers to which client software connected.
In the wake of universities’ rapid move to remote learn- We performed all captures on a clean installation
ing, the media reported widely on security flaws in the of Windows using the same software packages profiled
adopted platforms. Certain problems (such as “Zoom- in the binary analysis stage. We used a monster-in-the-
bombing”) received widespread coverage, but other com- middle attack to interpose between the software pack-
mon software security problems remained unaddressed. ages and the servers they were contacting, allowing us
Our survey asked educators whether they had secu- to see traffic in the clear.
rity concerns. Of the 60 educators who answered this We began each capture, then started and logged in
question, 32 (53%) had concerns. Several educators de- to the software being tested, began a video call with a
sired institutional authentication and/or passwords for second client (for all applicable platforms), terminated
private video conferences to prevent “Zoombombing” or the call, then terminated the capture.
theft of course materials. Two mentioned end-to-end We counted the number of third-party domains to
which each connected and looked for domains with noVirtual Classrooms and Real Harms 11
Zoom Slack BlueJeans Jitsi WebEx (M) WebEx (T) MS Teams
W i n d ow s / M ac O S
Arch i386/AMD64 AMD64 AMD64 AMD64 i386/AMD64 AMD64 / AMD64 AMD64
SafeSEH 7 N/A N/A N/A 3 N/A N/A
NX 3/ 3 3/ 3 3/ 3 7/ 3 3/ 3 3/ 3 3/ 3
ASLR Low Entropy High Entropy High Entropy 7 Low Entropy High Entropy High Entropy
CFI 7 3 7 7 7 7 3
Code Signing 3 3 3 3 3 3 3
Stack Canaries 3/ 3 3/ 3 3/ 3 7/ 3 7/ 3 7/ 3 7/ 3
Table 4. Security features present in end-user binary software on Windows and Mac desktop OSes. Where a feature is available for
both Windows and macOS, support in the for the feature is marked for Windows/Mac on the left and right of the slash respectively.
Low/High ASLR entropy indicates whether compile time flags necessary for high entropy ASLR were present. Rows with only a sin-
gle element per entry represent features specific to Windows. As SafeSEH applied only to 32-bit binaries, 64-bit binaries have their
respective entries marked N/A. WebEx Teams/Meetings are distinguished by (T) and (M) respectively.
apparent connection to the provision of platforms’ ser- to ensure close matches. We profiled servers against
vices. SSL Labs and found that all platforms’ servers received
We included third-parties that may add platform scores of A or higher for all platforms except for Blue-
functionality, such as Gravatar (a service providing jeans, which received a B for weak cipher suites. Jitsi
graphical avatars) or New Relic (providing application does not operate its own servers and so was excluded
analytics). Though use of these services may often be from that analysis.
justifiable, including them in our results contributes to
an understanding of how broadly platforms may share
user data. We excluded all domains that we could iden- 4.2 Binary Security
tify with the platform operator (e.g.; slack-edge.com).
We evaluate desktop software packages of platforms by
building on the Safety Feature evaluation criteria of Cy-
Results ber Independent Testing Labs (Cyber ITL) [24], a non-
profit research organization that attempts to provide
Of the software examined, only BlueJeans and Slack consumer friendly security analysis of software and de-
connected to third parties, connecting to three and two vices. Their approach aims to measure the difficulty “for
external hostnames respectively. an attacker to find a new exploit” in a given piece of soft-
Slack, WebEx Teams, and Microsoft Teams all used ware. Combining this approach with an analysis of ex-
certificate pinning to verify the identity of the servers isting vulnerabilities in Section 4.3 helps give an overall
to which they connected, providing protection against picture of software security. We opted not to adopt the
TLS monster-in-the-middle attacks. WebEx Meetings code complexity or code hygiene metrics of Cyber ITL
and Zoom presented warnings for untrusted certificates, which are of increased value for larger software packages.
but allowed users to click through the warning dialogs. We provide a short description of the different features,
If a user clicks through the Zoom warning, Zoom will highlighting which threats they protect against.
persistently trust the certificate across executions. None of these features impose substantial perfor-
Client software generally requested safe TLS cipher mance penalties and their absence is therefore better
suites, as classified by SSL Labs, but unfortunately all explained by ignorance or lack of investment in security,
the platforms maintained support for RSA suites, which rather than conscious product management decisions.
are known to be weak and vulnerable to attack. Blue- SafeSEH (Windows Only). Safe Structured Ex-
jeans and Jitsi supported finite-field Diffie-Hellman ci- ception Handling (SafeSEH) is a mechanism to ensure
pher suites that researchers similarly warn against [59]. that only authorized exception handlers execute [55]. A
The cipher suites offered by platforms’ corresponding binary with SafeSEH contains a list of exception han-
servers deviated from from those of their clients, which dlers, which the kernel stores in a protected list when
is intriguing as—had significant thought gone into the the program begins execution. If an exception is thrown,
choice of suites—the providers would have been able the kernel checks if the handler is pre-approved and, if
so, allows the handler to execute.Virtual Classrooms and Real Harms 12
DEP/NX. Data Execution Prevention techniques 32-bit software packages that developers migrate to
separate areas of memory that contain data and those 64-bit architectures may exhibit pathologies [63]. Thus,
that contain code, restricting the user from executing packages that have recently transitioned to 64-bit archi-
code contained in areas marked for data. No Execute tectures merit further caution.
bit (NX) is a CPU implementation of the DEP concept.
A binary with support for DEP/NX has appropriately
marked memory regions. Results
ASLR. Address Space Layout Randomization
(ASLR) randomizes the layout of a binary when the op- We extracted relevant fields from the first loaded bi-
erating system loads it into a virtual address space [43]. nary image from each software package using tools
Its efficacy is tied to the number of possible different provided by Microsoft/Apple where available. Where
layouts. 32-bit operating systems traditionally reserved unavailable or when searching for Stack Canaries, we
only randomized 8 bits, giving an attacker a 1/256 reverse-engineered the binaries by hand. We present our
chance of guessing the layout [37]. Modern 64-bit ver- results in Table 4.
sions of MacOS and Windows support randomizing up Limitations. Although the results for Jitsi appear
to 16 and 19 bits of entropy respectively (corresponding below-par compared to the other applications, they are
to between 66k and 524k guesses). Notably, Windows partially an artifact of our methodology. Jitsi is mainly
requires two compile time flags to be set to enable 19 written in Java, except for the main binary which
bit ASLR, without which at most 14 bits can be ran- uses native code to initialize the Java Virtual Machine
domized (corresponding to 16k guesses) [53, 57]. (JVM). Our methodology reveals only the properties of
CFI. Control flow integrity refers to a class of mit- this launcher and not of the underlying JVM present on
igations that aim to prevent an attacker from redirect- the users’ system. The Oracle JVM (the predominant
ing program flow [11]. Microsoft’s implementation of instantiation) has well-studied security properties and
this concept, Control Flow Guard (CFG), adds a check protections beyond the launcher’s. We therefore do not
before call instructions (that transfer execution to a consider Jitsi’s results to suggest overall poor security.
function) that do not have static arguments. The check
cross-references a data structure that stores the start
address of all valid functions, and throws an exception 4.3 Known Vulnerabilities and Bug Bounties
if the program execution would otherwise be transferred
to an invalid address [56]. Reports of software failure or flaws in the past predict
Code Signing. Code signing provides a chain-of- failure in the future [16, 29]. We therefore analyze pub-
trust to validate authorship of a binary. Both Microsoft licly disclosed vulnerabilities in the platforms. We also
and Apple provide services for third-party developers collate and discuss the platforms’ Vulnerability disclo-
to sign their applications. Both prevent users of their sure programs (VDPs), which are an important mecha-
most modern operating system versions from executing nism to aid firms in detecting and remediating software
unsigned binaries absent explicit acknowledgment. security flaws [60].
Stack Canaries. Stack canaries are a compile-time Vulnerability Disclosure Programs. Often
modification that allow a program to detect a subset of known as ‘bug bounty’ programs, VDPs provide a
buffer overflow attacks [22]. A canary value is placed mechanism for participants to submit flaws to a plat-
on the stack between a stack frame’s return pointer form security team, which then fixes (or decides not to
and other variables. Before a program uses the return fix) the flaw. The programs generally offer rewards for
pointer on the bottom of the stack, it first checks the participants—fame, fortune, or both. The existence of a
contents of the stack canary against a known value. If well operated VDP is known to be a positive indicator
the value has been altered, the stack has been tampered of security, and gives a measure of assurance that a com-
with, and the program will terminate with an error. pany takes security seriously. However a poorly designed
Architecture Width. While the architecture for program that does not provide adequate incentives, or
which a binary is compiled is not inherently a security excludes too many threat types, reduces its effectiveness
feature, 32-bit binaries are unable to use many modern in securing software [35, 36].
OS security measures. To this end, MacOS 15 (Oct 2019) The vendors for all platforms we evaluated offered
ceased support for 32-bit binaries. We therefore checked a VDP, open to members of the public.
that the Windows software packages were 64-bit.Virtual Classrooms and Real Harms 13
Zoom and Slack both outsource their VDPs to
HackerOne [2, 3], a for-profit operator that has faced 10
criticism for its use of non-disclosure agreements that
limit when a reporter may disclose the existence of vul- 8
nerabilities [45]. Zoom excluded from its program many
types of potential issues including ‘Attacks requiring
MITM’ and ‘Any activity that could lead to the dis- 6
Impact
ruption of our service (DoS)’. Following criticism, Zoom
hired external consultants to revamp its VDP [17], a
4
process that concluded in July 2020. While Slack has a
similar list of exclusions to Zoom, Slack marked them
as ‘unlikely to be eligible,’ leaving room for discretion. 2
BlueJeans outsources its VDP to Bugcrowd [1]. The
only significant limitations to its rules-of-engagement
are denial of service attacks, and attacks on physical in- 0
0 2 4 6 8 10
frastructure or persons. Bluejeans also provides a mech-
Exploitability
anism for testers to obtain enterprise accounts so as to
Zoom (11) Jitsi (1)
enable them to test the full set of offered features.
Webex Meetings (4) MS Teams (1)
Both Cisco and Microsoft retain in-house Product Webex Teams (15)
Security Incident Response Teams (PSIRTs) that handle
disclosure. Cisco explicitly includes high-impact vulner-
Fig. 3. Exploitability and Impact scores for CVEs reported Jan
abilities in third-party libraries used by their products
2010-May 2020. Circular clusters indicate CVEs with the same
in scope of their VDP [18]. scores, with markers adjusted for visibility. Regions are shaded to
Known Vulnerabilities. When a vulnerability in indicate low/high exploitability and impact. Numbers in parenthe-
software is publicly identified, it is often assigned a num- ses indicate the number of CVEs found for a particular software.
ber according to the Common Vulnerabilities and Expo- No CVEs were found for Slack or Bluejeans. (n = 32)
sures (CVE) system. A CVE ID is stored along with de-
tails of the vulnerability in the National Vulnerability understate recent problems with the software. On the
Database (NVD), a separate but related program ad- other hand, Zoom’s rapid improvement in both software
ministered by the National Institute of Standards and and process (that represented a response to disfavorable
Technology. The NVD listing includes numerical scores media coverage) point to a positive trajectory for Zoom.
from zero to ten for the impact of the vulnerability when While Zoom garnered the bulk of negative media
exploited, and for the ease with which the vulnerability attention, in the 2019 alone, five CVEs were issued for
can be exploited. These scores as calculated according WebEx Teams, two of which were high severity each
to the Common Vulnerability Scoring System (CVSS). scoring 8.6 on exploitability and 10 on impact. WebEx
In Figure 3 we depict the CVSSv2 impact and ex- was issued 15 CVEs total in the reporting period, the
ploitability scores for CVEs tied to the software we eval- most of all software.
uated. While we intended to aggregate all CVEs from Limitations. As many bugs are discovered inter-
2010 onward, the earliest CVE we found for our dataset nally, it is common for vulnerabilities not to be assigned
was issued in 2014—indicative of the relative newness a CVE ID, limiting the extent to which the number of
of the platforms evaluated. The vulnerabilities are clus- CVEs for software can be used as a proxy for security.
tered toward the high-exploitability region of the figure, For example, during this study Jitsi (which only had
however this is unsurprising given that the mean impact one CVE) issued a security bulletin identifying high-
and exploitability scores across all CVEs reported since severity remote execution bugs in the client software [7].
2010 were 8.04 and 5.04 respectively. Similarly, in August 2020 hackerone published a critical
Zoom has many recent CVEs (11). While intense severity bug in Slack [42]. As of writing, these bugs were
recent attention is no doubt a contributing factor, the not assigned CVEs, despite their significance.
substantial number of recent vulnerabilities suggests a The relative number of CVEs found by researchers
systemic component to Zoom’s security issues. Further, may also be more reflective of the scrutiny that has been
as our evaluation postdated Zoom’s efforts to remedi-
ate the aforementioned security issues our results likelyYou can also read
