Empieza La Fiesta De Drm...

[TheWind]

Pero hasta las ultimas noticias que yo tuve (hace no mucho en el espacio de economía de la ser) las empresas de juegos y sobre todos las discograficas seguian obteniendo beneficios (pingües por cierto) con respecto al año anterior. Yo ya empiezo a perderme...

Claro q tienen beneficios, si para que comenzasen a perder $ deberia haber unas 15 veces mas pirateo que copias originales, pero eso no es el tema a debate.

[TheWind]

 Fiero, creo q no captas qe que la idea es que en un par de años, los ordenadores, etc.. solo reproduzcan contenido DRM.

[fiero]

Fiero, creo q no captas qe que la idea es que en un par de años, los ordenadores, etc.. solo reproduzcan contenido DRM.

Eso es IMPOSIBLE.

[TheWind]

 no es imposible, de hecho ya ha sido propuesto varias veces y en un futuro los ordenadores llevaran ya de serie el tcpa/DRM, todo lo que no cumpla este estandard no funcionará.

[fiero]

 

no es imposible, de hecho ya ha sido propuesto varias veces y en un futuro los ordenadores llevaran ya de serie el tcpa/DRM, todo lo que no cumpla este estandard no funcionará.

Esto parece un chat XD.

¿Cómo evitas que un reproductor de OGG reproduzca OGG? O te puedo poner un ejemplo más cercano, yo he hecho un plugin gráfico. ¿Cómo puede evitar alguien que yo reproduzca una secuencia de imágenes en mi programa? Me bastaría pasar un vídeo protegido con DRM a un formato propio con solo la secuencia de imágenes (aunque sea grabandolo con una cámara en mi tele). ¿Van a evitar que cualquier programa pueda mostrar imagenes o audio en un ordenador?

[TheWind]

 Tan sencillo como que como tu codigo no ira firmado y con los permisos necesarios por parte de la autoridad tcpa/drm, no funcionara.

[zupervaca]

Tan sencillo como que como tu codigo no ira firmado y con los permisos necesarios por parte de la autoridad tcpa/drm, no funcionara.

esto no puede llegar a pasar, ¿estas diciendo que nadie podra programar en windows?

[senior wapo]

 Tal vez puedas grabar audio y video con una camara/microfono y perder calidad en el proceso, pero ¿ y los documentos ?

¿ Vas a fotografiar la pantalla del Acrobat Reader 600 veces y a pasarla por un OCR ? ¿ Y por qué deberias tener que hacer todas estas cosas ?

¿ Por qué ha de ser permisible que otros decidan como uso un ordenador que yo he pagado ? ¿ Por qué ha de ser permisible tener spyware por hard ?

¿ Acaso se ha decretado que las personas no deben tener libre albedrío y libertad de elección ? Vamos a decidir por vosotros, confiad en nosotros, es por vuestro bien. Cuando seais empresa ya lo comprenderéis. Id a ordenar vuestro cuarto y a recoger el dinero, que sino, esta noche os quedais sin WWW.

[senior wapo]

Tan sencillo como que como tu codigo no ira firmado y con los permisos necesarios por parte de la autoridad tcpa/drm, no funcionara.

esto no puede llegar a pasar, ¿estas diciendo que nadie podra programar en windows?

¿ Como ? ¿ Estas diciendo que ahora nadie puede programar para consola (sin pagar) ?

Eso es imposible, habladurías.  (twist)  

[fiero]

 Esa es una visión muy catastrofista y nada real. Una cosa es que el DRM por hardware te impida ver/copiar/duplicar los contenidos protegidos, y otra cosa muy distinta es que yo pueda crear una herramienta para crear y reproducir mis propios contenidos. Si vamos a tener que firmar cada chorrada que programemos nada más que para poder ejecutarla estamos listos, se acabaría el desarrollo. No tiene ningún sentido: si se acaba el desarrollo, los ordenadores pasarían a ser simples reproductores multimedia y herramientas para navegar y enviar correos, y eso NO va a pasar.

[TheWind]

Tan sencillo como que como tu codigo no ira firmado y con los permisos necesarios por parte de la autoridad tcpa/drm, no funcionara.

