> I couldn't find a K-pop API, so I built one. Kpop has millions global fans but no proper REST API for developers building fan apps, bots, or tools (like me).
Because there's really not a need for a kpop-specific API? Your API doesn't really seem to provide anything that a generic music API doesn't provide.
I only stated why a kpop-specific API like this most likely didn't exist before, because generic music APIs (like musicbrainz) already exist and provide this same info.
If it solves his or someone else's problem, great.
> I uploaded a file and now I can't download it because the download endpoint is a 404.
Weird, looking at the logs it appears that the service worker didn't manage to register in your browser. Are you using some aggressive adblock by any chance?
I have to resort to registering a service worker and using it for downloads to make the decryption + download as a ZIP work for very large streams. The registered SW then gets added as an iframe, and that iframe triggers the download. In your case, it's as if the SW didn't manage to register so the added iframe led to nowhere.
> Except there is, it's 2GB or 100GB, you said it yourself.
Fair point - my phrasing was poor there. I meant that the architecture has no technical limits (unlike browser-based encryption which often crashes RAM on large files), whereas the 2GB/100GB are just business quotas to keep the lights on.
The architectural difference is actually why I built this. Standard E2EE services often choke on thousands of small files (because they attempt to upload everything with individual HTTP PUTs to S3) or struggle with massive single files (due to memory limits). By streaming encrypted chunks via WebSockets, aero.zip's setup handles 10k 1KB files or one 10GB file with roughly the same performance.
> stored in our database which was not compromised
Personally I don't really agree with "was not compromised"
You say yourself that the guy had access to your secrets and AWS, I'd definitely consider that compromised even if the guy (to your knowledge) didn't read anything from the database. Assume breach if access was possible.
It depends on what kind of access we're talking about. If we're talking about AWS resource mutations, one can trust CloudTrail to accurately log those actions. CloudTrail can also log data plane events, though you have to turn it on, and it costs extra. Similarly, RDS access logging is pretty trustworthy, though functionality varies by engine.
Most non-trivial security investigations involve building chains of events. If SSM Session Manager was used to access the EC2 instance (as is best practice) using stolen credentials, then the investigation would connect access to the instance to the use of instance credentials to access the S3 bucket, as both events would be recorded by CloudTrail.
CloudTrail has what it has. It's not going to record accesses to EC2 instances via SSH because AWS service APIs aren't used. (That's one of the reasons why using Session Manager is recommended over SSH.) But that doesn't mean CloudTrail isn't trustworthy; it just means it's not omniscient.
Ideally you should have a clear audit log of all developer actions that access production resources, and clear records of custody over any shared production credentials (e.g. you should be able to show the database password used by service A is not available outside of it, and that no malicious code was deployed to service A). A lot of places don't do this, of course, but often you can come up with a pretty good circumstantial case that it was unlikely that exfiltration occurred over the time range in question.
> $4,320 ($360/mo)
I don't see this price or that plan name on Canny's site. But then when I scroll down to your FAQ it says "Canny costs $1,200/year"
> $1,188 ($99/mo)
Featurebase is $29/mo for the growth plan.
And this wording:
> Enterprise features. Indie pricing.
You don't have enterprise features though? No SSO, no integrations, no SOC2 or similar
reply