## Inspiration

We think improving cybersecurity does not always entail passively anticipating possible attacks. It is an equally valid strategy to go on the offensive against the transgressors. Hence, we employed the strategy of the aggressors against themselves --- by making what's basically a phishing bank app that allows us to gather information about potentially stolen phones.

## What it does

Our main app, Bait Master, is a cloud application linked to Firebase. Once the user finishes the initial setup, the app will disguise itself as a banking application with fairly convincing UI/UX with fake bank account information. Should the phone be ever stolen or password-cracked, the aggressor will likely be tempted to take a look at the obvious bank information. When they open the app, they fall for the phishing bait. The app will discreetly take several pictures of the aggressor's face from the front camera, as well as uploading location/time information periodically in the background to Firebase. The user can then check these information by logging in to our companion app --- Trap Master Tracker --- using any other mobile device with the credentials they used to set up the main phishing app, where we use Google Cloud services such as Map API to display the said information.

## How we built it

Both the main app and the companion app are developed in Java Android using Android Studio. We used Google's Firebase as a cloud platform to store user information such as credentials, pictures taken, and location data. Our companion app is also developed in Android and uses Firebase, and it uses Google Cloud APIs such as Map API to display information.

## Challenges we ran into

1) The camera2 library of Android is very difficult to use. Taking a picture is one thing --- but taking a photo secretly without using the native camera intent and to save it took us a long time to figure out. Even now, the front camera configuration sometimes fails in older phones --- we are still trying to figure that out.
2) The original idea was to use Twilio to send SMS messages to the back-up phone number of the owner of the stolen phone. However, we could not find an easy way to implement Twilio in Android Studio without hosting another server, which we think will hinder maintainability. We eventually decided to opt out of this idea as we ran out of time.

## Accomplishments that we're proud of

I think we really pushed the boundary of our Android dev abilities by using features of Android that we did not even know existed. For instance, the main Bait Master app is capable of morphing its own launcher to acquire a new icon as well as a new app name to disguise itself as a banking app. Furthermore, discreetly taking pictures without any form of notification and uploading them is technically challenging, but we pulled it off nonetheless. We are really proud of the product that we built at the end of this weekend.

## What we learned

Appearances can be misleading. Don't trust everything that you see. Be careful when apps ask for access permission that it shouldn't use (such as camera and location).

## What's next for Bait Master

We want to add more system-level mobile device management feature such as remote password reset, wiping sensitive data, etc. We also want to make the app more accessible by adding more disguise appearance options, as well as improving our client support by making the app more easy to understand.
## Inspiration

The inspiration came from the two women on the team, as the app is geared toward female security.

## What it does

A common issue and concern for women on dates is safety. Now that online dating sites are more popular, this raises the concern women may have about going out to meet their date-- is the person crazy? Will they hurt me? Will they abduct me?

While this web app cannot stop something from happening, it was meant to assure the woman that if she was taken against her will then a contact of choice or even the police will be alerted as soon as possible.

The idea is a woman makes a profile and enters her choice of emergency contacts. Before going out on a date, she would select the "DateKnight" option and log where the date was taking place, what time it was taking place, an uploaded picture of the date, a selected check-in time, and a selfie of herself before leaving.

When she is on her date, if she does not check into the app within 10 minutes of her selected check-in time, the emergency contact of her choice is then texted and alerted that she is not responding on her date and she may be in trouble.

After a specified time that alert is sent, if the user still has not checked in the police are called and alerted the location of where the woman should be. Now the date information the woman uploaded before can be used in finding her if she has been abducted.

While this was originally intended for women, it can be used by either gender to make the user feel like even if something were to happen then contacts and the police were quickly alerted that something is wrong.

## How we built it

We created the back end using MySQL in order to effectively store and access the users data across the web app. We also implemented PHP/CSS/HTML to create the front end and bridge it to the back to create core functionality. Using the Twilio API, we filtered fields from our database into real communications with demo users. All components are running a LAMP stack (Linux, Apache, MySQL, PHP) on an EC2 (Elastic Cloud-Compute) instance with Amazon Web Services. We are also using their Cloud9 collaborative IDE to work together in real-time on our project files. We acquired a custom domain (safetea.tech) from Domain.com and connected it to our EC2 instance.

## Challenges we ran into

