All players are allowed to use /tell with all its modifiers, this means that @a, @p and conditions of these like r= or name= can be used by any player and admin cannot restrict the use of either of these on default vanilla. This however has serious implications:
Using a command like
/tell @p[name=Dinnerbone,r=100] I know where you are :P
and slowly increasing the range condition until the message gets sent (if the player is not in range the tell command will fail with the message that the player could not be found) any player can pin-point the distance to any other player.
Doing this in 3 different locations, will then completely pin-point the targets location (coords).
To illusrate the method look at these pictures:
http://imgur.com/eTaUltz
See this picture as a top view on the map. The left to right Axis is the X axis, the top to bottom axis is the Z axis. Y coords of the player will be ignored in this method ( they dont matter too much anyways ).
A,B and C represent the positions of the player while using the above command. P would be the location of the target, in our case that would be Dinnerbone.
the smaller circle of each color is the last range where the /tell command failed, the bigger circle is the first range where the message did get sent.
As a result, the target player could be at any point that is in between all of the 3 pairs of min and max radii.
However in reality you would not use 3 sets of min and max radii, you would use the median of the min and max radii and get 3 radii as a result. The point where all of them meet is the target players position:
http://imgur.com/Cp2lDIl
Note that the result is not 100% precise, this however can be counteracted by using smaller distances for the min and max radii.
This method works for targets more than 40k blocks away from the player (but has a limit).
A normal player should never be able to find the location of another player in survival minecraft. Especially in PvP this can be and is being abused.
So how to solve this problem?
There are multiple ways to solve this, the most elegant way in my oppinion would be to simply disallow @a and the range condition for non-op players (disallow @a to prevent spam, different issue). Most of these conditions and modifiers where designed for map makers, admins and for the use with command-blocks in the first place, not for normal players.
A different aproach would be to limit the r= condition to the area visible by the player ( so that you can only send messages with r= to players the server already sent you the coords of (for rendering purposes) ).
The third and (in my oppinion) most un-elegant way of preventing abuse would be to simply change the messages displayed when the message gets sent or fails to be sent to be the same when using range conditions. This however would probably confuse most players.
I hope that this explained the problem with the command modifiers and conditions in an understandable way. If you should still have questions feel free to ask.
Kagamul
Linked issues
Comments 5
Yup it is a duplicate, you're nit-picking. The source of the issue is the same, you're just using it different.
Still, its neither 'resolved' nor 'working as intended. If this is a duplicate, then at least reopen the original one.
As long as a Dev can find the issue (while the problem still exists) I'm happy with it. Right now the original one has a misleading title and description and thus is closed and marked as working as intended. Something that is working as intended doesnt need to be reviewed by devs and thus will not be found / fixed. My issue is a duplicate and thus is closed as well. Thus everything posted regarding this problem will be ignored by all Devs by default.
I hope we can agree on that if the problem I have mentioned here exists in the game currently, then either the original one with misleading dscription (at the very least) has to be reopened, or they have to be seen as different issues.
If we dont agree on that, it seems rather pointless to post in this bugtracker at all regarding this problem, because it wont be found by devs anyways.
This is not a duplicate of MC-40319, while the ppl in the comments are talking about this, 40319 was about a different issue in the firt place.
Furthermore the problem I am taking about here is neither 'resolved' nor 'working as intended'.