eriner_

Ah, that's what you're referring to. As I mentioned in a comment on the previous thread (which I now see you commented on two days ago), we didn't want to require phone numbers for verification and went the email-only route instead. Unfortunately there was a not-insignificant amount of abuse from temporary email addresses. Because they are temporary and throwaway accounts and we have no way of reliably contacting the humans behind those accounts, our best option was to prevent players from using accounts with those throwaway domains.

As you stated in your other comment, it sounds like you got your money's worth. Accounts can still be registered with non-throwaway emails.

Can you be specific and less vague? I don't understand what the issue is.

Even if it reproduces (proportionally) small sections of code it's been trained on verbatim, its function is transformative and will likely be deemed fair use. This lawsuit is going nowhere other than the HN front page.

I use zsh and have the following alias (rather, function):

``` cp () { rsync -avhW --progress --inplace ${@} } ```

If I ever need to use the `cp` binary, I execute `=cp`, which evaluates to `/bin/cp`.

I felt like prepending the domain was a reasonable request so I've added that as a checkbox. Thanks for the feedback!

Regarding the versioning, perhaps that could be manual editing of the email? or using a different "v2" salt?

Correct! This is why I explicitly said the following in the blog post I linked above:

> Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.

Arbitrary file read vulnerabilities are extremely common.