Registered users should be able to add other registered users to their contact list.

The About page in Crypter.Web is out-of-date. The way we handle encryption and decryption has slightly changed since the page was first created.

Take another pass at the contents of the About page.

Navigating to a fake user profile will cause an unhandled error. Fix this.

Perhaps show a message such as, "This user may not exist".

Blazor WASM runs everything on the UI thread. This is fine for many things, but offers a horrible experience when we start doing some of the heavy cryptographic stuff. Creating asymmetric keys and encrypting large files can take forever. It also forces us to use smaller, less-secure asymmetric keys just to get by.

Investigate SubtleCrypto which should be available in every modern browser and will allow us to run our cryptographic functions asynchronously.

Describe the bug
The two options shown while performing a user search are "Search by username" and "Search by public name". "public name" is not the correct terminology.

Expected behavior
The option should use "Alias" instead of "public name".

The Crypter.Web project is using a mix of "DIY" HTTP requests and requests using the HttpService. Every request should go through the HttpService.

If something about the HttpService is not working properly, fix it.

For example, Crypter.API will often return a non-200 response in case an error occurs or a user submits some bad data. The HttpService throws an exception in these scenarios; eating the HTTP response body as a result. The response body of those requests contain valuable information that Crypter.Web needs. Need to figure out a better way.

Marking this as a bug due to the issue mentioned above.

Crypter.API and Crypter.Tasks are currently logging in to the production database as 'root'.

Create a new user with least privilege. Use this new user with our apps.

When one user sends something to another user, the web client create a random asymmetric key-pair. There is no need for this.

Use existing asymmetric keys when sending user-to-user items.

We should let users know they can share a link to their public profile. We should also let users know whether this link will work, based on their current privacy settings.

When a user views the page to decrypt a message, the Creation and Expiration times shown in the preview area are exactly the same.

The Expiration time should not match the Creation time. The Expiration time should be exactly 24 hours after the Creation time.

Putting our auth tokens in session storage is making the multi-tab experience awkward for users.

We should switch to storing our auth tokens in local storage.

The current method to insert a new Beta Key into the database is to manually login to the MySQL database and run a SQL query. This opens the door for user error.

It would be better if Crypter.Console had a command which allowed the user to insert a new Beta Key of their choosing.

We only require the user to enter their password once during sign up. Since we do not currently support password resets, we should definitely make sure users provide the correct password when they create an account.

The sign up component should require a user to enter t heir password twice. Do not allow the user to register if the two passwords do not match.

The "About", "Sign Up", and "Login" buttons are not visible using the following configuration. Try to fix.

Device: iPad (5th generation)
Browser: Safari
Orientation: Portrait only

To reduce the initial loading time of the web client and thus improve the UX, we should implement server-side pre-rendering of the web client.

This will change the web app's hosting model.

Saving a user's privacy settings will subsequently disable the "Subject" input field for that user, if they try uploading a message immediately after.

Visitors can sign up and login. We should refresh our privacy policy to indicate what data we collect and how it's used.

Whenever I try uploading a file that is larger than 3 or 4 MB using my cell phone, the encryption process takes literally forever; I always close the tab before it completes.

See if chunking the encryption step for larger files will help alleviate this.

Switch from RSA to ECC, in hopes that key generation will be much quicker.

Users are not automatically notified when they receive a file or message.

Investigate and implement email notifications.

