No, that would be the "copy the repository" approach. Private fork is when you do it through their UI.

As far as I know, it is not accessible.

Because you never git pushed to the fork it's not aware of your repo, you're ok.

What I don't know is if in 3 months you DO set your remote origin to that fork to for instance, pull upstream patches into your private repo, you're still not pushing, only pulling, so I would THINK they'd still never get your changes, but I don't know if git does some sort of log sync when you do a pull as well.

Maybe that would wind up having the commit hash available.

It’s not. The feature here works because a network of forks known by GitHub has a unified storage, that’s what makes things like PRs work transparently and keep working if you delete the fork (kinda, it closes the PR but the contents don’t change).

then it's fine

the issue is the `fork` mechanism of github is not semantically like a `git clone`

it's more like creating a larger git repo in which all forks weather private or not are contained and which doesn't properly implement access management (at least point 2&3 wouldn't be an issue if they did)

there are also some implications form point 1 that forks do in some way infer with gc-ing orphan commits (e.g. the non synced commits in he deleted repo in point 1) at least that should be a bug IMHO one which also costs them storage

(also to be clear for me 2&3 are security vulnerabilities no matter if they are classified as intended behavior)