YouTube

Google hat gestern in seinem API-Blog von YouTube erklärt wie man seinen Besuchern mehr Kontrolle darüber geben kann, wie ein Video von YouTube in der Webseite eingebunden wird. Mit einem alternativen Code kann man es seinen Leserinnen und Lesern auch möglich machen, dass sie Videos im WebM-Fomat anschauen ohne auf YouTube selbst zu müssen.

Die Lösung hierfür ist ein simpler iframe. Der Code für das einbinden schaut so aus:

Wobei VIDEO_ID der entsprechenden YouTube-Video-ID entspricht (nach dem http://www.youtube.com/watch?v=HIER die VIDEO-ID)

Der Player schaut dann so aus wie der Player auf YouTube, nämlich so:


Die Vorteile gegenüber des anderen Codes:
- Das Video kann auch im video-Tag von HTML abgespielt werden
- WebM ist ebenfalls möglich (bei beiden wird auf die Einstellungen des Nutzers (youtube.com/html5) zurückgegriffen)
- neues Design
- weniger Code
- iFrame ist W3C-valide
- sollte das Video bspw. wegen Werbung nicht im HTML5-Player zur Verfügung stehen, wird auf Flash zurückgegriffen
- Ist ein Besucher nicht teil der Beta von HTML5, wird automatisch Flash geladen
- mobile Geräte können nun auch auf ihre HTML5-Fähigkeiten zugreifen

Nachteile:
- man kann noch keine andere Farben wählen
- Thumbnail ist gelegentlich verzerrt

Bei neueren Artikeln wird nun der iframe-Code verwendet, der Feed liefert Videos weiterhin im normalen Code aus, da iframes von Google nicht dargestellt werden.

» YouTube API Blog
Google Das Google-Sicherheitsteam sieht die Praxis von Microsoft und co. als schadhaft an und möchte nun den Begriff "Responsible Disclosure", also "verantwortungsvolle Offenlegung" umdefinieren. Dazu hat sich auch der Sicherheitsexperte Tavis Ormandy gemeldet. Er hatte letztes Jahr eine Sicherheitslücke an Microsoft gemeldet, als diese aber nicht geschlossen wurde, entschied er sich, Infos über die Lücke im Netz zu veröffentlichen. Seit jeher beansprucht Microsoft den Responsible Disclosure für sich. Kein Wunder, dass es dann mal Monate oder Jahre braucht, bis ein Sicherheitsleck im Betriebssystem geschlossen wird. So hat sich Hacker Tavis Ormandy (der im übrigen beim Google Sicherheitsteam tätig ist) eine Lücke an Microsoft gemeldet, da aber sich über ein Jahr niemand meldete, ging Ormandy an die Öffentlichkeit: Er stellte den Bug kurzerhand mit Beschreibung ins Netz und kaum 24 Stunden später gab es erste Trojaner, die sich am Bug zu schaffen machte. Betroffen waren etwa XP-Systeme. Damit diese Zeit in Zukunft sinnvoller genutzt wird, hat Google nun den Begriff "Verantwortung" umgeschrieben. Bisher war die Praxis so, dass es gereicht hat, wenn der Hacker die Lücke meldet. Jetzt kann der Hacker auch eine Deadline von maximal 60 Tagen einrichten. Sollte sich dann der Hersteller der Software nicht melden und einen Fix/Patch veröffentlichen, so hat der Hacker das Recht, die Lücke ins Netz zu stellen, um den Druck auf den Hersteller zu erhöhen. So schreibt das Sicherheitsteam zum Thema im Blog: "[...] Daher glauben wir, dass die Responsible Disclosure eine Einbahnstraße ist. [...] Schwerwiegende Bugs sollten eine angemessene Frist erhalten. Obwohl jeder Bug einzigartig ist, sollten wir vorschlagen, dass 60 Tage Obergrenze genügend ist, um ernsthaft eine kritische Lücke in einer Software zu schließen." Weiterhin schlägt Google diese Änderung vor, damit die Softwarehersteller einen Stichtag haben, wo vielleicht schon Blackhat-Hacker sich an der Lücke zu schaffen gemacht haben. Dabei wissen sie aber selbst, wie schwer es ist, solch eine Deadline einzuhalten. Dennoch sollte es bei kritischen Lücken schnelle Hilfe geben, bevor er von Fremden ausgenutzt wird. Das erhöht den Druck auf den Hersteller und gibt eine bessere Sicherheit im Netz. » heise » Google Online Security Blog