Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement text blocks #6494

Closed
wants to merge 1 commit into from
Closed

Implement text blocks #6494

wants to merge 1 commit into from

Conversation

akihikodaki
Copy link
Contributor

@akihikodaki akihikodaki commented Feb 17, 2018

This is a response to:
Un carattere indiano fa crashare iPhone, Mac e iPad | MobileWorld
http://www.mobileworld.it/2018/02/14/carattere-indiano-crash-iphone-mac-ipad-144881/

Because such a problem is expected to occur also in the future, this kind of feature would be necessary.

This implementation is primitive and has rooms of improvements, but works.

UPDATE:

  • Implemented various improvements. Now it supports logging and severity "silence", and is usable not only for security purpose, but also for moderation purpose. The silence feature is expected to be used to exclude aggressive words from the public timeline without interfering users' activity.

  • The "reject" severity reports what word is prohibited in its error message. It is like HTTP 451 and to prevent arbitrary censorship on the fediverse.

  • Spec and edit feature is pending.

UPDATE:

  • All features has been implemented.

@akihikodaki akihikodaki added the security Security issues and fixes, vulnerabilities label Feb 17, 2018
end

def create
text = params.require(:id)
Copy link
Contributor

@abcang abcang Feb 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think :text is better than :id.

@nightpool
Copy link
Member

nightpool commented Feb 17, 2018 via email

@akihikodaki
Copy link
Contributor Author

shouldn't app developers block text snippets that have issues on their end, before rendering?

No. I believe Mastodon's Web UI supports iOS.

why do we have to add this added complexity to mastodon for one Apple bug?

Not only for one bug. Not only for one product. That kind of problems occurred many times in history of the Internet. I have not mentioned in the first comment, but it is obvious that there are much more examples if it comes to the necessity of text filtering: not only security, but moderation, legal, censorship, etc.

@@ -50,6 +50,7 @@ defaults: &defaults
activity_api_enabled: true
peers_api_enabled: true
show_known_fediverse_at_about_page: true
blocked_texts: []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not necessary anymore

@Gargron
Copy link
Member

Gargron commented Feb 19, 2018

The more I think about it the more I am entirely uncomfortable with the subject of this PR.

@akihikodaki
Copy link
Contributor Author

Indeed I would not use instances with arbitrary text blocks, especially if they are with "reject" severity. That's why here is this pull request. This change assures to tell users what texts are rejected:

Prohibited text: %{text}

This change complements the room between the ideal situation and the reality; the instances may be forced to reject some texts because of security (e.g the recent iOS case), or legal. An instance owner can still show he has nothing to hide by using the feature even if he he cannot help certain texts.
In other words, if he doesn't use the feature and still rejects some texts, he has something to hide deliberately. That is what I want to show.

@ghost
Copy link

ghost commented Mar 8, 2018

Feel likes a censorship tool to me. When it's cause of legal issues, an instance owner can choose between:

  1. suspend the user
  2. moves its instance to another jurisdiction

@akihikodaki
Copy link
Contributor Author

When it's cause of legal issues, an instance owner can choose between:

This pull request is not to help an instance owner to deal with legal issues but to tell an user how the owner is dealing with.
As I noted earlier, text blocks are implemented in the way that:

  • not intrusive ("silence" severity) or
  • acknowledgeable ("reject" severity)

The actions you suggested are extreme and may not be possible. Instead of requiring them to the owners, this allows users to know how the owners deal with problems and migrate to another instance if necessary.

@kvanbere
Copy link

kvanbere commented Mar 26, 2018

Consider, a hypothetical kids.social might want to block half a dozen things that are unsafe to young kids: swearing, cursing, racial slurs, derogatory terms, certain nouns. I don't think its evil to allow site admins to block text as long as it is transparent.

In the above example, even transparency could be an issue.

At the end of the day the site admin is the one paying for the instance. If they don't want a certain thing there, that's their choice (not yours). If you don't like it, can't you just pick a different instance?

@Gargron Gargron closed this Jun 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security Security issues and fixes, vulnerabilities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants