markvp

Il DRM sfugge a BBC

Il gigante britannico vara la versione Apple del client che permette l'accesso ai contenuti tivų blindati. Ma sbaglia qualcosa e i contenuti vengono liberati

Roma - BBC sta rivoluzionando la propria posizione nei confronti del suo iPlayer: il discusso riproduttore multimediale, come preannunciato, rinnega il passato e non solo arriva su iPhone, ma si lascia inavvertitamente alle spalle anche il DRM.

L'uso tramite rete cellulare - che per iPhone al momento è limitata a EDGE, cioè 2,5G - non è ancora possibile a causa della scarsa velocità di collegamento. Nessun limite per l'impiego, invece, se si dispone di connettività WiFi, il che rende disponibile iPlayer anche sull'iPod Touch.

Perché proprio iPhone? "Abbiamo iniziato con l'iPhone perché è il più ottimizzato per il video ad alta qualità", scrive sul blog di BBC Anthony Rose, responsabile della divisione Digital Media Technologies. "L'iPlayer e i programmi di BBC sono visualizzati perfettamente. Ma stiamo lavorando per rendere iPlayer funzionale anche su altri apparecchi dotati di browser nei prossimi mesi".
"Č la prima volta - si legge su BBC News - che il servizio viene reso disponibile per apparati portatili" e in rete il tam tam è stato talmente veloce da svelare subito altre novità. C'è, infatti, chi ha scoperto che i server di BBC verificano prima di inviare il filmato se la richiesta proviene da un iPhone controllando lo user agent. "Invece di trasmettere streaming in Flash, ora viene trasmesso lo standard MP4 ma a chi non dispone di un iPhone non è consentito riceverlo", spiega il blogger che ha aggirato l'ostacolo adottando un semplice stratagemma.

La "manovra" è consistita nell'impiegare due estensioni per Firefox: User Agent Switcher e Firebug. La prima ha permesso, alterando lo user agent originale, di simulare l'ambiente iPhone, consentendo così l'invio del filmato. La seconda, un piccolo debugger che permette di curiosare in modo interattivo nel sorgente della pagina, ha permesso di individuare la URL esatta del filmato che, copiata nella barra degli indirizzi, consente di scaricare la clip e salvarla per riprodurla localmente. Di fatto il DRM viene così bypassato.

I lettori di Punto Informatico ben sanno che l'iniziale, strenua difesa del DRM e delle tecnologie proprietarie da parte di BBC aveva scatenato petizioni, cori di proteste e rimostranze di ogni genere, Open Source Consortium in testa. La Beeb aveva cercato un modo per placare gli animi, proponendo gratuità tramite determinati hotspot WiFi, con il risultato di sollevare invece ulteriori clamori. Ora dovrà invece combattere con gli smanettoni del wireless.

