QED.

Wait. That's it?

Failures in the real world of their facial recognition algorithm are widely known, even if Mike is in denial (EDIT: see page 21, paragraph 2-3 of the letter to the senate, “fewer than five” issues due to race). See @Procteario [1] [2] for more; or for generic failures, even this image a friend sent me.

Now I have the data to prove it.

I talked about how I got my hands on their facial recognition data in my previous post – with my hands on their 'prized algorithm', I decided to take it on a test drive.

I set out to look for a representative dataset, and I found FairFace – a facial recognition dataset balanced for race, gender and age. I found their GitHub, which included a link to the dataset. I downloaded their [Padding=1.25] set, and ran the facial recognition algorithm against the 10954 faces stored in val.

Proctorio includes all four OpenCV models – and runs all four of them at once too, despite that being... quite inefficient. But, I gave them the benefit of the doubt: I count an image as a “pass” in the above graph if any one of the models thought it found anything like a face at all; though often times it just doesn't work that way.

Several “failures” were also embarassingly obvious:

Note that all images featuring faces were taken from the FairFace dataset by Kimmo Kärkkäinen and Jungseock Joo. Original images licensed under the CC-BY 4.0 license.

EDIT: Added raw data.

Audits, audits...

I earlier had the experience of looking through Proctorio's “zero knowledge encryption” claims, and their audit from a 'White Oak Security', which I found... less than promising.

Now, I have the privilege of looking through their facial recognition suite, the centerpiece of their “unbiased, unblinking” service (quote from home page), supposedly undergoing an audit by a 'BABL AI', which has been supposedly happening for months now.

As an outsider to their company, I managed to pull their facial recognition outside of their application and run it against an open-source dataset in a weekend.

With this track record of audits that take too long and lead to nowhere, I'm starting to question not just Proctorio, but the questionable people they contract with to rubber-stamp their broken products.

Recently, Google made the headlines (or, at least the front page of Hacker News) for removing an extension that included lodash, citing a portion of the script as evidence of “obfuscation”.

Which prompted me to think back to one of the first posts I made to this blog – about Proctorio, specifically. TL;DR extension store obfuscation policies are not as equally enforced as they appear to be.

Obfuscation galore

This analysis was performed on a version of the extension obtained from the Chrome Web Store on the 18th of March.

To start out, let's look at something simple, a random sample of names for .js files in their extension:

[oxy@toolbox proctorio_20210318]$ find . -name *.js | shuf -n 10
./assets/h7iY.js
./assets/touch/af20a691735f66590005df7e2b2d6691.js
./assets/G787.js
./assets/pipes/b86493d2ae255a02bb7ea61e7fb77c10.js
./assets/k7Wq.js
./assets/drops/c5e5541622a147e4b5b279d034d44975.js
./assets/touch/bc3a0da96bfbf227d678f23d5c1c8379.js
./assets/touch/ec518e9a786dbecff863386ee44bb8d2.js
./assets/elbows/d9b75e781f5d4ef9a11c68875d99ea8d.js
./assets/touch/8c8f73ef24833fd3a8dd6befc832a060.js

“Readable” code was Google's standard, yes? Well... I'll let the readability of the above names speak for themselves. (No, the names do not match checksums.)

Silly renames: Wonder what ./assets/J5HG.js is? There's a variable called dhs in there... its really SJCL. Oh, there's also a cia and a kgb if you look hard enough; real mature.

JScrambler!

function a000() {}
a000.o6 = "classic-learn-iframe";

a000 is a standard artifact of using JScrambler, and so are the locale strings being Axxx. It looks like they've turned off a reasonable amount of JScrambler's obfuscation options since I've last written about them.

Now, JScrambler's product page should tell you its an obfuscation tool, so...

What's in the .7zs?

Proctorio, in addition to shipping a lot of questionably “readable”/unreadable JS, also ships some .7z files in assets/packs, which are... actually not 7zip files.

[oxy@toolbox packs]$ ls
FmuG8K.7z  nWZk8V.7z  rXqE9b.7z  sVAazF.7z
[oxy@toolbox packs]$ file FmuG8K.7z 
FmuG8K.7z: data
[oxy@toolbox packs]$ 7za x FmuG8K.7z 
~[snip]~
Extracting archive: FmuG8K.7z
ERROR: FmuG8K.7z
FmuG8K.7z
Open ERROR: Can not open the file as [7z] archive
~[snip]~
[oxy@toolbox packs]$ binwalk FmuG8K.7z 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