esto no puede llegar a pasar, ¿estas diciendo que nadie podra programar en windows?

No, lo que pasara es que tu escribes el programa, y cuando lo quieres  en otra maquina al enviarlo a ser firmado, no se firmara.
Esa es la idea ultima tras el concepto de TCPA/DRM, que nada que no haya sido firmado y autorizado por una autoridad pueda siquiera ser ejecutado.

[TheWind]

Esa es una visión muy catastrofista y nada real. Una cosa es que el DRM por hardware te impida ver/copiar/duplicar los contenidos protegidos, y otra cosa muy distinta es que yo pueda crear una herramienta para crear y reproducir mis propios contenidos. Si vamos a tener que firmar cada chorrada que programemos nada más que para poder ejecutarla estamos listos, se acabaría el desarrollo. No tiene ningún sentido: si se acaba el desarrollo, los ordenadores pasarían a ser simples reproductores multimedia y herramientas para navegar y enviar correos, y eso NO va a pasar.

Se acabaria el desarrollo independiente, no el de las grandes compañias, de ahi que TCPA/DRM sea algo tan jodidamente peligroso.

PD:El paso de apple a plataforma x86 no ha sido motivado mas que por la existencia ya de la tecnologia tcpa/drm para micros x86, cuando en power ni se habia planteado.

[TheWind]

 

Examples of abuses of remote attestation

Let's consider a few concrete examples of how TCG's attestation approach can harm interoperability or be used against computer owners.
1. On the Web

A web site could demand a software attestation from people wishing to read it. If they declined to provide an attestation, the site would refuse to deal with them at all; if the attestation showed that they were using "unapproved" software, the site would likewise decline to interact with them. Only those who could produce a digital certificate proving that their computers' software was satisfactory to the remote site would be permitted to use it. And this certificate could be produced -- in the current TCG scheme of things -- only if its contents were accurate.

Today, there is no really reliable way to achieve this effect. Therefore, attempts to coerce users into using particular software are currently ineffective; web sites are hard-pressed to control what operating systems and applications their users can use. Reverse engineering allows the creation of competitive new software that works well with existing software and services, and therefore computer owners have real choice. It is effectively impossible to punish them for choosing to use software other than that favored by those they deal with. If they want to use a different web browser or a different operating system, they know that they are unlikely to be locked out by the services most important to them.

For instance, some of today's on-line banking services claim to "require" Microsoft's browser, but users of other software are readily able to instruct their browsers to impersonate Internet Explorer. As far as the bank is concerned, its customers are accessing the site with the browser it demanded, but the users are not locked into technology decisions dictated by the shortsightedness of their financial institutions.

In a widely publicized case, MSN, the Microsoft Network, briefly refused to serve web pages to non-Microsoft browsers. In the interim, users of competitive products were able to fool MSN into thinking they were running Microsoft browsers. This would be impossible in an environment of routine NGSCB-style remote attestations. By allowing a web site to lock out disfavored software this way, these attestations would let anyone with market power leverage that power to control our software choices.

Security has nothing to do with many sites' motivations for preventing the use of disfavored software. Indeed, their reasons may be entirely arbitrary. In some cases, a site operator wants to force you to use a particular program in order to subject you to advertising. By verifying your use of an "approved" client, the site can satisfy itself that you have been forced to view a certain number of advertisements.
2. Software interoperability and lock-in

Software interoperability is also at risk. A developer of a web server program, file server program, e-mail server program, etc., could program it to demand attestations; the server could categorically refuse to deal with clients that had been produced by someone other than the server program's publisher. Or the publisher could insist on licensing fees from client developers, and make its server interoperate only with those who had paid the fee. (It is similarly possible to create proprietary encrypted file formats which can only be read by "approved" software, and for which the decryption keys must be obtained from a network server and are extremely difficult to recover by reverse engineering.)

The publisher in this case could greatly increase the switching costs for its users to adopt a rival's software. If a user has a large amount of important data stored inside a proprietary system, and the system communicates only with client software written by the proprietary system's publisher, it may be extremely difficult for the user to migrate his or her data into a new software system. When the new system tries to communicate with the old system in order to extract the data, the old system may refuse to respond.

