## Inspiration

Inspired by the rise and proliferation of facial recognition technology, we decided to take the increasingly important and nuanced matter of security into our own hands. Swiper No Swiping provides users with the peace of mind of knowing their devices and data will always be safe whether they are around curious hands or in large crowds. Our logo of the hedgehog mirrors the tale of the hedgehog and the fox, both in the comedic sense - as the popular character in Dora Explorer was a fox named Swiper - and in a metaphorical sense - as the fox represents the versatility of big data and the hedgehog represents the strength and resilience of security.

## What it does

Swiper No Swiping uses AWS Rekognition and multiple AWS Services to lock the device when an unauthorized face is using it. The faces of close ones can be added to the accepted list and the feature can be toggled on and off to provide our users with utmost versatility for their unique needs. Further, if the phone has been stolen and locked, the user will immediately receive an email notification through AWS SNS and will be able to log into our companion website for further support. On the website, users will be able to access their phone's location services to track down the phone and see updated photos taken by the front camera of the potential thief. Not only does this technology protect data and increase the chances of reclaiming a stolen phone, its proliferation will discourage phone theft.

## How we built it

Our project represented a unique challenge of having equal importance in web and mobile development - which were integrated through Amazon Web Services. The core of our technology is based upon AWS Rekognition, AWS DynamoDB, AWS S3, AWS Cognito, and AWS SNS which respectively provided us the tools for image recognition, data storage, secure authentication, and detailed notifications, all of which are integral to the product. Then, we used Android Studio, Java, and XML to build the mobile app and connect the user to the tech. As for the website, we used Javascript, HTML, and CSS to develop the content and styling of the website, then used Node.JS to retrieve values from AWS DynamoDB and AWS S3 and connect it with the rest of our project.

## Challenges we ran into

From the initial moments of the hackathon, we ran into issues regarding authentication of users, multithreading of 4+ threads, and modification of services to behave as activities. Though one of our members has worked with AWS briefly in the past, this experience still created many puzzling and rewarding moments. As we began web development, further issues ensued as neither of us had experience with back-end. As such, learning Node.JS and using it to serve HTML and CSS and retrieve data from AWS was a very intensive and at times frustrating process. Furthermore, the nature of asynchronous functions resulted in difficulties that caused us to pivot our designs last minute.

## Accomplishments that we're proud of

After this very tiring and fulfilling weekend, we are proud of have concluded with a project that consists of both an mobile app and a website, and with a slight disbelief of what complicated issues we have overcome and what simple matters we still do not understand. We're proud to have learned back-end and gained versatility in our respective development skills.

## What's next for Swiper No Swiping

To be entirely satisfied of a project made in 36 hours, or to be entirely satisfied of a project at all, is an unlikely occurrence. We hope to expand the capabilities of Swiper No Swiping by creating an option that locks certain apps such as photos or messages rather than the entire phone and we plan to leverage AWS's resources to scale the project to bring to more users. Also, we are aware that the website may result in legal issues, so we plan to gain a better understanding potential legal setbacks and restrictions so we can still carry out a product that protects our users. Furthermore, we wish to fine-tune the user-interfaces to be more cohesive with each other and create a more enjoyable experience.
# SwipeShield Project Story

## Inspiration

The idea for SwipeShield was born out of a growing concern for mobile security. With the rise in smartphone theft and unauthorized access, we wanted to create a solution that improves user authentication while maintaining convenience. The concept of using unique swipe patterns as a biometric measure intrigued us, leading us to explore how machine learning could be used to analyze these patterns effectively.

## What it does

SwipeShield is a user verification system that analyzes swipe gestures on mobile devices to distinguish between legitimate users and potential imposters. By employing machine learning algorithms, our app identifies swipe patterns and provides real-time feedback on whether the last few swipes match the user's behavior, improving security without compromising user experience.

## How we built it

We began by gathering swipe data using the Android Debug Bridge (ADB) to collect the necessary input for our machine learning model. After cleaning and organizing the data, we employed K-Means clustering to analyze swipe patterns and classify them into user and non-user categories. The project was developed using Python for the backend and Streamlit for the interactive web application, allowing us to visualize data and results in a user-friendly manner.

## Challenges we ran into

One of the primary challenges was ensuring the accuracy of our machine learning model. Tuning the parameters for K-Means clustering took several iterations, as we needed to balance the sensitivity of the model with its ability to avoid false positives. Additionally, integrating the data collection from ADB into a seamless workflow proved difficult, requiring us to troubleshoot various technical issues along the way.