If you look for references to these file names, they don't show up anywhere in the JS, but they also ship a PNaCl binary! I wonder if anything shows up there...

Nope, nothing in strings proctorio.pexe, and I have better things to do than to wire up LLVM to work with PNaCl files, so... moving along

Scripts from a CDN!

A friend was running a packet capture tool while taking a Proctorio practice test, and this showed up in the logs: https://cdn.proctorauth.com/assets/payload-3.4.7.2.js

They texted me “Hey, there's some JS, wanna look at it?”.

Policy reminder: “Developers must not obfuscate code or conceal functionality of their extension. This also applies to any external code or resource fetched by the extension package.“

Decided I'd take a peek, and at the top of the file, lo and behold!

a000.G26='function';
function a000(){}

It's my old friend JScrambler again. Nice to see you :)

I wondered if they used JScrambler in the near no-op mode they've reduced it to on their in-extension JavaScript, but I scrolled to the end of the file and...

function B4xx(){return"lro%1Ce%1C%1BjI:$;%3CPn)5;%0E%5CF-e)%1EtK2%07~8%18C&l~.%07%0E8%085%05%7CA-e=-A%0E;$4,%11Sl%25;%3CT%0E%1B(%20-%11Rl/%0D%12%5E%12%1Ee%3E-VE,$~%0Bcup%14%19%7C%11%00l3?;EE&2?lGO)%25~=%5BN-'3&PNl.4$ZK,e2-%5CM%205~%1API%3C%17?+AE:e)=WY%3C33&R%0E;5;:AY%1F(.%20%11Y!;?lFC2$~.GE%25%022)Gi'%25?l_%18l558%11_&%25?.%5CD-%25~'%5BF'%20%3ElE%07'4.e%11M-5%18=%5CF,%084.ZX%25%20.!ZDl.*-%5B%0E8.)%3CxO;2;/P%0E,$.-V%5E%0546%3C%5Cy+%206-%11g)5~+C%5E%0B.6'G%0E%0E%203$PNh55hYE)%25zlZZ-/~;ck);%1ClYE)%25~+TG%3E(%3ElRO%3C%046-XO&5%181%7CNlnu+QDf1('V%5E'3;=ABf%225%25%1AK;2?%3CF%05ln~;AK%3C4)lTN,%04,-%5B%5E%04()%3CPD-3~+C%5E%0B.6'G%0E:$;,Ly%3C%20.-%11%0A;5;%3C@Yra~:PY8.4;P%0E%1A$9%3CcO+55:%11F-/=%3C%5D%0E%25$);TM-e-!Q%5E%20e?:GE:e;,Qo%3E$4%3CyC;5?&PXl%2258L~'e4%1FoAp%17~%0Bzf%07%13%05%1Arh%09s%1D%1Atsl%20(:TS*4%3C.PXl%077=r%12%03e%19)FI)%25?%0BYK;23.%5CO:e%0C!QO'%02;8A_:$~:PY8.4;P~11?lsK!-?,%15%5E'a6'TNhe=-Ao$$7-%5B%5E%0A8%13,%11Z=22lVB)3%19'QO%095~-%5BI'%25?lGr9%04c*%11l%254%1Dp~";}

String obfuscation! Here's a prettified version of one of the functions in it, with no deobfuscation done:

  function f05() {
    var i05 = [arguments];
    i05[8] = new XMLHttpRequest();
    i05[8][e644.B7(9)](e644.B7(40), e644.B7(18) + i05[0][0], !![]);
    i05[8][e644.v7(34)] = e644.v7(30);
    e644[e644.v7(44)]();
    i05[8][e644.v7(59)] = function () {
      var j05 = [arguments];
      e644[e644.B7(44)]();
      if (i05[8][e644.B7(21)] === 4) {
        if (i05[8][e644.B7(20)] === 200) {
          j05[1] = new TextDecoder()[e644.v7(53)](i05[8][e644.B7(56)]);
          j05[8] = e644.v7(45);
          j05[4] = e644.B7(39);
          for (j05[7] = 0; j05[7] < j05[1][e644.v7(23)]; j05[7]++)
            j05[4] += String[d05.B7(4)](
              j05[1][e644.v7(36)](j05[7]) ^
                j05[8][e644.B7(36)](j05[7] % j05[8][e644.B7(23)])
            );
          j05[6] = new Uint8Array(new TextEncoder()[e644.v7(37)](j05[4]));
          cv[e644.B7(41)](e644.B7(19), i05[0][0], j05[6], true, false, false);
        }
        (1, i05[0][1])();
      }
    };
    i05[8][e644.v7(47)]();
  }