The Samba file server is an important example of interoperable software created through reverse engineering. Samba developers studied the network protocol used by Microsoft Windows file servers and created an alternative implementation, which they then published as free/open source software. Samba can be deployed on a computer network in place of a Windows file server, and Windows client machines will communicate with it just as if it were a Windows server. (Similarly, Samba provides the means to allow non-Windows clients to access Windows file servers.) Without competitive software like Samba, users of Windows clients would be forced to use Windows servers, and vice versa. But if software could routinely identify the software at the other end of a network connection, a software developer could make programs demand attestations and then forbid any rival's software to connect or interoperate. If Microsoft chose to use NGSCB in this way, it could permanently lock Samba out of Windows file services, and prevent any useful competing implementations of the relevant protocols except by specific authorization.

Similarly, instant messaging (IM) services have frequently tried to lock out their competitors' clients and, in some cases, free/open source IM clients. Today, these services are typically unsuccessful in creating more than a temporary disruption for users. An attestation mechanism would be a powerful tool for limiting competition and interoperability in IM services. Some client applications could be permanently prevented from connecting at all, even though they offer features end-users prefer.

These are examples of a more general problem of "lock-in", often practiced as a deliberate business strategy in the software industry, to the detriment of business and home computer users alike. Unfortunately, the TCG design provides powerful new tools to enable lock-in. Attestation is responsible for this problem; sealed storage can exacerbate things by allowing the program that originally created a file to prevent any other program from reading it. Thus, both network protocols and file formats can be used to attack software interoperability.
3. DRM, tethering, forced upgrades, and forced downgrades

Many people have speculated that trusted computing technology is a way of bringing digital rights management (DRM) technology to the PC platform. Some portions of the trusted computing research agenda have roots in DRM, and Microsoft has announced a DRM technology (Microsoft Rights Management Services) that it says will make use of NGSCB. However, trusted computing developers deny that DRM is the main focus of their efforts, and trusted computing is useful for many applications besides DRM. Ultimately, DRM is just one of several uses of a technology like NGSCB -- but it illustrates the general problem that NGSCB's current approach to attestation tends to harm competition and computer owners' control.

The NGSCB design's elements can all be useful to implementers of DRM systems. Curtaining prevents information in decrypted form from being copied out of a DRM client's memory space, which prevents making an unrestricted clear copy. Secure output can prevent information displayed on the screen from being recorded, which prevents the use of "screen-scrapers" or device drivers that record information rather than displaying it. Sealed storage allows files to be stored encrypted on a hard drive in such a way that only the DRM client that created them will be able to make use of them. And remote attestation can prevent any program other than a publisher-approved DRM client from ever receiving a particular file in the first place.

Among these elements, remote attestation is the linchpin of DRM policy enforcement. If a remote system lacks reliable knowledge of your software environment, it can never have confidence that your software will enforce policies against you. (You might have replaced a restrictive DRM client with an ordinary client that does not restrict how you can use information.) Thus, even though other NGSCB features aid DRM implementations, only remote attestation enables DRM policies to be instituted in the first place, by preventing the substitution of less-restrictive software at the time the file is first acquired.

Other consumer-unfriendly software behaviors which can be implemented by means of attestation, combined with sealed storage, include tethering (preventing a program or a file from being migrated from one computer to another), forcing software upgrades or downgrades, and enabling some limited classes of "spyware" -- in this case, applications that phone home to describe how they are being used. (Some of these behaviors might be good things if they occur at a computer owner's behest, but not if they occur at a software publisher's or service provider's whim. For example, you might want to prevent a sensitive file from being moved off your computer, but you wouldn't want other people to be able to prevent you from moving your own files around.) Although all these unfriendly behaviors can be implemented in software today, they can in principle be defeated by well-understood techniques such as running a program in an emulated environment, or altering it to remove the undesirable behavior. Remote attestation makes it possible for the first time for a program to obtain and communicate reliable evidence about whether it is running in an emulator or whether it has been altered.