Marco Valerio Principato
20 Commenti alla Notizia Il DRM sfugge a BBC
Ordina
  • Non vorrei sembrare pignolo. Ma il DRM non dovrebbe essere qualcosa di ben diverso dal semplice check dello User Agent?

    Oppure mi sfugge qualcosa?
    non+autenticato
  • concordo.

    se sfugge qualcosa a te, allora sfugge anche a me.

    se un video è protetto da DRM, non lo si dovrebbe riuscire a leggere (senza autorizzazione) nemmeno se lo si è salvato in locale.
  • DRM = l'ennesimo Buco nell'acqua... o date le circostanze dovremmo dire nell'AQUA....

    Comunque Aqua o non Aqua il DRM ha le stesse possibilità di essere efficace che ha la distribuzione di un DVD con sopra scritto "vietata la duplicazione"..... anzi anche meno se si scordano la scritta!
    Tanto varrebbe limitarsi a quella!
    non+autenticato
  • Pare che tutti qui sappiano intercettare la URL della risorsa (con Ethereal/Wireshark o Firebug) e quindi scaricare il contenuto desiderato.
    Ma come si fa con i video tipo quelli di realplayer ? Sempre con wireshark riesco a recuperare l'URI del filmato ma è di tipo RTSP://
    Come faccio a scaricarmelo sull'HD ?
    non+autenticato
  • - Scritto da: Toshiro Mifune
    > Pare che tutti qui sappiano intercettare la URL
    > della risorsa (con Ethereal/Wireshark o Firebug)
    > e quindi scaricare il contenuto
    > desiderato.
    > Ma come si fa con i video tipo quelli di
    > realplayer ? Sempre con wireshark riesco a
    > recuperare l'URI del filmato ma è di tipo
    > RTSP://
    > Come faccio a scaricarmelo sull'HD ?
    non è questione di "scaricare" quanto di "catturare" quello che passa mettendosi "in mezzo"... chiaro?
    non+autenticato
  • > non è questione di "scaricare" quanto di
    > "catturare" quello che passa mettendosi "in
    > mezzo"...
    > chiaro?

    Abbastanza. In pratica dovrei mettere una sorta di proxy tra il realplayer e il server che fornisce il file. Giusto ?
    Ma che software utilizzo ?
    non+autenticato
  • Cerca RM recorder. Per i filmati che invece usano il Media Player usa WM Recorder.
    non+autenticato
  • Confermo Io ho usato WM e RM recorder e funzionano veramente bene.
    non+autenticato
  • Ethereal.... il modo infallibile per catturare gli url richiamati da pagine web e video in flash (i file .sfw che richiamano i soliti .flv).... utilizzato insieme ad User Agent Switcher fa accedere a qualsiasi risorsa HTTP che venga richiamata dal PC-mac-windows-linux spoofato....Occhiolino
    non+autenticato
  • Meglio non dare troppa pubblicità alla cosa, altrimenti finiranno di inviare contenuti "view only" credendo che non li sappiamo catturare su HD...
    non+autenticato
  • - Scritto da: Nome e cognome
    > Ethereal.... il modo infallibile per catturare
    > gli url richiamati da pagine web e video in flash
    > (i file .sfw che richiamano i soliti .flv)....
    > utilizzato insieme ad User Agent Switcher fa
    > accedere a qualsiasi risorsa HTTP che venga
    > richiamata dal PC-mac-windows-linux spoofato....
    >Occhiolino

    fai prima con firebug
    non+autenticato
  • Non conoscevo firebug, per ora ho sempre usato user agent e letto manualmente le pagine sorgenti per ricostruire l'url esatta dello streaming da passare ad un programma in grado di scaricarlo sul disco, vlc lo puo' fare anche dagli stream live ma non e' l'unico.
    non+autenticato
  • forse sto per scrivere una stupidaggine, ma io riesco a vedere l'URL di uno streaming QuickTime semplicemente facendo Informazione del filmato (Control/Command+I). Il risultato che ho è lo stesso oppure state parlando di una cosa diversa?
  • Ethereal adesso si chiama WireShark
    non+autenticato
  • - Scritto da: Nome e cognome
    > Ethereal.... il modo infallibile per catturare
    > gli url richiamati da pagine web e video in flash
    > (i file .sfw che richiamano i soliti .flv)....
    > utilizzato insieme ad User Agent Switcher fa
    > accedere a qualsiasi risorsa HTTP che venga
    > richiamata dal PC-mac-windows-linux spoofato....
    >Occhiolino

    mbhe adesso si chiama wireshark!... e mi pare decisamente un nome ahem... più adatto! A bocca aperta
    non+autenticato
  • Utilizzo User Agent Switcher di continuo insieme a Firebug, ma anche a Proxy Switcher per accedere all'inaccessibile.
    Da parte di chi sviluppa siti e portali è un errore madornale quello di inserire "in chiaro" l'URI di un contenuto ad accesso limitato nel sorgente della pagina quanto lo è quello di "sniffare" il browser via javascript o leggendo l'User-agent.
    Ogni browser ha funzioni e comportamenti diversi per cui sarebbero bastati due accorgimenti (le basi, signori, le BASI) per evitare tutto ciò:
    1 - che il browser venisse individuato per le sue peculiarità e non per la sola User-Agent-string (ad esempio si può, via javascript, dopo un controllo della stringa, controllare che una proprietà di un elemento della pagina come -moz-opacity restituissca errore)
    2 - inviare l'URI con un redirect lato server e non lato client

    Le basi, signori, le basi...
    H5N1
    1641
  • scusa ma se un contenuto deve essere acceduto dal client in qualche modo l'uri della risorsa deve essere resa disponibile al client stesso. anche se non "in chiaro", come dici tu, bene o male da qualche parte nella pagina deve stare. e non credere che una detection lato client delle capabilities del browser possa impedirmi di localizzare l'uri della risorsa all'interno della "pagina" e aprirla con altri programmi tipo VLC (in questo caso). IMHO non c'è modo di proteggere l'accesso ad una risorsa lato client in una pagina web. Punto. Se conosci un modo di farlo mi farebbe piacere conoscerla così comincio a usarla anche io.
    Punto secondo: Redirect lato server. Dipende da cosa intendi come redirect lato server.
    Se intendi sostituire la response di una pagina con il contenuto multimediale, questo non protegge in alcun modo.
    Non puoi intendere un HTTP 302.
    Quindi dammi qualche dettaglio... Davvero vorrei capire.

    Ciao

    Gene
    non+autenticato
  • Come al solito la certezza che le informazioni non vengano prelevate non esiste.
    Però, sempre come la solito, possimao rendere un po' più arduo il compito di individuare la risorsa.
    Ad esempio si potrebbe creare un'applicazione flash (anche in questo caso basta decompilarla e il gioco è fatto, comunque) che analizzi la richiesta e generi la risposta.
    Non sto criticando il fatto che la soluzione adottata sia "bucabile" poichè lo è tutto il contenuto di Internet, ma che lo sia TROPPO.
    Questi signori dovrebbero mettersi per prima cosa in testa che l'acceso pubblico è PUBBLICO: se vogliono pubblicare materiale accessibile solo in privato DEVONO creare un accesso privato con tanto di username e password.
    Anche in questo caso, però, come sappiamo la sicurezza è solo marginale.
    H5N1
    1641
  • - Scritto da: H5N1
    >
    > Le basi, signori, le basi...

    Ssssst! Zitto...
    Come osi dubitare della capacita' di programmazione di questi co.co.co di oltre manica, con patente europea, messi li' da intermediari che avranno incassato milioni di sterline?

    Hanno fatto un ottimo lavoro (per noi)!
    non+autenticato
  • redirect? perche', quello non lo sniffi?

    il modo corretto sarebbe creare lo stream direttamente dalla servlet a seguito di una qualche "autenticazione" del device...

    se trasmetti in chiaro mp4 cmq non avrai mai una reale sicurezza, l'unica (e relativa) e' quella che il client stesso decritti lo stream video tramite meccanismi drm
    non+autenticato