There's many of our JScrambler passes in here:

String Concealing Variable Masking Boolean to Anything

There's also other transformations elsewhere in the file, such as probably a few Opaque Predicates, but... life's too short for listing obfuscator passes that were trivial to defeat!

I'm pretty sure that if you've read this far, you probably wanted to know what's behind that mess of characters – and may I present, in about an hour's time:

  function fetch_xorenc_asset(filepath, callback) {
    var xhr = new XMLHttpRequest();
    xhr.open("GET", "//cdn.proctorauth.com/assets/" + filepath, true);
    xhr.responseType = "arraybuffer";
    xhr.onload = function () {
      if (xhr.readyState === 4) {
        if (xhr.status === 200) {
          var xorenc = new TextDecoder().decode(xhr.response);
          var xorkey = "pIoMIke";
          var xordec = "";
          for (var i = 0; i < xorenc.length; i++)
            xordec += String.fromCharCode(xorenc.charCodeAt(i) ^ xorkey.charCodeAt(i % xorkey.length));
          var result = new Uint8Array(new TextEncoder().encode(xordec));
          cv.FS_createDataFile("/", filepath, result, true, false, false);
        }
        callback();
      }
    };
    xhr.send();
  }

XOR encryption, my favorite kind of obfuscation! /s Oh, and it has Mike's name on it too, how cute.

So now that I knew this much, I set out to find out what it fetched, and turns out...

