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
Implement text blocks #6494
Conversation
end | ||
|
||
def create | ||
text = params.require(:id) |
There was a problem hiding this comment.
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
.
this seems like a bad idea. shouldn't app developers block text snippets
that have issues on their end, before rendering? why do we have to add this
added complexity to mastodon for one Apple bug?
…On Sat, Feb 17, 2018, 12:01 PM abcang ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In app/controllers/admin/text_blocks_controller.rb
<#6494 (comment)>:
> @@ -0,0 +1,36 @@
+# frozen_string_literal: true
+
+module Admin
+ class TextBlocksController < BaseController
+ def index
+ @page = params[:page]
+ @Texts = ***@***.***)
+ end
+
+ def create
+ text = params.require(:id)
I think :text rather than :id is suitable.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6494 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORV262XsSKTme5upvRs8Fhq6Zpm3g4ks5tVwX-gaJpZM4SJWw_>
.
|
No. I believe Mastodon's Web UI supports iOS.
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. |
0701f1c
to
c7ee68b
Compare
config/settings.yml
Outdated
@@ -50,6 +50,7 @@ defaults: &defaults | |||
activity_api_enabled: true | |||
peers_api_enabled: true | |||
show_known_fediverse_at_about_page: true | |||
blocked_texts: [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not necessary anymore
0d30b14
to
daf4393
Compare
The more I think about it the more I am entirely uncomfortable with the subject of this PR. |
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:
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. |
Feel likes a censorship tool to me. 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.
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. |
Consider, a hypothetical 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? |
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: