Enhanced User Blocking and Privacy Controls

Overview

I suggest adding an optional stronger blocking mode to Scratch that would give users more control over who can access their profile and shared content.

Currently, blocking mainly prevents another user from interacting with you. However, a blocked user may still be able to access publicly shared content such as your profile and projects.

The proposed feature would allow users to choose between the existing blocking behavior and a stronger privacy block.

For example, imagine that someone is making fun of you, repeatedly bothering you, or refusing to leave you alone even after you ask them to stop. In that situation, you might not only want to prevent them from commenting or interacting with you, but also prevent them from viewing your profile and projects.

When blocking someone, users could also have the option to report them and explain why they are blocking them. This would make it easier for the Scratch Team to understand whether the block is related to bullying, harassment, repeated unwanted contact, inappropriate comments, or another violation of the Community Guidelines.

To help with optimization and avoid placing additional strain on Scratch's servers, this feature could initially be available only to Scratchers, rather than New Scratchers. This would limit the number of accounts using the feature while allowing Scratch to evaluate its performance and impact before considering wider availability.

Proposed behavior

When a user selects Block, Scratch could provide two options:

1. Standard Block

This would work similarly to the current blocking system.

The blocked user would not be able to:

* Comment on the user's projects.
* Interact with the user through supported social features.
* Follow the user or otherwise interact with them where blocking already prevents this.

2. Privacy Block

This would provide stronger separation between the two accounts.

A privacy-blocked user would not be able to:

* Open the blocked user's profile.
* View the blocked user's shared projects.
* Follow the blocked user.
* Comment on the blocked user's projects.
* Send messages or other direct interactions where applicable.
* Discover the blocked user's profile through normal Scratch searches.

This could be useful in situations where someone is repeatedly making fun of another user, harassing them, following them around the website, or continuing to interact with them after being asked to stop. A Privacy Block would give the affected user a stronger way to create distance and feel safer on Scratch.

Reporting while blocking

When a user blocks another account, Scratch could also display an optional Report this user option.

The user could choose to:

* Block the account without reporting it.
* Block the account and report it.
* Report the account without applying a block.

If the user chooses to report the account, Scratch could ask them to select a reason, such as:

* Bullying or harassment.
* Repeated unwanted contact.
* Making fun of or insulting another user.
* Inappropriate comments or behavior.
* Threats or intimidation.
* Spam.
* Other violations of the Community Guidelines.

The user could also be given a text box to explain what happened. For example, they could describe how often the behavior occurred, where it happened, and why they decided to block the account.

The report should be sent to the Scratch Team for review. Blocking the user should not automatically result in punishment, since the Scratch Team would still need to examine the report and determine whether the behavior violated the rules.

To protect users from false or abusive reports, Scratch could include a reminder that reports should be truthful and based on actual behavior.

Availability and optimization

To reduce the potential impact on Scratch's infrastructure, the Privacy Block could initially be limited to users with Scratcher status.

New Scratchers would continue to have access to the existing standard blocking system, while Scratch could monitor:

* Server performance.
* Storage and database usage.
* The number of privacy blocks created.
* Whether the feature causes additional moderation or technical issues.

If the feature works efficiently and does not significantly increase the platform's workload, Scratch could later consider making it available to more users.

This limitation would not be intended as a permanent restriction, but as a possible way to introduce the feature gradually and safely.

What would the blocked user see?

Instead of displaying the profile or project, Scratch could display a generic message such as:

“This content isn't available to you.”

This would avoid revealing whether the user specifically blocked them or whether the content simply isn't available.

For example, if someone is trying to view the profile of a user who has applied a Privacy Block, they would not see the user's projects, comments, or profile information. They would only see the generic message.

Technical implementation idea

The privacy block could be stored as a relationship between two accounts:

`blocker → blocked user`

When Scratch checks whether a user can access a profile or project, it could additionally check whether a privacy block exists between the viewer and owner.

For example:

`can_view(viewer, content_owner)`

could effectively include:

`if privacy_block(content_owner, viewer): deny_access`

The same type of permission check could be applied to:

* Profile pages.
* Project pages.
* User search results.
* Follow actions.
* Comments.
* Messaging/social interactions.

The system could also check whether the user has Scratcher status before allowing them to activate a Privacy Block.

This should be handled server-side rather than relying only on the website interface, so that the restriction cannot simply be bypassed by manually accessing a URL.

Important limitation

This feature would only control access through Scratch.

It would not necessarily prevent someone from seeing information that another person has copied, screenshotted, downloaded, or shared somewhere else.

It would also not replace Scratch's existing reporting and moderation systems. If someone is bullying, harassing, threatening, or repeatedly making fun of another user, the affected user should still be able to report the behavior to the Scratch Team.