## Accomplishments that we're proud of

We successfully built a functional prototype that demonstrates the potential of using swipe patterns for user verification. Our interactive web application showcases real-time analysis of swipe data, allowing users to visualize their swipe patterns and understand the clustering results. Furthermore, we are proud of our ability to work collaboratively as a team, leveraging each member's strengths to overcome obstacles.

## What we learned

Throughout this project, we gained valuable insights into the process of collecting and analyzing biometric data. We deepened our understanding of machine learning algorithms, particularly in the context of unsupervised learning. Additionally, we learned the importance of user-centered design, ensuring that our application is both secure and user-friendly.

## What's next for SwipeShield

Looking ahead, we plan to refine our model by incorporating more diverse datasets to improve its accuracy and reliability. We also aim to explore additional biometric authentication methods, such as touch pressure sensitivity and swipe speed, to improve security further. Our goal is to make SwipeShield a comprehensive security solution that adapts to users' unique behaviors while remaining effortless to use.
## Inspiration

Sustainability is one of the core pillars of modern progress. We wanted to address this challenge by thinking about how we could allow for substantial improvement in sustainability by optimizing an existing system. That's why we landed on LLMs: their **meteoric rise in popularity** has changed the way millions of people search for and learn information. That being said, LLMs are **extremely inefficient**when it comes to the compute required for inference. With hundreds of millions of people relying on them for day-to-day searches, it is evident that we have reached a scale where **sustainability needs to be carefully considered**. We asked ourselves, how can we make LLMs more sustainable? Can we quantify that cost so users can understand how many resources they use/save? The key to the idea is the fact that we wanted to propose a way to **dramatically improve sustainability with almost zero-effort required** from the user's side. These are the principles that make our proposal both practical and most impactful.

## What it does

In essence, we leverage **vector embeddings to make LLMs more sustainable**. Everyday, just on chatGPT, there are over 10 million queries made. Even over a small period of time, query overlap is inevitable. Currently, LLMs run inference on every single query. This is unnecessary, especially when it comes to objective queries that are similar to one another. Instead of relying on inference by default, we **rely on vector-based similarity search** first. This approximately takes **1/15 of the compute** that normal compute would take per query on chatGPT. Now, what makes LLMs desirable is their customization of responses. We didn’t want to lose this vital component by solely relying on embedded vector search. Thus, we give the user an option if they would like more information, and this defaults to a traditional LLM query. Thus, our approach allows for sustainability that is orders of magnitude higher than before, **without compromising what people like most about LLMs**.

## How we built it

For embeddings and our vector database, we used Pinecone. Our app is created with NextJS (ReactJS, TailwindCSS, NodeJS). We utilize the OpenAI api for traditional query requests. For our similarity search, we used cosine-similarity, and given that a query crosses our significance threshold, we return top 0-3 such queries for any given user input.

## Challenges we ran into

This was our first time working with embeddings and a vector database. Thus, we had some issues with setup and adding a new embedding to the overall vector space. We wanted the space to be dynamic so that answers generated for users can be shared by all users if someone were to ask a similar query in the future. Other than that, integrating all the required APIs was a challenge as some functions were async while others weren’t which caused state-update issues. Luckily, with some debugging, we were able to sort it out.

## Accomplishments that we're proud of

Our final version is a **fully-functional prototype** of our idea. We are also astonished by the real statistics behind the resources our system can potentially save. Additionally, we took UI extremely seriously because we wanted a system that was **intuitive and appealing** for users to use. We also wanted a clear way for them to see the benefit of using our platform. We believe we have accomplished this in a simple, yet capable UI experience.

## What we learned

We learned about how to use vector embeddings for similarity search. We also learned how to tweak the confidence threshold such that the relevant responses actually match the queries we are looking for. Above all else, we learned just how many resources are used in day-to-day usage of ChatGPT. When starting this project, we had a prediction about LLM resource consumption, but we completely underestimated just how large it would be. These learnings made us realize that **our project can have even more impact** than we had anticipated.

## What's next for SustainLLM

We want to take the same processes and **apply them to other modalities** like audio and image generation. These modalities require significantly more compute than text generation, and if we could save even a small percentage of that compute, it could lead to drastic results. We are aware that creativity is a pivotal part of audio and image generation, and so we would use embeddings for lower-level things such as different pixel patterns or phonetics. That way, each generation can still be unique while consuming fewer resources.

**Let’s save the environment, one LLM query at a time :)**