Authors

Inspiration

As students who have experienced the straining effects of the COVID-19 crisis, we were motivated by our academic integrity to develop a program that would make testing fair for all and proportional to the amount of work a student puts in. In a physical school setting, education is enriched by academic honesty, as students have to genuinely learn to get good grades, which they obtain through professional lectures and a safe environment. To replicate this environment at home, it is important to maintain this academic integrity through what we thought would be the best solution: a browser lockdown. While some forms of this solution exist, these existing services are neither efficient nor effective, as they tend to be outdated, not accommodating to the myriad of novel ways students are able to switch tabs, which makes sense, since the people who made these apps are outdated too. Given our younger age, we are much more privy to understanding the way our similar-aged peers try to cheat on tests and can therefore combat cheating more effectively.

What it does

With Browser Vault, a student’s computer gets completely locked down, with them being unable to Alt-tab or open communication websites like Discord or Slack without losing access to the test. A teacher is then able to monitor their progress on the test and see if they are performing any suspicious behavior.

How we built it

Server-side, the website started off as a basic HTML with basic CSS and a Javascript button. From there, we built upon the original index.html with added CSS to make it look neater. We added 2 separate download pages for both Windows and Apple, and then we added a navigation bar and improved on the CSS using transitions. Furthermore, we added a mixture of inline CSS and separate CSS files to not only familiarize ourselves with the language, but to also make the code more robust through multiple aspects of implementation. On the other hand, we also encountered errors when working with CSS grid and CSS to apply aesthetic to our images. To resolve the image issues, we were able to test many methods of centering an image and settled on setting an absolute position along with margin edits.  On a separate Java file, we programmed a random alphanumeric key generator and attached the applet to another HTML file, this one accessed by searching the link in the search bar. The code was also intended to limit the amount of uses to the number of participants expected for the test, but ultimately it had to be scrapped because Heroku was unable to store the data stream. Had it been able to, the client Browser Vault application would send constant data packets telling the main console the status of each participant. The teacher would then be able to view and control who would be allowed access into the test and who wouldn’t. We also added a Github wiki, an About page, and a redirecting home page. The Github wiki gives thorough and detailed steps for downloading and using Browser Vault.

Client-side, the application started out as a basic Java Swing window which could not be closed or taken out of focus. However, this model prevented users selecting and interacting with the website in view. Not only the lack of interactivity, but a very basic CSS interpreter implemented in the API meant that we could not properly render websites without absolutely destroying some (sometimes critical) elements. This led to a change in engines, and the web engine that is utilized by the current version of Browser Vault is JavaFX’s WebView. This allowed newer and more complex sites to be rendered with less issues than before, and also aided in load time mitigation. However, WebView was based on JavaFX, which was a completely different framework than Swing. After many insertions and deletions, we managed to make a bridge between the two frameworks and utilized the base for the original project. After this came the challenge of preventing cheating. While initially we attempted to make a program that locks the student out of application-switching shortcuts, a program that was more docile helped both client-side performance and overall usability. The solution that is implemented in the current version of Browser Vault utilizes the fact that all of the application-switching shortcuts also change the active window -- this means that to see if a student is cheating, one must simply check if the test is the active window repeatedly. This was implemented via a subthread that runs shortly after the webpage is rendered, and worked reliably even with newer implementations of multitasking, such as trackpad gestures and desktop switching. Finally, the client-side application had to be deployed reliably as well. Building the JAR file itself was fairly simple, however because of the application’s reliance on JavaFX and Swing, the only reliable JREs were 8, 9 and 10, as they came preloaded with these modules. After the JAR was built, we utilized Launch4j, an open-source converter between JAR files and EXE files, which also allowed us to limit the JRE versions the application could run on.

Accomplishments that we're proud of

Being able to overcome the downfalls of being beginners to a language. We were also able to collaborate with each other under both time constraints and a remote setting.

What we learned

Since we were all very new to HTML and CSS, working on a website from the ground up proved to be a very daunting task. We familiarize ourselves with incorporating Javascript and CSS into HTML5 and storing and transmitting data. We also learned some basic TCP, SSL encryption and port forwarding, as we learned it when we first attempted to host our Domain.com website. Seeing that we had trouble hosting with a third party hosting client like Google Cloud, we then attempted to localhost with WAMPServer, through which we learned about hosting on routers. Finally, we transitioned over to Github Pages, where we taught ourselves how to sync work done offline with the repository and website. We also used Swing and JavaFX, two new APIs we experimented with to create the application, and through them we learned how to do basic UI design, manage a workflow with git, and utilize multithreaded processing.

What's next for Browser Vault

With our newfound knowledge in website building, we plan on attending more hackathons and building more ambitious projects because we find the challenge of programming with a time constraint very fun. However, that doesn’t mean that we will leave Browser Vault behind. We want to continue this project as not only a way to pique our interest, but to potentially develop an application for the advancement of education as a whole, where scenarios like these will not force the field to use subpar tools.

Try It out

Hackathons

Technologies

css, github, heroku, html5, java, javascript, swing

Devpost Software Identifier

256585