Preventing cheating
If the peers told the host where they were and what they were doing in the game, and the host trusted them, peers could cheat. They'd simply need to suddenly send data saying they were the other side of a wall, or that they'd attacked a player they couldn't reach, and so on. To mitigate this, instead the peers only tell the host their inputs, such as which arrow keys they are currently holding down. The host receives this and starts moving that player, and sending data back telling that player where it thinks they are.
The immediate problem with this is that it adds a delay to all the player inputs. If a player presses 'Left' with a latency of 100ms, the host will receive that input 100ms after it was pressed. Then it will take another 100ms for the host's update with the new player position to arrive back. This would mean all the peer's controls feel very laggy, only taking effect after a significant fraction of a second. To resolve this, the peer's local game uses local input prediction.
Local input prediction
Instead, pressing left will send a message to the host saying the input was pressed, then that player's local game starts moving them anyway, without waiting for confirmation from the host! Since the host and the peer are running the same game, they generally match up pretty closely. Then the player gets controls which feel responsive, and they still can't cheat: they are only sending their inputs, and can't pretend to be somewhere else. Even if they hacked their local game, it only serves to disadvantage themselves, since all they can do is show themselves as being in the wrong place compared to the host.
The peer's player will however inevitably drift off the position that the host sees them. There are lots of small errors that can accumulate in network timing, framerate synchronisation, delta-time measurements and so on. The peer is still receiving messages from the host saying where they are, but the messages are delayed. In the previous example, the peer receives their position from the host with a total delay of 200ms. To correct deviations, the multiplayer engine looks at the object history and compares where it was 200ms ago. In other words, corrections are made looking at where the object was in the past, taking in to account the latency to the host. If the object is in the wrong place, the multiplayer engine will gradually move it to compensate. This happens over time to try to make it less noticable. In extreme cases a large and noticable correction will be necessary, but under good network conditions the movement matches up closely and small adjustments are made in a way that are difficult to spot.
It's worth noting this is not limited to positions. The multiplayer engine has the ability to do all this synchronisation with any instance variable, not just X and Y co-ordinates.
Lag
Under poor network conditions, there can be obvious effects on gameplay. Gamers commonly refer to these problems as "lag". It can include rough motion (when the 80ms update buffer is empty), jumps or discontinuities in gameplay (when packet loss occurs and the next update significantly change the game state), the player suddenly changing position (when local input prediction encounters a large error), or consequences that appear unfair (usually the result of each player seeing the game with a different delay, and the host making an authoritative decision in favour of one particular peer).
Unfortunately there is no good solution to permanently avoid these problems, other than to find a better quality Internet connection. These problems usually only occur under severe circumstances, such as complete packet loss for a few seconds, or sudden and extreme temporary changes in latency or PDV. In such cases it is almost impossible for the various compensation techniques to cover it up. This is sometimes simply the reality of communication over the Internet.