Overview of the Discussion

This discussion was similar to the one that we had last week and this was just talking about Legal and Ethical Concerns as well as Safe Computing. We talked about copyright and how legal methods are used to get information about people.

Section 5.5

There are two different types of licensing, open source and closed source. Open source allows people to view, access, and download code for a program, but closed source does not allow others to access a project or code of a project, and keep the code for themselves.

  1. When you create a GitHub repository it requests a license type. Review the license types in relationship to this Tech Talk and make some notes in your personal blog.

I saw two different tyoes of licensing from Github, Creative Commons License, MIT licensing, and GPL License. These licenses are what makes sure that people can get credited for their work and make sure they know when their work is distributed. The creative commons license doesn’t allow copyrighting and is given out for public use. MIT License is a closed source however, and it can be distributed but the owner should get credit for their work. Then in the Open Source GPL License, this one allows the owner to change the project except distribute closed sources. However, a MIT License might also work because it can help because it can allow others to use code, but the author is still credited.

  1. In your blog, summarize the discussions and personal analysis on Software Licenses/Options, Digital Rights, and other Legal and Ethical thoughts from this College Board topic.

I think that it is important for students to learn that most projects are open source because then it allows for many people to use the code and then the author is credited so others know that the code is not theirs, but is being used for educational purposes.

  1. Make a license for your personal (blog) and Team repositories for the CPT project. Be sure to have a license for both Team GitHub repositories (frontend/backend). Document license(s) you picked and why. FYI, frontend, since it is built on GitHub pages may come with a license and restrictions. Document in blog how team made license choice and process of update.

I personally went with an MIT license for my fastpage becuae I wanted other students to see my code and how I did something specificially. I want to be able to help students by providing my code publicly while also allowing them to credit me so that way, other people will know their code is not their’s, but used it for educational purposes. Our team decided to use MIT License as well because it is widely accepted and many people are already familiar with it and is simple to understand. Also, MIT License is allowed by our API’s and github-pages. However, I think we could have gotten away with GPLv3 Licensing because students can use our project and see how we implemented our API’s, and they can see it, but it makes sure they can’t steal our code even if they credit us.

Section 5.6

  1. Describe PII you have seen on project in CompSci Principles.

I have seen PII was when people tried to crowdsource for their projects. There were many google forms that we had to fill out for other CompSci groups so that they would be able to use that for their projects. Also on slack, when you click on someone’s profile, you can see their email. I am also seeing many projects where you have to sign up and they request an email.

  1. What are your feelings about PII and your personal exposure?

I do not feel super exposed in the Internet with my personal information. Whenever someone googles me, I don’t think they will actually find me because I have not done a lot in the public. I don’t have any of the famous social medias like Instagram, Twitter, or Facebook. I think you can only find my github profile and possibly my email. I think that PII can be dangerous and people use it to find out who exactly you are, I use this to see if I have seen a specific person beforre.

  1. Describe good and bad passwords? What is another step that is used to assist in authentication.

There are many examples of both good and bad passwords, but typically a bad password is something like the name of the website or your first name. Bad passwords can also be your personal info like your date of birth or name. A good password is typically something that is easy to remember, and is something that no one else knows about you. A good password consists of maybe one symbol varying lowercase and uppercase letters. The password would also be stronger if there were numbers in it.

  1. Try to describe Symmetric and Asymmetric encryption.

Symmetric Encryption is when only one secret key is used to encrypt and decrypt protected things. There is only one key that is used to encrypt and decrypt the content. Asymmetric Encryption uses a pair of keys, both public and private, and this helps because then information can be encrypted. I think that because asymmetric encryption uses two keys and can be more secure.

  1. Provide an example of encryption we used in AWS deployment.

An example of encryption that we used in AWS Deployment was SSL Encryption. I don’t really know what it does but it helps with the data. I think we did use SSH keys though when we were setting up our fastpages and also some RSA keys.

  1. Describe a phishing scheme you have learned about the hard way. Describe some other phishing techniques.

One time I received an email from a company that I trust. I usually receive emails from this company, but one day I got an email from the “company” and because I regularly got emails from them, I didn’t look to see if that email address was trustworthy. The email told me to click on a link, but the layout of the email was very different, and I was not exactly sure if it was from the company, so I checked the email address, and it looked fake. Other techniques include telling people they owe them money and then telling them to pay, or there might be more fees.

MIT License

Copyright © 2023 Edwin

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.