More generally, attestation in the service of remote policy enforcement leads to a variety of mechanisms of "remote control" of software running on your computer. We emphasize that these remote control features are not a part of NGSCB, but NGSCB does enable their robust implementation by software programmers. Lucky Green provides the example of a program written to receive from some authority a "revocation list" of banned documents it is no longer permitted to display. This mechanism would have to have been implemented in the software when it was initially written (or it would have to be added through a forced upgrade). If such a restriction were implemented, however, it would be essentially impossible for the user to override. In that case, some authority could remotely revoke documents already resident on computers around the world; those computers would, despite the wishes of their owners, comply with the revocation policy. The enforcement of this policy, like others, against the computer owner is dependent on the remote attestation feature.
4. Computer owner as adversary?

The current version of remote attestation facilitates the enforcement of policies against the wishes of computer owners. If the software you use is written with that goal in mind, the trusted computing architecture will not only protect data against intruders and viruses, but also against you. In effect, you, the computer owner, are treated as an adversary.

This problem arises because of the attestation design's single-minded focus on accurately reflecting the computer's state in every situation -- making no exceptions. A computer owner can disable attestation entirely, but not cause an attestation that does not reflect the current state of her PC -- you can't fool your bank about what browser you're using or to your other PC about what kind of Windows file sharing client you're running. This approach benefits the computer owner only when the remote party to whom the attestation is given has the same interests as the owner. If you give an attestation to a service provider who wants to help you detect unauthorized modifications to your computer, attestation benefits you. If you're required to give an attestation to someone who aims to forbid you from using the software of your choice, attestation harms you.

A user-centered, pro-competitive approach to attestation features would give the owner the power to guarantee that attestation is never abused for a purpose of which the owner disapproves, maximizing computer owners' practical control over their computers in real-world network environments.

Some trusted computing developers insist that their existing approach to attestation is reasonable because giving an attestation is voluntary. In every situation, they argue, you can decline to give an attestation if you prefer not to present one. (Indeed, TCG's design allows you to turn the TCG TPM chip off entirely, or decide whether to present an attestation in a particular situation.) But as we've seen, attestation can be used to create barriers to interoperability and access, so users will face an enormous amount of pressure to present an attestation. It's economically unreasonable to assume that a technology will benefit people solely because they can decide whether to use it.

We are not saying that the ability to communicate information about a computer's software environment is undesirable. This capability might well be useful for some security applications. We simply observe that the content of information about a computer's software environment should always be subject to the close control of that computer's owner. A computer owner -- not a third party -- should be able to decide, in her sole discretion, whether the information acquired by a third party will be accurate. This ensures that the attestation capability will not be used in a way contrary to the computer owner's interest.

[zupervaca]

 

Tan sencillo como que como tu codigo no ira firmado y con los permisos necesarios por parte de la autoridad tcpa/drm, no funcionara.

esto no puede llegar a pasar, ¿estas diciendo que nadie podra programar en windows?

No, lo que pasara es que tu escribes el programa, y cuando lo quieres  en otra maquina al enviarlo a ser firmado, no se firmara.
Esa es la idea ultima tras el concepto de TCPA/DRM, que nada que no haya sido firmado y autorizado por una autoridad pueda siquiera ser ejecutado.

¿y quien lo firma para mi ordenador? ¿cada vez que compilo el codigo fuente tengo que hacer que me lo firmen? sigo sin entenderlo

senior wapo: ¿ Como ? ¿ Estas diciendo que ahora nadie puede programar para consola (sin pagar) ?
Eso es imposible, habladurías. 

una cosa es pagar licencias para poder distribuir juegos en una consola y otra muy diferente programar para esa consola

editado: las preguntas que pongo no es en plan sarcasmo ni nada por el estilo, es que quiero enterarme bien como va a ir esto del drm antes de decir que bonito es o que ioputada

editado 2: ¿este sistema de firmado sera algo parecido a los certificados de windows?

[TheWind]

 Se supone que todo esto será online y que si, cada vesz o casi cada vez deberias recibir el codigo firmado

Y no, no es similr a lo de windows pq se basa en un sistema muy diferente