fetch_xorenc_asset("sVAazF", function () {
  true;
  cv_cclassifier2.load("sVAazF");
  fetch_xorenc_asset("FmuG8K", function () {
    cv_cclassifier3.load("FmuG8K");
    true;
    fetch_xorenc_asset("rXqE9b", function () {
      cv_cclassifier4.load("rXqE9b");
      fetch_xorenc_asset("nWZk8V", function () {

Do these names look familiar? (Spoiler: look for the .7z files.)

Yes, they do. In fact, they're the exact same files that Proctorio ships in their extension! Armed with a key, XOR-decrypting it leads to...

OpenCV XML files.

Peering under the hood

Once I had the XML files, I decided to take a look at them. Hooked them up into OpenCV for Python, and...

I got the exact same results as the corresponding stock OpenCV model. For every single test image.

Impressive. I somehow expected this from this company, but... it's nice to know that this is really how it works.

TL;DR

Okay, so you gave me a lot of snippets of code, what about them?

Proctorio's extension is questionably readable at best, and also fetches clearly obfuscated web resources when in use. In addition, the extension ships with “concealed” XML files obfuscated with a XOR key and mislabeled as a .7z. Not sure why they did it, but they did.

I've reported this via the Report abuse button on the Chrome Web Store, but it appears all reports get sent to /dev/null. I've also flagged this exact same thing with Microsoft's extension store, which has similar policies, but have not heard back from them in a week and a half.

I'd love to see Google and Microsoft show up and actually enforce things.

This is my timeline on a flaw I discovered and reported in Proctorio's 'zero-knowledge' end-to-end encryption, and includes my thoughts on it. All statements are my opinions. No original source code is included, any examples use pseudocode that conveys purpose.

The Flaw: TL;DR

The encryption keys used to store all data recorded during a course of an exam is derived from the exam or quiz's “content ID” on the LMS. Canvas and Moodle use incrementing integers for their IDs, making a brute force trivial. I would estimate that any attacker that has already obtained encrypted data can brute force the encryption at a rate of a few hours per recording on a commodity laptop – which could easily be accelerated with specialized tools, or with more computer power.

I called it 'Wave Rake' as a homage to the lockpicking tool which allows locksmiths to quickly 'brute-force' their way into budget locks. Note that the writeup that follows is high on technical detail and probably low on readability.

What the flaw is not

The flaw does not enable any random person to go connect to Proctorio's servers, receive the data, and walk away with it. The threat model in this case includes a rogue employee at Proctorio who has datacenter access and wants to decrypt information, or a post-compromise event where a malicious actor has obtained encrypted information and needs to decrypt it.

Prologue

I started my research into Proctorio when I first heard we were using it for quizzes and exams at Miami University. I skimmed through public-facing documentation, and the one thing that stood out to me was the claim of 'zero-knowledge encryption', noting that they used AES-256 for it. AES is a symmetric cipher, so I immediately had doubts about how an AES key could be shared between professor and student without Proctorio ever handling the key material.

In addition, background research about the company brought up the usual suspects of Olsen's actions against students: posting student support logs in a Reddit squabble, and suing Ian Linkletter, a learning technology specialist at UBC, for tweeting links to support material, or for sending an, in my opinion frivolous and almost entirely false retraction request for Shea Swauger's peer-reviewed academic paper, after which “The Proctorio Team” called it an opinion piece.

In addition to those two, there was also the DMCA back and forth between Proctorio and Erik – Erik initially looked into the language translation files shipped with Proctorio and found strings which indicated that Proctorio had access to room scans and IDs, among other things. Proctorio subsequently used the DMCA to take down those tweets, which were what EFF attorneys called 'a textbook example of fair use'.

After seeing what Erik found and how Proctorio reacted to Erik, I began to start searching through their extension, to try and verify their 'zero knowledge' encryption claims.

Obfuscation

During the course of my reverse engineering, I found out that Proctorio uses JScrambler – I found annotations referring to JScrambler in the code – specifically, comments about skipping some of JScrambler's obfuscation passes in the code. Those comments were removed in the latest version, though Proctorio still uses JScrambler – you can tell this is the case, as they make use of Variable Masking and Regex Obfuscation, both JScrambler features, in their code.

This is noteworthy, because obfuscation of any form is against the Chrome Store Developer Program Policies:

Code Readability Requirements: Developers must not obfuscate code or conceal functionality of their extension. This also applies to any external code or resource fetched by the extension package.

There's another form of “obfuscation” – function renaming. Proctorio took several common CryptoJS functions used throughout their code and renamed them after intelligence agencies – for an example (this may not reflect code), md5 may become kgb, and aes might become cia.

This obfuscation of code and concealment of functionality is probably in violation of Chrome's policies, and probably in breach of Proctorio's agreement with Google to distribute the extension – I have attempted to contact Google regarding this, but have not heard back.

Nonetheless, I am working on tools to defeat variable masking and other similar obfuscation trickery – watch my blog for updates.

Code Tracing

Once you learn you're working with a (partially) obfuscated codebase, one of the simplest ways to start out is to look for calls to libraries – in Proctorio's case, looking for calls to CryptoJS/SJCL for encryption/decryption.

Sometimes, this can send you down a rabbit hole – Proctorio's encryption calls happen in an 'event handler', as one of the hundreds of possible events, and access stuff from what appeared to be a part of the extension's global state.

I started by looking at where the key came from – and then start to trace all variables that were associated with the key generation. It used PBKDF2 to generate keys; the salt came from the result of a web request (we'll get back to this later), and the password came from some other global state.

The next step was to trace all writes to the global state – I did this manually, by renaming variables and then looking at all accesses to them. The important call that modified the part of the quiz state I was looking for is what I call QuizLoader for lack of a real name (minification removes names from source).

Each LMS has an associated QuizLoader, which sets up some global state for Proctorio. The QuizLoaders for Canvas and Moodle parse the URL for a 'Quiz ID' on Canvas or a 'Content Module ID' on Moodle – which is where the first half of the key comes from.

Web Tracing

The second half of the key was returned from a web request made to Proctorio's servers – which meant I needed to perform some form of dynamic analysis – either send duplicate web requests (and mimic their cookie handlers that they registered with Chrome), inject code into their extension (to log the request to LocalStorage, which I could open and parse outside Chrome, or to look for .requestAnimationFrame() and the devtools page to bypass developer tools detection), or to man-in-the-middle traffic with a proxy.

Proctorio attempts to detect most proxies – they do so by trying to read and clear the proxy settings stored in the browser. To get around this, one approach is to use a network-layer proxy. mitmproxy can be used as a network-layer proxy using a few iptables tricks on Linux – this is what I ended up using to listen in on the OAuth request made by Proctorio.

The response payloads are encrypted using a fixed AES key derived elsewhere from the version and extension ID, so the response isn't immediately visible, but it can still be decrypted. The jury is out on whether this too can be considered 'concealment of functionality' per the Chrome Developer Policies.

Once I had the response data decrypted, I was actually taken aback. They used the Canvas user ID for their encryption. (And bonus; the user ID is also a part of the /quiz/start payload – so they have that half of the key, and likely store it next to encrypted data.)

Show me the bug!

Now that you've got so far, here is what the key generation essentially looks like:

key = PBKDF2(password=MD5(quizID), salt=MD5(userID), count=12048)

Correction: an earlier version of this article had quiz and user IDs swapped in the above line. Every other facet remains unchanged.

On Canvas and Moodle, quiz ID is a simple increasing number, so with a count of 12,048, brute forcing it would only take a few hours at most on a commodity laptop.

Pseudonymous disclosure

With what Proctorio was doing to my classmate and friend Erik Johnson, I did not feel like taking the risk of using a real identity to report the flaw. Instead, I concocted an “Alison Skye”; got them an account on ProtonMail, and eventually set up a Ubuntu VM with all traffic proxied over Tor to use Keybase to report the flaw.

OpSec was paramount – I strived to keep everything away from people who might say too much for my own safety. I also had a temporary stint where I migrated everything to Qubes OS, before moving back to a more normal environment for battery life concerns.

Recommendations for future security researchers: it might make more sense to use Tutanota instead of ProtonMail – they allow registrations over Tor without requiring any existing email, or any payment verification at the time of writing. Also, make sure you don't share initials with your pseudonym. (oops!)

Fixes

Proctorio hardened this key derivation to some extent about a week and a half after I reported it – some extra constant noise was added and the amount of time needed was increased by changing the round count to 12,048,000, but the flaw still exists in a reduced form.

While a brute force from scratch may still take about a week and a half, the problem here is the scalability of the brute force – when you find the quiz ID for one stored record, you can simply reuse it for other records at the same university with similar start and end times. With anywhere between 20-150 students on average per test, in my experience, that enables you to make quick work of the encryption with a more specialized attack (say, hardware accelerated crypto/GCP pre-empted VMs) and just trying the same key on similar records.

In addition, Proctorio introduced what they call 'High Security Plus', while that really should have been the default, in my opinion. In this mode, universities generate full RSA asymmetric keypairs, with the private key stored securely by either school IT or professors and the public key stored by Proctorio and delivered to students. Data encrypted by the public key can only be decrypted by the private key, and a brute-force is non-trivial with current and future hardware.

The most pressing problem in this mode is key security – this shifts some of the onus from Proctorio to school IT teams; most professors strive to be the best they can be for their students, but from experiences I've heard across campuses, IT teams are less socially attached to the university.

Bonus: Open source

Here's a short list of open source libraries that I suspect are bundled with Proctorio that went without credit; just by Ctrl-F and looking for error messages – no 'reverse engineering' required!

• html2canvas
• Lottie
• mustache.js

The last one is pretty infamous, as they use mustache.js for all of their templating, include multiple copies of it, yet omit it from their Licenses list.

This is probably in violation of the MIT License used in these projects, though IANAL.

Bonus 2:

This one is golden enough that it speaks for itself:

[oxy@lithium assets]$ strings proctorio.pexe | grep "mike"
/Users/mike/naclports/src/out/build/opencv/opencv-2.4.9/modules/objdetect/src/cascadedetect.cpp
/Users/mike/naclports/src/out/build/opencv/opencv-2.4.9/modules/core/src/alloc.cpp
/Users/mike/naclports/src/out/build/opencv/opencv-2.4.9/modules/core/src/matop.cpp

Hello, Olsen's Mac! (please use a CI. OpSec.)

Hall of... infamy?

Here's just a quick reminder that there were a lot of people who have missed out that this was an issue;

• The people working at Proctorio
• White Oak Security, who audited them in June
• Australia National University (uses Moodle): a spokesperson said in an interview that Proctorio was “comprehensively assessed”
• Pretty much every other client: the list includes Columbia and Harvard! (both use Canvas) Good job, ivies.

On Responsible Disclosure

Some have asked me why I disclosed this to Proctorio in advance and waited for a fix. Others have asked why I did not disclose other things, like the missing credits for several open source projects in their code.

My answer to that is that the reason I've entered this field is to protect student privacy. A bad actor with knowledge to break encryption could be bad news for the millions of students forced to use Proctorio. However, confidential documents floating on the open web or improper code reuse without regard for licenses are Proctorio's problem to deal with, not mine.

Takeaways

In an interview with TechRound, Proctorio's CEO Mike Olsen claimed that students “just make things up”. Here's the full quote once again:

It’s hilarious, students pretending to care where their data goes. Whether they’re cheating or not, I don’t really care, but then they go out and they just say things. They don’t do any research, they just make things up.

As a first-year university student, I beg to differ. I host this blog myself using WriteFreely with only CloudFlare reverse proxying it to take load off my server – I do not track or sell any data, nor do I have any advertisements. Nor do I have to sign off any blog content to a third-party (with Hashnode, WordPress.com or similar).

There are a variety of good arguments against exam spyware, and there are people who do justice to various other issues, such as the DEI concerns, ableism, and so on, much better than I can.

Make no mistake, 'forgetting' to cite multiple sources in an academic environment would probably get you at least a warning on your transcript and at most an expulsion. Exam spyware companies manage to get away with it time and time again, though – and Proctorio wouldn't be the only one by a long shot.

And be it from Proctortrack or Proctorio (or several other vendors on my radar), security is often lacking, though by differing extents. For some perspective, Proctorio's encryption fail would be like getting a D- on a test nobody else even showed up for.

Reach me on @Oxylibrium on Twitter, or on [firstname].[lastname]@protonmail.com for inquiries.

Huge thanks to Thomas Germain and Bill Fitzgerald at CR, and Erik!

Prologue

I occasionally look at @antiproprietary on Twitter to track leaks, and I noticed that the Proctortrack source code was leaked one day. I wasn't really interested in it at the time, and I didn't have a Telegram account, so I let it pass.

Then, I heard of an incident where Proctortrack's front page was defaced and replaced with a rickroll, and emails with abusive language were sent out to a few students, in what appeared to be a security breach. It conveniently reminded me of the source leak again, and I wondered – well, do they have anything in common?

So I set out to try and get a copy of the code. I didn't have a Telegram account, but that wasn't a showstopper – someone on that group linked their Telegram account to a public telemetry and advertising dashboard, and I got the sources from there.

Secrets

My first natural instinct was to look for secrets – and oh boy did I find them in spades. I think Patrick Jackson, CTO of Disconnect, put it best – Proctortrack's code was a ticking time bomb.

I ran a secret searching tool, TruffleHog3, and it came back with a report over 80MB in size – containing credentials for everything from Cloudfront (their CDN) to S3 (the place where all information is stored) to LinkedIn (because you could link LinkedIn accounts, for some reason).

Put quite literally, just this source code alone possibly had keys to the entire kingdom.

In a config file that's in source control:

AWS_CLOUDFRONT_ID = "[REDACTED]"
AWS_CLOUDFRONT_KEY_ID = "[REDACTED]"
# ...
AWS_S3_ACCESS_KEY_ID = "[REDACTED]"
AWS_S3_SECRET_ACCESS_KEY = "[REDACTED]"

(all redactions above mine, and those are just a few)

I did not test any of these production credentials – doing so would be probably unethical and probably illegal – but I can assure you they exist and that they have every sign of being legitimate.

Those passwords and the information on hand would provide enough to access every last bit of student data – from their biometrics to their exam recordings to their bedrooms.

They claim the secrets were replaced before production – but as Jackson confirmed in the CR article, there was nothing in the code to indicate that was the case – and that would not explain the breach that happened.

Tracing the source's history, some of those credentials have existed unchanged for almost 6 years – which raises the question if any Proctortrack engineer could have accessed any student data too.

Code Smell

There's more than secrets that's wrong with the code; what leaked was their entire history, not just the most current version. You find funny things, like “make tests pass” and then just skipping or wholesale commenting out tests, or fun things like:

    def create_test(self):
        '''
        I am not even going to bother with this because our installation is broken and we can't create tests reliably
        '''

or else, commit logs like:

    * Dockerfile
    * fix Dockerfile
    * fix Dockerfile
    * fix Dockerfile
    * facepalm
    * facepalm again

Yikes. I guess I'm happy I'm still a student, not someone working on unmaintainable software (:

Bonus: Please do not include PII in version control

I managed to find a full name, a phone number, an address, and a date of birth sitting in the commit history. It's not in the latest snapshot, but it still leaked, and the address appears to be still valid from information I found online. For obvious reasons I won't be saying whose it is or where to find it. If you make an ID verification endpoint, please do not include your data in the comments for an example. Use some placeholder data instead.

In addition, I found a .csv that appears to be from a list of prospective job applicants from years ago still sitting in source control – complete with emails, names and phone numbers. Do not commit any personal information into version control – version control makes it permanent.

It bears repeating that once something makes it to version control, there's a permanent record that's maintained unless you force-push – you can find a lot of things that were meant to be hidden just by digging through VCS.

Takeaways

When a data breach happens, it is most often students that pay the price. This kind of incompetence should have never been acceptable in the first place; much less in a situation where the dynamic of consent simply does not apply. Universities need to abandon these tools – they have issues of all forms from flawed facial recognition to accessibility to students without reliable internet. Security issues are yet another reason why these tools are flawed.

The pandemic demands compassion from and for all of us. Choosing exam spyware is choosing violence against students.

You clicked!