Why use HTML to embed a video when you could use JS?

March 20, 2008 11:44 AM

Sites like Youtube, Vimeo, Blip, etc, all offer code to allow you to embed their videos in your own site, right? But why is that code invariably HTML, and not Javascript?

It seems to me, an experienced web developer, that offering javascript would offer you (the video provider) more flexibility.

Are there security implications I don't know about? If so, why is this different than the external JS calls I make to Google Analytics, etc?

posted by crickets to technology (13 comments total)

I think it's meant for easy insertion into CMS content like blogs, where you ordinarily can't run Javascript.
posted by mkultra at 11:51 AM on March 20

Probably because JS is turned off in about ten percent of browsers. And what mkultra said.
posted by Foci for Analysis at 12:06 PM on March 20

Theres big security implications in allowing the CMS of your site or blog or whathaveyou to contain scripts, and while EMBED tags arn't 100% guaranteed not to be unsafe they arn't quite so much of a headache, and also you can do things like check that they come flom a safe source, such as YouTube.

Also if the snippet of code is being inserted into some kind of container gadget (which is, for instance, how Windows Live Spaces shows Slide gadgets) after pageload using the javascript innerhtml property it won't actually excute.
posted by Artw at 12:15 PM on March 20

What benefits do you think javascript would provide? And sure, you could write javascript to manipulate the DOM in a way equivalent to adding the HTML directly, but I'm not sure what the point would be.
posted by Horselover Fat at 12:59 PM on March 20

Are there security implications I don't know about?

Take some time to read up on XSS. Everyone developing for the web should have a full understanding of what is necessary to protect yourself* against XSS (and injection) attacks. Javascript is probably one of the more common vectors, so it is almost always stripped from posts that come from an outside author, like comments, etc, and sometimes even stripped from the site owner's content. The stripping isn't always consistent, so even if you have a standard embed as well, you might have enough breakage so that nothing displays.

Meanwhile, once you've got the Flash file embedded, you have (as a video provider) almost all the flexibility you need (except interaction with the site in which the clip is embedded, which really, is more interesting for the site owner). No reason to add surrounding javascript that probably won't get there.** That said, Youtube just introduced an API that allows site owners to use javascript to control how the video is embedding, and there's been some neat demos already (bookmarking/comments for particular video times). You'll see more and more js used by site owners in the future for mashup applications, but it's in YouTube's best interest to stick with a dead simple embedding code that will work as many places as possible.

* as much as possible -- i think 100% protection basically means text only, like here on mefi. this often is not an option

** I've worked on some embed/object whitelisting santizer/filters for Drupal and it is a PAIN IN THE ASS working with all the different methods of embed/object that people have, much less throwing some javascript into the mix
posted by fishfucker at 1:04 PM on March 20

The biggest advantage would be not getting that nasty border around the flash movie in IE (the one mandated by an odd patent case) - inserting the movie via JavaScript gets around that.

Other possible advantages would be browser or plugin detetction of some kind, or even some kind of dynamic scaling, but that's all a bit much for something you cut and paste.
posted by Artw at 1:08 PM on March 20

fishfucker - When I worked with that kind of thing (again this was with Windows Live Spaces) for EMBEDs I would basically just grab the attributes I wanted from the EMBED and then rebuild it from scratch, ratehr than trying to directly use the users eMBED code, which would always be a pain in the ass.

That could lead to trouble if they had an odd scaling attribute or something though.

Anything that allows direct HTML is a huge pain in the asds, theres just so many ways to get JavaScript into it. Aparemtly you can execute JS in src attributes. Wh knew? Why the fuck would anyone want to do it in the first place? And yet you can.

Other tricks include using onFail or other obscure events, breaking up suspicious looking JS and then evaling it, etc... etc...
posted by Artw at 1:13 PM on March 20

HTML code is universially accepted and the easiest to put into a blog.
posted by Kioki-Silver at 1:21 PM on March 20

You can't run javascript on social sites, like myspace or bebo.

You need an actual script to use javascript, like swfobject.js would have to be on your website as well as the actual javascript code in the page--while it's small, it's not *that* small you'd want it in every instance of an embedded video.

What everyone else said re: security + CMS.

All in all, for the end user it is a better solution to provide a noncompliant bit of code that works in the most situations, with the most ease.
posted by shownomercy at 1:22 PM on March 20

When I worked with that kind of thing (again this was with Windows Live Spaces) for EMBEDs I would basically just grab the attributes I wanted from the EMBED and then rebuild it from scratch, ratehr than trying to directly use the users eMBED code, which would always be a pain in the ass.


huh. no idea why I didn't take that approach. it makes a lot of sense. the only trouble is if there are a myraid of params getting passed that are essential to the flash app, but i guess that's their bad if they need that.
posted by fishfucker at 1:25 PM on March 20

huh. no idea why I didn't take that approach. it makes a lot of sense. the only trouble is if there are a myraid of params getting passed that are essential to the flash app, but i guess that's their bad if they need that.

See Jon Postel's Robustness Principle ("Be liberal with what you accept, be conservative with what you send"). See Joel Splosky's critique, which though compelling is annoyingly incomplete.

The short of this, from my point of view, apropos to the development of systems like CMS:

Maybe its ok to be conservative with what you'll accept in cases like the above wherein:
1) Being very liberal with what you'll accept could quite easily lead to security problems.
2) What you'll accept is likely to be machine input rather than user input. [The assumption here being that any EMBED code a user submits to a CMS is likely to be copied from a media host like YouTube, and the further assumption is that the developers of said media hosts are likely, in following with Posel's Robustness Principle, to develop their sites in such a way that they only output W3C-valid code.]
posted by ChasFile at 4:07 PM on March 20

W3C-valid code

On immediate second thought that's a pretty major stretch, but likely ignoring things other than the most basic PARAMs, especially given that its coming from non-standard code, is ok.
posted by ChasFile at 4:11 PM on March 20

ChasFile - Hmm. There's also a counter principle of well trafficed sites (for instance: most blogs and social networking sites) – leave ANY opening for arbitary code and it will be used as a vector for XSS attacks. Sadly whitelists are very much the order of the day, unless you want your site to be a filthy security risk like MySpace.
posted by Artw at 4:40 PM on March 20