The report option should also not be considered an automatic punishment system. The Scratch Team would need to review each report and decide whether further action is appropriate.

Why this could be useful

This feature would give Scratch users greater control over their own experience without removing the current blocking system.

It could be particularly useful for:

* Personal privacy.
* Avoiding unwanted attention.
* Separating interactions with another user.
* Preventing repeated unwanted contact.
* Dealing with someone who is making fun of you and will not leave you alone.
* Preventing a user from repeatedly viewing or commenting on your projects.
* Giving users a simple way to report the behavior while blocking the account.
* Helping the Scratch Team identify patterns of harassment or bullying.
* Giving users more control over who can access their Scratch presence.

A gradual rollout limited to Scratchers could also help Scratch introduce the feature without immediately increasing the platform's workload for every account.

Why make it optional?

Not every user needs this level of blocking.

Keeping the existing block and adding a Privacy Block would allow users to choose the appropriate level of privacy without changing how blocking currently works for everyone.

Making the feature initially available only to Scratchers could also help Scratch test it on a smaller scale before deciding whether to expand access to New Scratchers.

Making reporting optional would also be important. Some users may only want to block another account, while others may believe the behavior should be reviewed by the Scratch Team.

Possible UI

The blocking menu could contain:

Block user

* Standard Block
* Privacy Block

A confirmation dialog could explain what each option does before the block is applied.

For example:

Standard Block: Prevents this user from interacting with you through supported Scratch features.

Privacy Block: Prevents this user from interacting with you and viewing your profile and shared projects.

Report this user: Sends a report to the Scratch Team so they can review the user's behavior.

After selecting Report this user, Scratch could display a form asking for:

* The reason for the report.
* A short explanation of what happened.
* Links to relevant comments, projects, or profiles, if available.

If the user is a New Scratcher, the menu could display a message explaining that Privacy Block is currently available only to Scratchers, while still allowing them to use Standard Block and report the account.

Example situations

Here are some situations where Privacy Block and reporting could be useful:

1. Someone is making fun of you repeatedly.
They continue commenting on your projects or profile to mock you, even after you ask them to stop. Privacy Block could prevent them from accessing your content, while the report option could allow the Scratch Team to review the behavior.

2. Someone will not leave you alone.
A user keeps following you, commenting on your projects, or trying to interact with you after you have blocked them. A stronger block could create more separation, and a report could document the repeated unwanted contact.

3. Someone is targeting your projects.
A user repeatedly visits your projects and leaves unwanted comments. Privacy Block could prevent them from viewing or commenting on those projects. If the behavior violates the Community Guidelines, the user could also report it.

4. You want to avoid a specific user.
You may not want a particular person to find your profile or see what you share on Scratch. Privacy Block could give you more control without requiring you to unshare every project.

5. A user is behaving inappropriately.
If someone posts inappropriate comments, makes threats, or repeatedly harasses others, a user could block them and provide an explanation through the reporting form.

These examples would not mean that every disagreement should result in a Privacy Block or a report. Users should still use both features responsibly, and reports should be based on genuine concerns.

Conclusion

I think a stronger, optional privacy block would improve user control and privacy while keeping Scratch's existing blocking behavior available.

When blocking someone, users should also have the option to report the account and explain why they are blocking it. This could help the Scratch Team identify bullying, harassment, repeated unwanted contact, and other violations of the Community Guidelines.

It would also avoid requiring users to unshare all of their projects simply because they want to prevent one specific account from accessing their content.

Initially limiting this feature to Scratchers could make implementation easier, reduce the risk of overloading the platform, and allow Scratch to evaluate its performance before making the feature available more broadly.

This feature could be especially helpful for users who are being mocked, repeatedly contacted, or bothered by someone who refuses to leave them alone. It would give them an additional privacy tool and a convenient way to report serious behavior while still allowing Scratch's reporting and moderation systems to review each case.

Blocking Scratchers is a rejected suggestion:

Catscratcher07 wrote:

9.6 Blocking Scratchers
This suggestion refers to an optional system that makes it so that you do not have to see comments that a particular user posts. This feature existed in Scratch 1.4, but the Scratch Team found that it buried any problems rather than solving them. Even if you block a user, that does not stop them from harassing other Scratchers, and also does not stop them from making more accounts to harass you further. The Scratch Team also found that some would use the block button in ways that were unwelcoming to other Scratchers of a certain identity. For more information, see this post.

If someone is being disrespectful, be sure to report that user with the Report button, or use the Contact Us link if the situation requires more explanation.

However, a system to block users while simultaneously reporting them is NOT rejected. You can discuss it on this topic.

There is also clearly LLM use, as there is no existing block system.

This is similar, but not identical. This suggestion covers projects, not just comments.