Reasonable expectation of privacy is the legal test, I think. The courts have ruled that in public, there is none. Chicago is the most over-surveilled city I could imagine. For probably fire or six years, there have been a huge number of CCTV cameras, mostly at intersections. In iffy neighborhoods, they are even in the middle of the block. They have large microwave link antennas, and can have a clear line of sight in four directions. If you look around a a square mile or so of hte city, you will see that they are all pointed at the closest precinct police station. They have ligt bars fomn police motorcycles on top of the (bulky) radio unit. A friend lives in a second floor apartment, and they put one of these outside his window.There are more cameras in lower-class neighborhoods, but they are everywhere. (Chicago is a patchwork of about 200 culturally and economically distinct neighborhoods). Mayor Daley several years ago mandated that any business open after midnight has to have cameras. Now the police department wants to use fresher technology to put covert cameras everywhere.

The cameras are clearly meant to intimidate. Daley is a man who's authority is not to be trifled with, and I cannot help but think that the embarrassment his father suffered from the 1968 police riot produced a "never again" mentality around dissent. Chicago has a long history of identifying and suppressing potential or perceived dissent. The infamous "red squads" ferreted out thought crimes until the feds ended the Chicago Police Department's Subversive Activities Unit in 1985.

Some things never change.

The cameras are clearly meant to intimidate. Daley is a man who's autority is not to be trifled with, and I cannot help but think that the embarressment his father suuered from the 1968 police riot has produced a :never again" mentality in his thinking. Chicago has a history of identifying and supressing dissent. The infamous "red squads" ferreted out thought crimes until the feds ended the Chicago Police Department's Subversive Activities Unit in 1985.

Some things never change.

Most of what's being called serial here is asynchronous serial, meaning there's no external clock line. Each end of the connection has a clock that determines the baud rate, and so they must match in frequency within a couple of percent. There's a TX transmit line and an RX receive line and a ground wire in the minimal configuration. In a pc or an MCU there's a chip or an emulated version of same called a UART Universal Asynchronous Receiver Transmitter that takes care of buffering the serial bits as they come in (or go out of) the data wires One Bit At A Time. Many microcontrollers have built-in UART's. It used to be that the signal from a UART was universally converted to RS232 voltage levels. The spec says -12 volts is a 1 and +12volts is a 0. This is a really old standard that was invented to connect dumb terminals to mainframes through a modem. Several other wires are in the spec have to do with flow control and interacting with the modem. To get from 5 volt (or whatever) logic levels, a special line driver is used. A popular one is the MAX232 series of chips. These days the other lines in the RS232 cable are rarely used for their original purpose. The Arduino uses a flow control line to start the flash burner through a bootloader for instance. Async serial is very much still around because there are a large number of periperal chips and board-level modules that use a UART to communicate with an MCU or each other (sparkfun.com). In these applications, the voltage is at logic level. It is not shifted to RS232 levels, although you could do this if you needed to.
The serial port on the original PC is a DB9 connector. The UART's interface to the CPU is interrupt driven, so you can do pretty good real-time stuff. Since the async serial port us pretty much gone on PC's, a lot of devices like most cell phone cables use an emulated UART port running over USB. There are a couple of companies that make USB to 5 or 3.3 volt UART converter chips that implement the USB protocol. Rather than having to put the USB protocol it in the target processor, you buy the functionality. Of course there are MCUs that know the USB stuff, but they're a bit uncommon. Also there's the whole licensing problem if you roll your own USB device. So as strange as it is, designing with an 8-bt MCU, you'll use a chip with a lot more horsepower than the target to handle the USB interface. This is a very, very common thing to do. The other half of the problem is the host device drivers. FTDI make chips with no-cost drivers that are routinely used alongside a lot of 8-bit MCUs. There are drivers in the linux kernel for a handful of converter chips, and FTDI's are the best known.
The PITA for embedded designers is that the serial port emulated by the FTDI chip has buffering constraints and timing limitations (16ms latency) that basically ruin the real-time capability of the port. This really sucks. The alternative is to write your own drivers for Win, Mac, and Linux, and program your mcu to use one of the faster modes in the USB protocol than the one offered by the USB device class that includes async serial. For most people this doesn't matter. The host app on the PC uses its driver package that comes with, and you never have to know that your cell phone is using a 50 year old data link to talk to the pc.