Thanks for reporting. Confirming.
I uploaded a random image as F2737099 with my private @Malyacko account (by dragging that image to the "Comments" field of a task) and can confirm that https://phabricator.wikimedia.org/file/edit/2737099/ shows "Visible To: @Malyacko" instead of "Visible To: Public".
Going to https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ as a Phab admin, "Default View Policy" (for newly created files) is set to "Public (No Login Required)" though.
Not sure what's going on here. @mmodell: Any ideas?
Could this possibly be a problem with the unfamiliar policy, "Files attached to objects are visible to users who can view those objects?"
I can see that a screenshot that I uploaded that wasn't attached to a task defaulted to an only-author-can-view policy but a screenshot that was attached still had that restrictive policy but "inherited" the view policy from the task.
Oh I see: That image was not added via drag and drop (which does set the same permissions as for the task) but via the explicit "Files" upload and only after that linked into a task.
Now it all makes sense. Thanks for explaining. My fault.
@mmodell: Glaisher, Aklapper, and me all saw that unlinked files were private, owner-only protected (could this be a bug?)
Also, files that were linked to a private task would inherit its private policy. If a private file was uploaded without being linked, I would like to think the user would be responsible enough to set it to a private policy. There are other more subtle accidents a user can make other than not setting the policy on a private file uploaded (if something is private I always double check; contrary, I don't check on public things). I think that setting files to public when not linked isn't such a bad idea. Correct me if I'm wrong.
Here's a non-drag-and-drop upload:
It used "public" as the default policy.
When uploading directly into a text field, the file assumes the policy of the object it's attached to. It's not important that people be able to access the file via the /files/ application because they can access it from within the task or mock that it was attached to. The files application isn't really meant to provide a way to browse all files on phabricator and I don't see any benefit to having a file publicly accessible there. When a file is attached to another object, it effectively exists within the other object's namespace / policyspace. What benefit would be gained by changing the current behavior?
Oh I see. When a file is uploaded via drag-and-drop it inherits the policy from the task and the Files policy is set to private because its assumed the file wouldn't need to be accessed by Files but if its just generically uploaded without drag-and-drop it uses the public policy.