To complete David's answer, a switch learns who is behind a port by looking at the MAC addresses of packets received on that port. When the switch is powered on, it knows nothing. Once device A sends a packet from port 1 to device B, the switch learns that device A is behind port 1, and sends the packet to all ports. Once device B replies to A from port 2, the switch only sends the packet on port 1.
This MAC to port relationship is stored in a table in the switch. Of course, many devices can be behind a single port (if a switch is plugged in to the port as an example), so there may be many MAC addresses associated with a single port.
This algorithm breaks when the table is not large enough to store all the relationships (not enough memory in the switch). In this case, the switch loses information and begins to send packets to all ports. This can easily be done (now you know how to hack your network) by forging lot of packets with different MAC from a single port. It can also be done by forging a packet with the MAC of the device you want to spy, and the switch will begin sending you the traffic for that device.
Managed switches can be configured to accept a single MAC from a port (or a fixed number). If more MACs are found on that port, the switch can shutdown the port to protect the network, or send a log message to the admin.
About the youtube traffic, the algorithm described above only works on unicast traffic. Ethernet broadcast (ARP as an example), and IP multicast (used sometimes for streaming) are handled differently. I do not know if youtube uses multicast, but it might be a case where you can sniff traffic not belonging to you.
About web page traffic, this is strange, as the TCP handshake should have set the MAC to port table correctly. Either the network topology cascades a lot of very cheap switches with small tables that are always full, or somebody is messing with the network.