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

Add ability to hide source application #5126

Closed
2 tasks done
jomo opened this issue Sep 28, 2017 · 8 comments
Closed
2 tasks done

Add ability to hide source application #5126

jomo opened this issue Sep 28, 2017 · 8 comments
Labels
security Security issues and fixes, vulnerabilities suggestion Feature suggestion

Comments

@jomo
Copy link
Contributor

jomo commented Sep 28, 2017

Revealing the source application of toots could be considered (low level) unwanted information disclosure. Some users might like showing which apps they're using while others might argue that it's nobody's business which app a toot was sent from.

For Twitter, there are actual tools that gather this data and show which applications a user uses to what percentage – or even at which times of a day, which can be used to gather information about this user. There are crazy people on the internet and they use this kind of OSINT to find patterns in application usage (combined with other patterns) in order to doxx people.

Example: At which times of a day is a user probably at home (tooting from desktop) and when are they probably not (tooting only from phone for a while)? For how long are they leaving home each day and at which times? How many different devices (applications) does this user own? …

If a user decides not to reveal the application, it should be hidden from both API and the web interface.


  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
  • This bug happens on a tagged release and not on master (If you're a user, don't worry about this).
@MightyPork
Copy link
Contributor

MightyPork commented Sep 29, 2017

for the record, this is how we could tell which Trump's tweets were from Trump and which from someone else: http://varianceexplained.org/r/trump-tweets/

@nolanlawson nolanlawson added enhancement security Security issues and fixes, vulnerabilities labels Oct 1, 2017
@Sylvhem
Copy link
Contributor

Sylvhem commented Oct 1, 2017

I think the RFC 6973 could be of use here. One of the main recommendation of this RFC is to reduce the data sent about users.

@ghost
Copy link

ghost commented Oct 2, 2017

How about not recording it at all?
User-Agent strings will be sent to servers, but I see no point in all the "sent from web" "sent from pidgin" "sent via airplane" etc to be in the UI, all it does is to provide people potentially with the ability to gather data.

@jomo
Copy link
Contributor Author

jomo commented Sep 26, 2018

It's been a year since I filed this issue and coming to think of it again, I fully agree with @Sylvhem and @ng-0. I don't see any real benefit of this information being recorded and/or exposed.

I'd be happy to submit a PR that removes this.

@Gargron do you have any thoughts on this?

@trwnh
Copy link
Member

trwnh commented Sep 27, 2018

@jomo I think there's a separate request to expand the from-client abilities to include muting by app source, so that you could mute "Moa" or "Mastodon Twitter Crossposter". (#8271) The problem is that right now, iirc, client names don't federate, and this info shows up only for local users. That was perhaps the biggest historical use of the source field, for 3rd-party Twitter apps to be able to mute crossposted tweets from Facebook or YouTube or other sources.

From a technical standpoint, application is already nullable and in fact applied to all remote statuses. I think application sources should be reworked to meet the following:

  1. Always federate application, so that eventually they can be used as a muting criteria in a separate issue
  2. Allow users to selectively remove this information if they want to, somehow? I'm not sure which way makes the most sense

@Gargron
Copy link
Member

Gargron commented Sep 27, 2018

I don't see any real benefit of this information being recorded and/or exposed.

Reasons to expose application:

  • Help promote apps (third-party app ecosystem). Mastodon does not have an official app, and cannot point everyone to one app they should download. Letting people see which apps other people use, is therefore the only way in Mastodon itself that any apps can be linked (other ways are all outside Mastodon itself, e.g. documentation)
  • If an application you previously authorized suddenly begins posting spam from your account, it's easy to see which one it is

@jomo
Copy link
Contributor Author

jomo commented Sep 27, 2018

I think spam identification and application based muting are some valid points. I suggest that the account owner can decide for each application whether or not they want to display the source application publicly.

Something like this (the wording could be improved):

screenshot

Of course, the owner would still be able to see the source themselves.

@Gargron Gargron added suggestion Feature suggestion and removed enhancement labels Oct 20, 2018
@trwnh
Copy link
Member

trwnh commented Feb 24, 2019

Fixed by #9897?

@Gargron Gargron closed this as completed Feb 24, 2019
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 suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

6 participants