The idea that we started out with (and spent quite a bit of time on) did not end up being the one we brought to completion. We initially wanted to create a web-app with Python for various data analysis purposes. Unfortunately, this soon became all about learning how to make a web-app with Python rather than how to create a useful implementation of the technology. One of our ideas was not reliant on Python and could easily be adapted to the newly chosen language. There was, however, no way to make up for lost time.

Programming in PHP, error messages were often hidden during the development process and made isolating (and therefore fixing) problems quite tricky. We also only had one member who had prior-experience with this stack's languages, but the general coding backgrounds helped them quickly acquire new and valuable skills.

## Accomplishments that we're proud of

We are proud that we have a demo-ready project. Though we most certainly faced our share of adversity (the person writing this sentence has a net 1 hour(s) of sleep and is so nauseous he does not even want the Insomnia cookies that were purchased for him; Well, they were not all for him but he has a large appetite for the soft, chewy, chocolate chip cookies of Insomnia (use promo code HARRYLOVESINSOMNIA), I digress), we worked together to overcome obstacles.

## What we learned

We learned that maybe if we had planned ahead on the 7 hour car ride like we were SUPPOSED to, then MAYBE we would have shown up knowing what we wanted to pursue and not had to madly scrape ideas together until we got one we really liked and was doable.

## What's next for SafeTEA

Another feature we talked about creating was one called “Party Mode”. The concept behind this is that if a group of friends is planning on going out and drinking they would all log the location they planned to be, the names and contacts of the people they were going with, and then a selected radius.

If the app sensed that a member of the group was outside of the radius selected, it would alert them first that they were too far and give them 10 minutes to get back to their friends. If they did not get back in that radius within 10 minutes, the other people they were out with would be alerted that their friend was beyond the set radius and then tell them the last location they were detected at.

This was designed so that if a group of friends went out and they got separated, no one would be too far away without the others knowing. If one of the friends were abducted and then taken far enough away from the determined location the others would be alerted someone was outside the radius and would be able to try and contact the user, and if given no response, the police quickly.

The feature would be able to be turned off if a member decided they wanted to leave early but would still alert the others that someone had turned it off in case they were not aware.

While this option appears on the web app home page, we were unable to link the location portion (the major component behind it) because we were unable to fund this.
## Inspiration

It sometimes feels so innate to find inspiration from everyday routine. One such case is when my teammates and I were on a group call when we discussed about how we got **calls from spammers \*\*almost every day and how convincing it seemed to everyone who talked to them for a while. As we discussed further we found the problem continued in the current technological world of social media where we find \*\*spams on Twitter** as well. So, we decided to create an app for the problems faced by people in the virtual world.

## What it does

The application is designed for easy usage while keeping every user in mind. The app targets **phone numbers** and **twitter accounts** of spammers and lets the users review the person behind it. The users can also look up the reviews added by other people on the platform along with relevant photos and tags. To make the app more secure we have **integrated OTP services** for new user registration.

## How we built it

We tried to build the application with a simple idea in mind. We made it keeping the everyday challenges that we faced in mind and all the technologies and software that we are good at. For seamless integration into all mobile operating systems we developed the front end using **React Native** and the back end was made using **Node.js** hosted on **Google Cloud** app engine for synchronous code execution. As for our messaging and OTP services we decided to go with **Twilio** for reliable connectivity anywhere in the world. We even used Twitter API for collecting and analysing tweets. Finally, for database management we incorporated **NoSQL Cloud Firestone** and consolidated **Google Cloud** storage for blob files.

## Challenges we ran into

The primary challenge that we ran into was the **long-distance communication** with the team. As the event was online our team was based from different parts of the world. With that we had different time zones. This led to lack of communication and longer response time. As we proceeded further into the event we **adapted to each other’s schedule and work**, which all in all was a great experience in itself.

## Accomplishments that we're proud of

While creating the whole project we accomplished a lot of things and overcame a lot of challenges. Looking back, we think that making a **fully functional app in less that 36 hours** is the greatest accomplishment in itself.

## What we learned

Our team enjoyed a lot during the project as we learned to make our way through. The key points that all of us can say we learned was **cooperation** and **efficiency** all while staying online the whole time. There was a unspoken understanding that we developed in the past few hours that we can say we are really proud of.

## What's next for SafeView

We developed SafeView keeping the future in mind. Our team has a lot of plans and hopes for the application. But first we will try to **improve our UI** and make it more user friendly along with covering **more test cases** for the better learning of the app and covering all possibilities. Finally, we plan to **add location for our app** and help real world users to stay aware of bad neighbourhoods all this while improving any bugs that we can find in the app.