Basically yes. If you use "inspect element" (right-click in any of Chrome, Firefox, IE, Opera) you can see in the inspector that there's a bit of boilerplate around the HTML string. The description string is injected into a div which becomes the only element in the body of the iframe's document. The head of that document contains a reference to the default stylesheet, "InfoBoxDescription.css".
A few versions ago (1.6 and prior, maybe?) we didn't use an iframe, the description box was a normal div in the page. For security against un-trusted descriptions, we ran the description string through Google's Caja script, to sanitize it. But the default settings there were extremely strict, as they need to be, and many seemingly simple HTML tags were being removed for the sake of security. So the description couldn't handle much in the way of custom styling, and the whole mechanism depended on an open network connection to Caja.
Luckily, browser support for "sandboxed" iframes has improved a lot over the past year, and is now robust enough that we felt we should make the switch. So, no more dependency on Caja and its heavy-handed filtering. Instead, your HTML description is injected into a sandboxed iframe complete with custom images and custom styling. Even if it's a user-supplied description string, they shouldn't be able to run scripts or steal login auth cookies etc. so long as the sandboxing is left on. If you turn the sandboxing off, make sure all of your descriptions come from "trusted data" within your own app, not anything supplied by users (or, run the user-supplied stuff through Caja or similar).
--Ed.