Add a field to the user homepage, next to every received item, to show who an item is from. This can be "Anonymous" or a registered user (link to that user's profile).

A user received an empty GUID when attempting to upload a file named DEBOUT.500. This is because the front-end cannot determine the content type for the file.

The internet suggests using "application/unknown" in this case.

Add a "Remember Me" option to the login component. Ticking this option on login will store a 'refresh' token in browser local storage, as well as a copy of the token in the database. When a regular auth token expires, the user can get a new auth token using their refresh token.

We have a few different modal components that could probably all be standardized. I.e., share the same component.

Minimize the number of modal components. Standardize the UI for remaining modals (center-text, justified, etc).

Users are prompted to create their key-pair when they first log in. The UX is not great:

• Clicking the "OK" button doesn't always appear to work.
• There is no UI to indicate the page is doing work.

Implement a spinner and show some text that says, "Creating your asymmetric key-pair".

The mobile navigation menu looks a little wonky. Buttons are squished together and the "About Crypter.dev" link looks a little out of place. See if the UI can be improved a bit.

Describe the bug
Some messages are being unnecessarily written to the browser console whenever an authenticated user uploads something.

Expected behavior
These messages should not be getting written.

#64 Did not fully resolve the mobile performance problem for large file uploads. See if we can avoid reading in the entire plaintext file.

Crypter.Tasks is currently written as an ASP.net project. We should convert this to a console application.

Keep in mind, we may want to run additional tasks down the road. We may not want to run these new tasks at the same interval as our current tasks. Therefore, if we choose to run this console application as a cron job, the application will need to accept arguments.

Otherwise, we can configure the intervals within the console application itself. The application would always be running in the background.

In the mobile resolution of the web app, the navigation bar remains expanded after the user has made a selection (Sign Up or Login, for example). The navigation menu should automatically close whenever the user clicks an option inside the menu.

Who can see my profile:

• Users in my contact list
• Registered users
• Everyone

Who can send me messages:

• Users in my contact list
• Registered users
• Everyone

Who can send me files:

• Users in my contact list
• Registered users
• Everyone

With user data being stored across multiple tables, completely removing a user from the database would be a chore and prone to error if done manually.

Add a command to Crypter.Console to make the deletion of users easier. The command should either accept a Guid or a Username.

Example:
.\Crypter.Console -d User -u Mordeo
.\Crypter.Console -d User -i {guid}

In these examples I've overloaded the -d flag to accept a type of thing.

So we would also need to modify the existing command that deletes expired transfers. Perhaps:
.\Crypter.Console -d Transfer -e
Where -e indicates expired. This should also take -i {guid}

Describe the bug
Crypter.API only performs a single round of hashing when hashing passwords. This is highly insecure.

Expected behavior
Tens of thousands or even a hundred thousand rounds of hashing should occur. As many rounds as reasonable, without degrading server performance.

Navigating to a decryption URL for an item that does not exist will tell the visitor that the item they are viewing is intended for a specific recipient.

This message should be updated to include all the reasons why an item cannot be previewed:

• The item does not exist
• The item has already been deleted

We should not include "the item is intended for someone in particular" here. In the future, I intend to have separate URLs for items that were uploaded for no one in particular, versus sent to a specific person.

Forgot to update the returnURL when a successful login occurs to be "./user/home".

Need to add the dev branch to our workflow.

It doesn't make sense to allow Alice to access Bob's received items. Only Bob should be able to see the preview page and have the opportunity to decrypt his stuff.

Migrate Crypter.API to .NET 5.0

Describe the bug
Using Firefox's suggested password during user signup will tell the user their passwords do not match.

Expected behavior
The passwords should match. Do not show an error message.

Uploading a file or message that does not meet the API's requirements, of if the API just fails, will not show the user an error message. All the user may see is a decrypt URL containing an empty guid.

Update all file and message uploads to handle non-200 responses from the API.

We should not briefly show "this profile does not exist" when navigating to the profile of a user that does actually exist.

Insert some "loading" text instead.

Our authentication tokens are only valid for 24 hours. The web app does not detect that a user's token has expired when the user navigates back to the app after being away for a while.

When a user navigates back to the app, we should check to see whether their token is still valid. If the token is invalid or expired, log the user out of the web app.

Microsoft is no longer updating Blazor WASM in .NET Core 3.1.

Upgrade all the .NET Core projects to .NET 5.

If Alice has sent a message to Bob, that message will appear in Alice's "sent" items. However, this message does not belong to Alice. The message belongs to Bob. Only Bob may decrypt the message.

Do not provide users with a link to their "sent" items if those items were sent to someone in particular.

Describe the bug
Users are only able to update their profile information. There isn't any code which allows users to insert profile information for the first time.

To Reproduce
Steps to reproduce the behavior:

1. Create a new user
2. Attempt to set either an "Alias" or "About"
3. Save
4. See error

Expected behavior
Users should be able to set and save their profile information

Describe the bug
It's not ideal that brand new users do not Profile or Privacy records created on their behalf in the database.

Expected behavior
When a new user is created, add default records for them in the Profile and Privacy tables.

At the moment, all of our services are running on a single server. Those services are Web, Database, and Application (Crypter.Console).

Prior to moving forward with adding an email service, which may end up on a server of it's own, we should move the database service to a separate server. This new server should not be publicly accessible. I.e., all incoming connections are closed, unless those requests are coming from another Crypter server.

Reconfigure the apps running on the web server to use this new database server after it gets setup and the data is migrated.

We need to set a content security policy on the front-end to help prevent cross-site scripting.

https://docs.microsoft.com/en-us/aspnet/core/blazor/security/content-security-policy?view=aspnetcore-3.1

Add a field to the DecryptDetails component to show who uploaded the item. This can be "Anonymous" or from a registered user (link to the user's profile).