Yes, the owner would be the machine that owned the player controller of the actor in question.
In my example, it will allow you to filter which machines see the property change of a single actor, and in this case, it would be either the owner or not.
One thing you could do with this, is use a struct or something, and use the condition logic to only send that struct to the owner. Then, you can populate that struct with only information that owner should know about. The server can then take advantage of this, and use that to send and filter information to individual clients (it can populate each owners private struct differently, based on filters).
If you don’t mind the client getting the property, but then throwing it away (OnReps are triggered on the receiving side), AnXgotta has a perfectly reasonable solution, and we do this internally. This is slightly dangerous if you’re worried about cheating, since the client has this info, but is simply ignoring it. They would need a modified client to exploit this though.
If you absolutely don’t want the client having this information, you need to do this server side.
In your specific example though, of 3 players having vision of a unit. You could modify the relevancy checks, and factor in teams, or whatever filters you want.
So if a unit is visible to 3 of 5 connected clients, you could force false in the relevancy check for clients that shouldn’t see that actor.
AActor::IsNetRelevantFor is where you would want to look. This will work if you want to physically control which actors get sent to whatever connections.