Comment 69 for bug 48734

Schools have started installing/upgrading to 22.04.1 and we're just now seeing this.

This change takes away the ability of the users to share some of their data WITHOUT involving the administrator.
It's not "privacy by default", it's "mandatory privacy".
Privacy by default could be done with umask or with a pam script that ensures the sensitive subdirectories are 0750.

Administrative actions can mitigate the issue, but they're tricky as they cannot easily be applied to users that haven't logged in yet and folders that don't exist yet.
Sudoer scripts that would give the ability to the users to share stuff by themselves can be a worse security risk.

On the other hand, encrypted home directories is a trend with similar issues.

I guess it'll be a bit easier to rewrite all the "system-wide" programs that need access to /home/username to use other locations such as /run/user/XXX, /home/shared/XXX, /home/public_html/XXX, /var/lib/AccountsService/users/user/face.png, /var/spool/* etc,
than to introduce an XDG specification for a new /home/user/private directory, and rewrite all the programs that need private or encryped data to use that one. That would be a much cleaner solution, but it can't be a goal for a single distribution.

So while this change does require us to spend some weeks reimplementing our shared folders software, it might be for the best, let's see how it goes.

Btw, the XDG_PUBLICSHARE_DIR="/home/user/Public" directory doesn't make any sense anymore after this change.
It might be worth it to try to standardize it to /home/Public/user/ instead, and see if other distributions will follow suit.
Then web servers and similar software could start using $XDG_PUBLICSHARE_DIR/public_html instead of ~/public_html.
Of course adduser etc will need additional patches to create the /home/Public/user folders, and delete them on deluser.