This desirable feature should be implemented for Data Center as well.

See https://confluence.atlassian.com/confkb/how-to-hide-content-s-author-created-by-for-certain-users-or-groups-in-confluence-1047559739.html

It's just terrible that there is no way to close access to this data and all previous edits from public access.

Not being able to fully anonymise pages makes it impossible for me to use Confluence for public consumption. I'm surprised this feature isn't standard.

We also have a Confluence Cloud instance with a publicly available space that we use for help documentation, and I agree with Jan that this would be very useful. In the spirit of this use-case, I'd also like to suggest hiding a few other things from 'public, read-only' users. I've tried to list the items grouped by why we'd like to hide them, although the overall intention is that we don't want to give away too much information and we don't want to give read-only users irrelevant things to click on, just in case it confuses them.

For Anonymous, read-only access, hide anything that shows our editing history, user names and anything thing else that shows 'how the sausages are made'

This includes hiding:

• The page byline that shows the page editor and when the page was last edited
• The Space Tools link - this shows when the space was created and the names of the administrators. Also, if you click this link, then you can see the 'all updates' link and see our entire editing history for all public spaces
• The "..." button. Currently anonymous users with read-only access can see these options: Attachments, Page history, Page information, Resolved comments, Link to this page, View source, Convert Gliffy diagrams, and a few more. (Although, perhaps 'Export to PDF' would be okay to keep, but I'm willing to lose it, if it meant everything else was removed too)

For Anonymous access, hide anything that will prompt users to login or give away information about non-public parts of our Atlassian instance (If possible, it would be nice to isolate public spaces from the rest of the site, even other public spaces. If we wanted to link to other spaces, then we could add links in the content)

This includes hiding:

• The 'Log in' link in the header - users without a login shouldn't need to see this, users with a login should know another URL if they want to login
• The application link on the top right - we have a link to JIRA here and we just don't want anonymous users to see it at all. If they click on it they get a login page, which is confusing.
• The 'Spaces' link on the top menu - the 'Site menu' lists space categories that are empty because it should be impossible for people with anonymous access to see them (e.g. 'Personal spaces', Archived spaces) and Categories that are only for internal use. When you click on an empty category, you get this message 'Spaces are great for keeping related content organized. To create a space, contact your administrator.' they shouldn't be given the option to create spaces if they can't even create pages.

For users with read-only access, hide items that are only useful to users with fuller Confluence access

This includes hiding:

• The entire Help menu in the header - this really only has items that are useful for editing Confluence
• The 'no labels' message - If there aren't any labels then, ideally, nothing would show. Currently, you can see 'No labels' and the edit button. If you click 'edit' then you can enter a label, and only then do you get an error. It shouldn't be possible to even click the edit button.
• Any messages about switching on a new Beta feature - in mid-2016 (i think), there was a button in the header to switch on a Beta for the new space navigation, this button was irresistable to one of our site's visitors and the end result was confusing.

We were hoping that we could use Confluence Cloud as a quick and easy way to make our documentation public (at least in the short term), but some of the above are quite problematic, because, as a public space, we have no control over who will see it, so we want to have very fine control over how much can be seen.

Background: https://answers.atlassian.com/questions/201399/different-versions-of-a-page