-
Notifications
You must be signed in to change notification settings - Fork 0
Ethical, Security, Legal
Ethical issues that could arise from our app and how we plan to solve them, and privacy expectation for our app.
- Users information will not be sent or sold to any third parties
- User data is sent between the application and AWS Amplify with Amazon’s own encryption software
- User can toggle their profile between public and private, so if they do not want people they do not approved viewing their profile or seeing their posts, they won’t
- We will have a report system for any comments or posts that are using hate speech. We will also have a system in place for users to block someone who they do not want to interact with
- As we develop our app we will make strides to ensure that the app is accessible as possible to anyone trying to use it. For example, there is not an issue in the app that should inhibit the access of anyone based on race, gender, or religion, and we will do everything possible to ensure that our app is accessible to anyone with disabilities
- A user could potentially use the app to post hate, or post pictures or videos that are not intended to be on our app such as violent or sexual content. This will be solved through the aforementioned report and block system, as well as a terms of service that every user must agree to before they can use the app. This would allow us to remove
The most sensitive information handled by our application will be email/username/password combinations since people often reuse these for more than one application. Our sign in process and storing of this sensitive information will be handled by AWS Amplify, specifically, we are going to use Amazon Cognito Users Pools. According to the AWS docs, "Data within Amazon Cognito is encrypted at rest in accordance with industry standards.". As for the encryption in Transit, all requests are made over Transport Layer Security Protocol (TLS). Both of these encryption options are modern and secure.
There is no other truly "sensitive information" that we are storing in our application, just private information. This includes information like old posts/pictures or personal goals. Since this information isn't truly sensitive as most of it has been seen by other users, the extent with which we protect it is much lower. We will protect this private data by having software controls governing who can request certain data. This will also be helped by AWS Cognito verifying user has the correct access levels for some of the data.
This section covers some attack vectors and details what steps we have taken to mitigate them. This is our protection plan.
All access to our databases and to the backend of our application is through AWS Amplify. Using this system we have one administrator account, and four developer accounts that can also access the backend. Each account is administered through Amplify with separate passwords that each of us, the developers, have individually set. The only realistic way for someone to access our backend would be to find out the password to one of our accounts and then login using those stolen credentials. Alternatively, someone could steal one of our laptops and access our backend if we were currently signed in, but that seems rather unlikely. Either way, currently our credentials are quite secure, but when we start getting real customer data in our app, we'll look into enabling 2FA to add another layer of security.
Since our application contains a lot of possibilities for user input as a social media application, malicious input is something we are aware and wary of. What follows is a list of potential attack vectors and how we are solving for them.
- Cross-Site Scripting, Since this is a JavaScript application being developed with React, this is still something we need to be worried about, despite only deploying the application to android
- This is actually natively solved for by React, according to their docs --> "By default, React DOM escapes any values embedded in JSX before rendering them. Thus it ensures that you can never inject anything that's not explicitly written in your application. Everything is converted to a string before being rendered. This helps prevent XSS (cross-site-scripting) attacks."
- Insecure Links, which is what happens when we generate clickable links based on user input
- Generally, we aren't going to be generating any links with user input so this won't be a huge problem. Having people post links in their Posts could potentially be a problem however, and we will discuss that in the next bullet point
- Phishing attacks via the Post feature (interaction with other users)
- The solution for this is to sanitize the data entered into Posts, or Goals, or really any interaction between two parties. At first, this sanitization will be very strict, i.e. not allowing links etc., but as we build out the app and find more secure solutions, or better ways to sanitize user input, we'll loosen this up a little bit.
Security issues that could arise from our app and how we plan to solve these potential problems.
- AWS Security measures provide users with data privacy and regulations to ensure data doesn’t get leaked. Users won't have any personal data stored other than their password, username, goals, and email.
- This shouldn’t be an issue, as videos won’t be posted. It could be possible a user would post a trademarked logo, but this is highly unlikely. (This also probably wouldn’t matter as its free advertising and the user isn’t making money)
- This can/ will be solved by giving users the ability to block other users.
- COPPA is a law that establishes a set of strict guidelines for online businesses to protect the privacy of children under the age of 13.
- The FTC considers the following to be “personal information” under COPPA:
- Email Addresses
- First and Last Names
- Screen Names
- Geolocation
- Instant Message Details
- Physical Addresses
- Telephone Numbers
- Hobbies/ Interests
- Photographs
- Video and Audio Files
-
Data protection principles:
- Lawfulness, fairness and transparency: Processing must be lawful, fair, and transparent to the data subject.
- Purpose limitation: You must process data for the legitimate purposes specified explicitly to the data subject when you collected it.
- Data minimization: You should collect and process only as much data as absolutely necessary for the purposes specified.
- Accuracy: You must keep personal data accurate and up to date.
- Storage limitation: You may only store personally identifying data for as long as necessary for the specified purpose.
- Integrity and Confidentiality: Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (e.g. by using encryption).
- Accountability: The data controller is responsible for being able to demonstrate GDPR compliance with all of these principles.
-
Individual User Rights Under the GDPR:
- Right to be Informed
- Right of Access
- Right to Rectification
- Right to Erasure
- Right to Restrict Processing
- Right to Data Portability
- Right to Object (Basically users don’t have to give out their personal data)
- Rights Related to Automated Decision-Making Including Profiling