# Ozzy Secret Serverless Project


## Requirements

The application must act as a one-time-password share website like [onetimesecret](https://onetimesecret.com/).

The repo can and will be public in order to be shared.

### Basic components/pseudostories

* Frontend [Giorgio + Paolo]
* Must be able to upload new secrets/data
* Must be able to read secrets/data properly
* With the correct security policy constraints
* Must correctly record a view on a secret
* Ask the user to flag something before doing the API call?
* Use this time to warm up the lambda and optimize fetch times?
* Backend [tutti]
* Must be able to save data in a secure and deletable way
* Must be able to return a unique non-guessable non-enumerable url for a given secret
* Not a hash, same payload == different url
* Must be secure, no HTTP allowed
* Must automatically delete secrets when done with them (or after a given amount of time ~Mariano)
* Nice to have: pipable CLI tool (should be pretty easy in golang, even if I hate golang ~ Giorgio)

### Tech stack

* We need to use AWS stuff. Lots of it, as the whole application should leverage AWS services and be serverless by design.
* SAM
* Dynamo
* Lambda
* Api GW
* Cloudwatch + X-Ray
* S3
* Cognito [phase 2]
* KMS
* Code*
* Route 53 [phase 2]
* Parameter Store
* Frontend
* REACT
* Backend (have your vote-say down here)
* Python
* NodeJS [phase2]
* F# [phase2]

* Giorgio says: Python or F#. C# maybe.
* Giorgio is crazy but hear me out: Py == we're quick and gives best benefits in cold start and whatever. Clear cut first choice, but the environment is a pain. JS? Everyone is doing serverless in js, and performs a slice worser than py. F#/C#? No one is doing lambda in dotnet. Might be good for marketing purposes. F# is great and we occupy a niche that overlaps with the resurgence of functional programming (lambda is clearly "functional", in the sense that it's stateless~ish. C# is meh, but there are less resources on "C# serverless" than JS/Py so might be worth
* Other crazy idea: mishmash of languages. Yes, it sucks. Thats why I said it's a crazy idea
* Mariano says: NodeJS
* Riccardo says: Python

### To discuss

* Secret sharing policies
* Like what options to give users (time constraint, view constraints, etc.)
* Optimizations
* "Premature optimization is the root of all evil"...
* ...but don't shoot yourself in the foot too early.
* Cost optimizations?
* Lambda warmup time for secrets fetching? (I wouldn't worry about it. I'm more concerned about DynamoDB indexes and cryptography ~Mariano)
* Race conditions
* A UUID looks ok for the unique url that is generated, if a bit long. There is a nonzero chanche that the same UUID is generated. Can we **guarantee** the unicity of the generated url?
* Riccardo says: not sure why we couldn't use an hash (maybe Blake2b?) are there any constraints about this point?
* General security
* Encryption at rest? (Of course! ~mariano) (Sure!, I'd say data should be encrypted both from code and from AWS services at rest ~Riccardo)
* How to handle key management? ~Riccardo
* Treat less data as possible in order to not have to get cookie consent and blahblah gdpr blahblah?
* Require some form of authentication? (maybe optional?) ~Riccardo
* Analytics/Telemetry
* What, When, How to measure?
* Do we really have to? ;) ~Riccardo
* No, but it's honestly important. If you're not measuring you're not knowing what your user do, want, need, etc. Obviously skippable early (cw is enough?), but might be interesting to do (maybe just starting with you're uploading from website, from api call, from cli)
* Stylish stuff
* Private `pip/npm/nuget/maven/whatever` repo? To show the layer+package technique?

## Architecture


## References

- [amazon-api-gateway-url-shortener](https://github.com/aws-samples/amazon-api-gateway-url-shortener)
- Cool we can include it too! ~ Giorgio
- Shorter url could be easily guessable

## Product Roadmap

### Early

Implement basic requirements. SHIP IT!

### Midterm

Make it look good and patch security holes!

### When it's done it's done... (new features)

- Front end interface for secret management with user authentication (ex. paid/admin subscription to manage secrets)
- Complex/predefined type of secret (json, yml, key....)
- File share
- Whitelabel-ization (put name/brand/logos in conf, so you can override conf and brand it as you want)
- Email/SMS notification when a secret is retrieved
- Email/SMS notification when a secret is shared? and to whom? ~Riccardo
- ???