@a, @p and similar modifiers can be used in /tell command
Anyone can use "/tell @a Hello" to send private messages to everyone on the server.
Environment
Linux Ubuntu
Linked Issues
Created Issue:
/tell @a Hello -> Anyone can send message to *all* players
Anyone can use "/tell @a Hello" to send private messages to everyone on the server.
I find it hard to believe this could be a feature so I assume it must be a bug. If it's not a bug then shame on you.
Environment
Linux Ubuntu
Anyone can use "/tell @a Hello" to send private messages to everyone on the server.
I find it hard to believe this could be a feature so I assume it must be a bug. If it's not a bug then shame on you.
is duplicated by
relates to
is duplicated by
/tell @a Hello -> Anyone can send message to *all* players@a, @p and similar modifiers can be used in /tell command
duplicates
relates to
is duplicated by
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'.
Just tested this on 14w03b. Still an issue.
It looks like it just disconnects all of the clients, if it is typed once. But I've had abusive players spam this, causing the server to crash. There is also similar problems with /tell allowing players to use @a @p selectors to locate other player.
See: MC-40319
That's just what the /tell command does. @a targets all players, so this behavior makes perfect sense.
Maybe @a makes perfect sense, but it allows players to spam everyone with no log entries. Admin already has a hard time finding people who spam using clever methods. The @a selector just makes it even more annoying.
Also, things like @p[name=!myname] is very bad. Using certain /tell selectors enable players on a survival server to slowly pinpoint the position of other players. All selectors work, including x/y/z/radius. I don't think Any @ selectors should work for non-op. It destroys survival.
This. Agree 100%.
Still an issue in 1.7.4.
This is very much an issue, even in 1.7.4. It's now become impossible to play survival without risk of players or griefers finding out exactly where you are. It doesn't stop with @a, either. @r and @p work just as well. Players have been abusing this system to triangulate players using custom strings such as @a[x=0,z=0,r=1000] or @p[x=1000,z=-2000,r=100]. Using advanced trigonometry, a player can obtain the exact cords of a player in 3 whispers. Some players have been using it as "/me @p" to locate the person nearest to them, broadcasting it in public chat, or even using the more advanced aspects of the command to single out more specific players. What's one of the most annoying aspects of it is that in servers with many players, it's easy to spam chat and not trip the built in spam filter, or even avoid some scripts by either whispering a message using "/w @a @a" or sending a message in public chat by using "/me @a".
I strongly suggest reconsidering the status of this issue. At the moment it's impossible to play on any PvP server without someone using this method to find and kill you, and our server is having issues with people spamming /me @a @a @a @a @a and crashing the server. This is absolutely not "working as intended", or you might as well throw down player coordinates next to their names on the scoreboard. It should NOT be possible for normal players to use a command and find a player's exact location.
Agree with other commenters. I can use this with @p and coordinates to locate any other player on my server. As unknown says, 3 whispers and you can triangulate another user's base.
A simple fix would be to restrict regular players so that they can only use x/y/z/r modifiers in some local area around where they are currently standing. Actually restricting the "r" parameter is the most important to avoid easy exploitation. It would be nice to at the least provide a server flag to allow a server owner to restrict the usage of selectors in some way.
I think that this can be quite useful from an admin standpoint, whether it be using it for mini games, survival, rewards, etc., but I think it should be reserved to players with OP powers. That would make the most sense in the case of 'working as intended'. As Turnvax said, " It would be nice to at the least provide a server flag to allow a server owner to restrict the usage of selectors in some way.", I think that would be a decent option, too, if there is an option fit for each scenario.
Reopened
I'm not going to make any friends with this, butthis behavior can be heavily abused.Alex, what do you mean "I'm not going to make any friends with this ..."
Just ignore that.
It looks like @a doesn't work anymore in 14w02a but @p stilll does.
EDIT: Nevermind, @a is just broken.
In fact, it's worst than ever. In 14w02c, @e may now also be used:
Owch. I've been looking at the entities number in the F3 menu lately and with a view distance of 10 chunks seeing 6500 of them isn't that uncommon. PER PLAYER. How many messages go out with @e used in a tell command?!?
While @e no longer works, @a @p and @r still does. This means players can still triangulate other players in survival.
Observed in 14w08a and prior.
Sorry, but this still isn't 'Resolved'. I don't get why the mods here keep putting this bug on Resolved status while it's obviously still a problem.
Anyone can locate a player's exact coordinates just by a /tell command. You might as well create a '/getcoordinates <player>' command. Clearly this is not intended, and griefers are having a field day with this.
Please re-open this issue for the 3rd time, and don't make it 'Resolved' unless you can no longer use @a, @p, @r in commands if you're not an OP. Because that's clearly what the title states the issue here is.
"Resolved" does not mean "Fixed". It means that a decision has been made. In this case, I believe it's been marked a duplicate of
MC-43984, which unfortunately isn't showing on the ticket. I'm guessing thatMC-43984has been made private, as it relates to an exploit, and they don't want to publicize discussion on it. So take that as an indication that they are taking this seriously.Someone from Mojang looked at this less than 24 hours ago and indicated that "this barely even rates" as bugs go. So I take that as in indication that they are not working on this anytime soon.
https://twitter.com/TheMogMiner/status/437689512873828352
And Mog (Ryan Holtz), as wonderful as he is, primarily focuses on technical aspects like the rendering code, not gameplay. @Dinnerbone, @jeb_, @_grum, or even @SeargeDP all would have been better people to point such a question at.
You'll have to consider that people play Minecraft in a wide variety of ways, and that the way you play is not universal, not how the developers themselves play, not how many other people play, and thus not that big a deal to most of them. They may not really understand why this is a problem for you. It's probably not very high-priority, because it doesn't interfere with how they expect the game to be played. But tickets being marked duplicates of a private ticket strongly suggests that they're treating it as a possible exploit, even if it's not a high priority. The mods here have repeatedly stated that private tickets are only to be used for serious exploits or where personal information is at risk, and have changed the security settings on many tickets from private to public as a result.
@[Mod] Torabi: Yup
So there's a strong suggestion that there's a non-high priority fix. But it's even possible that vanilla non-arena PvP is now not considered universally supported anymore. Yup.
It's funny because on my server, there are a lot of people who are lousy at direct PvP. So they use distance from spawn as their only defense. Those players are now totally screwed.
But I can see how this is an odd situation. Not a lot of servers out there do the anarchy theme with the Mojang server jar.
Still observed in 14w11b.