RE: [backstage] 7 day BBC TV and Radio listings in XML!
> The feed contains daily snapshot of BBC TV and radio schedules for the > forthcoming week. We're offering it in TV-Anytime XML data format > (http://www.tv-anytime.org/). TV-Anytime contains some interesting new > flavours of metadata and is well worth exploring. Fantastic news - thanks! I heard a lot about TV-Anytime around 4 or 5 years ago but nothing much recently. Does anyone know if there are still plans to include CRID metadata in broadcast trailers? Tim - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
RE: [backstage] Timezone bug?
On Mon, 31 Oct 2005 14:32:11 - "Kim Plowright" <[EMAIL PROTECTED]> wrote: > The set-to-record from trailer is a great idea - and you're right, should > > be possible / doable. The problem is, i think, that CRID isn't widely used > > across the whole industry - i don't know if TV anytime is used by sky? I believe this was one of the driving use cases behind TVA, so certainly should be doable. In terms of Sky, the TV Anytime Forum was chaired by Simon Parnall of NDS - Sky's sister company that developed Sky+. I don't know how Sky use TVA data at the moment, but I have no doubt that they will! Tim - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
[backstage] RE: [backstage] RE: [backstage] RE: [backstage ] RE: [backstage] £1.2 billion question (or RE: [backstage] BBC Bias??? >Click and Torrents)
> On 06/02/07, Andrew Bowden <[EMAIL PROTECTED]> wrote: > > > On 06/02/07, Andrew Bowden <[EMAIL PROTECTED]> wrote: > > > > And yet it's still used... > > > > Doesn't that say something? > > > It says that record execs are stupid, but we all knew that already. > > > > I was going more for a "it might be broken by some, but it's good enough > > for 'purpose'". > > And what is that purpose, exactely? Deterring the general public from blatant file-sharing. Yes, it's beatable, but there are hoops to jump through before that file you've just download can be usefully shared, which the majority won't bother with. It's a first step. Security is almost never a simple choice between absolute protection or none. Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
[backstage] RE: [backstage] RE: [backstage] RE: [backstage ] RE: [backstage] RE: [backstage] £1.2 billion question (or RE: [backstage] BBC Bias?? ? >Click and Torrents)
Hi Dave On 08/02/07, Dave Crossland wrote: > On 08/02/07, Tim Thornton <[EMAIL PROTECTED]> wrote: > > Deterring the general public from blatant file-sharing. > > It fails at this purpose. I disagree. It fails at preventing all of the public from sharing files. > Firstly, file sharing in itself. Most importantly, this is very > unethical. Sharing is the basis of friendship, neccessary for > community, and important for a good society. To divide the basis of > friendship in the age of computer networks is deeply wrong. No > publishing is better than restricted publishing. Sharing is good for society, but only when sharing things you have permission to. I suspect we will never agree with each other about the ownership of music or specific cultural output, but I'm sure you can see my point if you think of a physical posession. My position on music was made up when I considered how I would react if a piece of music I composed were to be used to promote a cause I disagreed with. If music belongs to the public domain, then I have no ability to control who can use my creations. > Secondly, deterrents. For the general public, the deterrents do more > harm than good because they cut into private use that is allowed in > the law (or should be, cf Gowers). But isn't allowed as yet. ;) Nonetheless, DRM can allow fair use. > I can download BBC shows > transmitted through analogue radio broadcasts onto a VHS tape. I can > keep the copy as long as I want, and copy it to my portable video > player. I can download BBC shows transmitted through digital radio > broadcasts onto a file in my computer. I can keep the copy as long as > I want, and copy it to my portable video player. I can download BBC > shows transmitted through the Internet onto a file in my computer, > and my computer deletes it after 7 days, and I can't copy it to > any other device. There is something deeply wrong here. This comes back to the ownership question again. If I own the IP in a file, why shouldn't I be able to specify that you're only allowed it for a week? One of the complaints I often hear is that music companies are not adapting their business models to take advantage of the "Internet generation" - and yet the subscription model (ie explicit music rental) can only really work when the right to play the song for a restricted time exists. > To convert copy-restricted data into copy-enabled data, there may be > many hoops to jump through. For the first person, there will be many > many hoops. For the second, there will be less hoops. Eventually, the > hoop is "download this program and drag and drop your restricted data > onto it." The hoops can always be jumped, and collapsed to this single > one. This is not an 'implementation problem' - if it was, software > program proprietors would have implemented it 20 years ago. No, this /is/ an implementation problem, and can be overcome with a trusted hardware element on the platform. At that stage, the hoop will be more than simply running some code. > Say that there are a few hoops though, so "the majority won't bother." > For the minority who do jump the hoops, the copy-enabled data can be > shared. > > How many hoops do the recipients of the copy-enabled data have to jump? > > Zero. The primary aim is to reduce the number of sharers (cf sharees) > > It's a first step. Security is almost never a simple choice between > > absolute protection or none. > > Security is usually a charade, and security experts are usually > charlatans :-) :) I spend a lot of time with security experts. A few are indeed charlatans. Most are scarily clever! -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 08/02/07, Nic James Ferrier wrote: > "Tim Thornton" <[EMAIL PROTECTED]> writes: > > > No, this /is/ an implementation problem, and can be overcome with a > > trusted hardware element on the platform. At that stage, the hoop > > will be more than simply running some code. > > Do you work for ARM? I do, but I'm posting as an individual. > If so maybe you have a different perspective on > these things but it I think we all agree on the logic: > >DRM requires constrained computer hardware No, strong DRM requires a hardware element to be constrained. > the difference between you and Dave (and me! and Stallman!) is that > you are not worried about having a constrained computer. I welcome it. Having a region of my computer that is independent of the "regular" computer gives me confidence that I can hold secrets on my PC. The whole purpose of trusted computing in its widest sense is to provide an environment where anyone can have trust. There are many uses for it, often directly beneficial to the owner, and DRM is only one. In fact, it's not the strongest use case in my opinion. > I don't want a constrained comptuer because I don't trust the computer > maker to be open and above board about the precise way the computer is > constrained. What do you feel may be hidden? > And there's the rub. They won't trust us. So we won't trust them. The rub is that they/I don't trust large codebases to be bug free, so if you have secrets (do you have a PGP key?) you need somewhere protected to keep and manipulate them. Are we off-topic yet? ;) Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 08/02/07, Nic James Ferrier wrote: > "Tim Thornton" <[EMAIL PROTECTED]> writes: > > > Nic said: > >> I don't want a constrained comptuer because I don't trust the computer > >> maker to be open and above board about the precise way the computer is > >> constrained. > > > > What do you feel may be hidden? > > What do you feel a company might not hide? > > I think the attitude that led to the Sony fiasco last year is all too > prevalent. It's not particularly evil, it's quick fix that leads > people to do stupid things. If I don't control my computer then I > don't control those things. Ironically, one of the principal goals of trusted computing is to protect against things like the Sony rootkit. > It's a philosophical issue I grant you. But it's an important one I > think and the crux of the DRM issue. I believe it to be orthogonal to DRM. In the trusted computing space, your secrets are secret, as are mine. I can trust your computer not to reveal my secrets to you, and you can trust that I can't get at yours. > > The rub is that they/I don't trust large codebases to be bug free, so if > > you have secrets (do you have a PGP key?) you need somewhere protected > > to keep and manipulate them. > > So you don't trust code bases to be bug free so you have to trust a > corporation to not abuse your trust in a constrained computer? But the computer isn't constrained. There's an environment within it that is. You are right that the computer will need a "root of trust" which will be provided by a corporation, but when that corporation is founded on selling trust (think Verisign, Entrust, Thwate or whoever) the incentive to not abuse it is massive. > > Are we off-topic yet? ;) > > Oh yes. Do you think anyone's noticed? Seems not! -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 09/02/07, Nic James Ferrier wrote: > "Tim Thornton" <[EMAIL PROTECTED]> writes: > > > I believe it to be orthogonal to DRM. In the trusted computing space, > > your secrets are secret, as are mine. I can trust your computer not to > > reveal my secrets to you, and you can trust that I can't get at > > yours. > > But I see this as a bad thing: > > If you leave your secrets on my computer I want to be able to read > them. It's my computer. Not yours. Ok. But in that case I won't send them to you. If you invite my secrets to be on your machine, I want to know that they're secret. > If you were a criminal who used my computer I want to know what you > left on it. I'm sure. > > But the computer isn't constrained. There's an environment within it > > that is. > > I don't see the subtelty of this point at all. A computer with a so > called trusted element *is* constrained. If the facility is there it > will be used - it is surely nonsense to suggest that the trusted > component is there but won't be used? No, in the PC space it's only constrained if you want it to be. Most PCs sold today have a TPM, which is rarely used (I've only met one person so far who uses their TPM, and I work in the industry). You need to enable it. You can use it to constrain your PC if you want (eg by enforcing a secure boot process), but it is only the basis of trust on your platform. If you don't want other people to use it, you don't need to let them. > > You are right that the computer will need a "root of trust" > > which will be provided by a corporation, but when that corporation is > > founded on selling trust (think Verisign, Entrust, Thwate or whoever) > > the incentive to not abuse it is massive. > > Not a good example. All the SSL companies I know have had problems > with their procedures and sometimes abused their positions. I've not come across any such abuse, but ok. > Anyway, this is the root of the argument. Whether my PC is wholly mine > or whether there should be a feature within it that allows you to come > and put stuff on there that I can't tamper with (and I can do the same > to your computer of course). No - your PC /is/ wholly yours. There's a feature that allows you to invite me to put stuff on I can't tamper with. But I can't randomly take control of your computer. > A whole bunch of us don't like this. We do understand it. But we don't > like it. A whole bunch of people don't like this because RMS and Ross Anderson told them it was bad, but have no understanding of what the technology actually is. I'm sure you do understand it, but let's have the debate so that those who only hear the hype can make an informed decision. > So Nya. }:p -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 09/02/07, vijay chopra wrote: > There's not a single benefit that treacherous computing brings that cannot > be solved another way, in your example you can "hold secrets" via any > number of numerous encryption methods, my home PC has a whole encrypted > partition for data security. Why do I need a so called "trusted hardware > element" at all. Your PC has an encrypted partition - so how do you access the data on it? Somewhere you need a key that must be unencrypted. With a trusted computing system, you generate your private/public key pair in the secure element. The public key will be exposed, but the private key will never leave the device. > Oh, and where did you get the idea that DRM is a benefit > to the computer's owner? It's a benefit to me, in that I subscribe to an online music library for less than I used to spend on CDs. I have more music, and more money - I call that a benefit. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 09/02/07, Michael Sparks wrote: > "Tim Thornton" <[EMAIL PROTECTED]> writes: >... > > No, this /is/ an implementation problem, and can be overcome with a > > trusted hardware element on the platform. At that stage, the hoop > > will be more than simply running some code. > > Trusted element? Trusted by whom? The so-called "trusted computing" > platform is a double edged sword - whilst it can be used by a user to > implement a data store they personally trust[1] the situations where a it > is used by a remote party to trust the user, is from a users perspective > not trustable. > > The reason for this is it places an element of _their_ hardware under the > control of a third party. This is actually a _untrustable_ hardware > element from the perspective of the perspective of the user. There have > been somewhat less flattering descriptions of this. > > Personally I'd prefer it if people stated by *whom* such hardware elements > are to be trusted in these discussions. Personally I prefer to own > hardware devices that do what I tell them to, when I tell them to, and how. The difficulty with stating by whom the element is to be trusted, is that it depends on the application. For a disk encryption application, I trust the device, for a DRM application, the music provider trusts it, for a VPN encryption driver, my company trusts it. The commonality between all applications is that there is one party that /is/ trusted by all users, and that's the supplier of the secure element. If that trust doesn't exist, then the device is useless. > Otherwise you're (probably inadvertantly) continuing the false implication > that such systems are more trustable by their _owners_ whereas in practice > it depends on HOW such systems are controlled by software installed on > them as to whether the system is more trustable by their owners (safe > personal store) or by third parties. Absolutely. > [1] Since you can access the TCPA from userspace to store/retrieve keys to > make encrypting your own file system under your control & passphrase. > (There's a tutorial for this in a Linux World issue from about 3 or 4 > years ago which is quite interesting) > > (as an aside, given you can emulate a TCPA based system in software > however even that doesn't really actually solve your implementation issue, > since you just virtualise the entire platform including TCPA module - > which would of course happen if you provide people with a sufficient > incentive...) The TPM was designed with this in mind, and each TPM has its own keys. Because they're internal to the TPM and can't be extracted by software, you can have confidence in the TPM's authenticity. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 10/02/07, Michael Sparks wrote: > On Friday 09 February 2007 18:26, Tim Thornton wrote: >... > > I can trust your computer not to reveal my secrets to you, > > Do you not see how this is a bad thing - how this can be abused? > > I buy a car. It does what I tell it (well it would if I drove). I buy > a hammer it bangs what I want to bang. I buy a phone. It phones where > I tell it. I buy a general purpose computer, it does what I tell it. > Or should. I need to be able to trust *my* machines, if it doesn't do > what I tell it, I can't trust it. I don't want *my* property keeping > secrets from me. Your machine will do what you tell it to. It's just that there are secrets you can't access. That includes your secrets, you just get to use the result of their manipulation. This is good, because *your* property is keeping your secrets safe from rogue applications/viruses. As well as the ability to store secrets, the TPM also has some other abilities. It can "measure" the system as it boots, so you can be sure that the operating system and application loaded are what you're expecting. It also contains a monotonic counter - that's a counter that will only increment. That allows protection against replay attacks, where for example the system clock is rolled back to enable some demo software to be used for longer than the trial period. > If you do not trust me, but wish to deliver it by machine, then it is > up to you to provide to me a machine *you* trust, it is not up to me > to provide *you* a machine that you trust. If you are willing to provide me with a machine that I can trust, then I can deliver to you by machine. If you're not willing to provide that, we can agree to not transact. If the music industry are willing to deliver songs to you by machine, isn't it for you to provide that machine if you want to take advantage of that offer? Unfortunately, I had to buy my own CD player... ;) > Also, its a false "trust". Your "secret" is audio and video. That's > not a secret at all. In the DRM case, the secret is a rights object. That contains a decryption key and information about what you're allowed to do (number of plays, key validity). The plaintext audio/video is not nearly as valuable. > BTW, I'm not arguing the /technology/ is broken. After all, using the > same technology you can make things like secure personal storage are > more secure and trustable by the user: >* http://www.linuxjournal.com/article/6633 Now we're on the same page... :) Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 10/02/07, Michael Sparks wrote: > > The TPM was designed with this in mind, and each TPM has its own keys. > > Because they're internal to the TPM and can't be extracted by software, > > you can have confidence in the TPM's authenticity. > > This is wy off topic, but how does a remote third party that wants to > trust your system tell the difference between (for example): > > * A remote system that's just been bought that's using the TPM to securely > store keys for a secure store/streaming system > > * A remote system that is running a virtual machine that looks to the > operating system sitting inside that virtual machine as if it has a TPM > module, and that remote machine looks like its just been installed, and > the virtualised OS is otherwise installed identically. It's all about the keys installed at manufacture. Obviously, the TPM is just a computer itself (usually an 8 bit micro, but a computer nonetheless) and could be emulated in software. The security comes from the isolation of the TPM and the main computer - there is memory in the TPM that cannot be accessed from the big bad outside world. By placing a key in the device during manufacture (known as the Endorsement Key - Google Pt 1), there is an identification that cannot be spoofed by a rogue TPM. The public part of the Endorsement Key is signed by a certificate authority as belonging to a particular TPM. Now, an Attestation Identity Key is generated by the TPM for use by an application that wants to check the validity of the TPM. That's a private/public key pair that is signed by the private Endorsement Key. That new key can be sent to the certificate authority, who can check the Endorsement Key's signature - and also if that Endorsement Key has been revoked. If all's ok, the certificate authority signs the Attestation Identity Key, so the application (who also trusts the CA) knows the TPM is ok. There is also a more advanced method for validating the authenticity of a TPM without the need for trusted third party involvement, called Direct Anonymous Attestation. This presentation gives an overview of DAA: http://www.zurich.ibm.com/security/daa/daa-slides-ZISC.pdf Slightly more in depth presentation: https://www.trustedcomputinggroup.org/news/presentations/051012_DAA-slid es.pdf This paper describes in detail with proofs. Exercise for the reader! http://www.hpl.hp.com/techreports/2004/HPL-2004-93.pdf > For all intents and purposes the remote third party (eg a person wanting > to trust) should get the same responses from the secure system, and the > supposedly secure system. If the virtualised TPM has the correct EK, you'd be right. > I don't work with these things, but having read the linux journal > article[1] sometime back, and knowing how virtualisation works, and the > fact that any hardware system can be emulated I can't see how a remote > third party can truly tell the difference. > > [1] For anyone else, if they haven't read this, its worth reading since > you'll see that TCPA/TPM is a double edged sword that has many real > uses beyond things like DRM. (Once I read it, it struck me that its > primary use is for helping lock down a military laptop in the event > of it being compromised/stolen in an even more secure fashion than > people who are used to used an encrypted loopback device are used to) Thanks for mentioning that. Honestly, DRM != TPM. Although it's intended for day-to-day use in locking down enterprise PCs more than the military. For example, Vista's Bitlocker will take advantage of a TPM to store the drive encryption key (that's the only use that Vista puts the TPM to, as far as I'm aware) The TCG is not oblivious to the bad press it has received from certain in the community. Design decisions are made around principles that seem fine to me. For example, from: https://www.trustedcomputinggroup.org/specs/bestpractices/Best_Practices _Principles_Document_V2_0.pdf "Each owner should have effective choice and control over the use and operation of the TCG-enabled capabilities that belong to them; their participation must be opt-in. Subsequently any user can reliably disable the TCG functionality in a way that does not violate the owner's policy." Note the dichotomy between user and owner - I'm using my company's laptop right now, and it's their right to lock it down. But if I were using my desktop, that decision would be mine to make. > Based on your comments, I'm guessing that the TPMs themselves have default > hardware keys as well as being able to generate keys and those default > keys can in fact be authenticated rather than just being able to > generated? What's to stop someone opening up the hardware to find out what > that is? Obviously that's outside the realms of your average developer, > but it's not outside the capabilities of a commercial company. That's right (as explained above). I've mentioned before that security isn't binary, and you only spend as m
RE: [backstage] DRM and hwardware attitudes
On 10/02/07, Nic James Ferrier wrote: > You work in the industry and you've only met one person who uses > it. So why are firms still putting it in their products? Surely a > motherboard would be cheaper without it? Of course it's cheaper not to install a TPM, but it's chicken and egg - to take advantage of its facilities, an enterprise needs a large proportion of its PCs to be enabled. > > No - your PC /is/ wholly yours. There's a feature that allows you to > > invite me to put stuff on I can't tamper with. But I can't randomly take > > control of your computer. > > I never said you could. But you are being disenguous. There is a > feature that allows me to let you put stuff on my computer that I > can't tamper with, let alone you. No, I'm really not being disingenuous. We both agree the feature is under your control. If you don't want to use it, you don't have to. Your PC is wholly yours. > > A whole bunch of people don't like this because RMS and Ross Anderson > > told them it was bad, but have no understanding of what the technology > > actually is. I'm sure you do understand it, but let's have the debate so > > that those who only hear the hype can make an informed decision. > > This seems to be the "people are stupid" argument. I don't believe > that. I understand this technology and I believe it threatens my > freedom. I'm fairly sure that everyone I have heard describing their > fears about such a module also understood it. How is this, "people are stupid"? What I said was that some people are not informed. (Hey, we're back on topic - Educating, Informing & Entertaining, all in one thread!) Look at Vijay's assertion regarding his encrypted partition, and how that obviated the need for a trusted element - when the protection of encrypted partitions is one of the primary use cases for TPMs. I've just reread one of RMS' musings on treacherous computing, and some of what he describes is terrible. But that's not what is on offer! >From RMS at http://www.gnu.org/philosophy/can-you-trust.html: "In the past, these were isolated incidents. "Trusted computing" would make it pervasive. "Treacherous computing" is a more appropriate name, because the plan is designed to make sure your computer will systematically disobey you. In fact, it is designed to stop your computer from functioning as a general-purpose computer. Every operation may require explicit permission." Which is absolute balderdash. If it was designed to "stop your computer from functioning as a general-purpose computer" why can I turn it off? > > }:p > > Have you got funny hair or something? No, I had my hands to my head and was waving my fingers. :) Nya. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] DRM and hwardware attitudes
On 11/02/07, Michael Sparks wrote: > On Saturday 10 February 2007 22:28, Tim Thornton wrote: > > > Your machine will do what you tell it to. It's just that there are > > secrets you can't access. > > Regarding the point above, that's the issue here. Whilst you're happy with > owning a computer that will keep secrets from you, I'm not. > > That's a minor detail though - kinda you say potato I saw potato - we're > unlikely to agree. Much like attitudes to IP ownership, I suspect! :) > (We both agree they keep their secrets from the user, > from your perspective I still retain control, from mine I don't.) Unfortunately, for it to provide security to the level that it does, those private keys must be unavailable outside the TPM. I do understand where you're coming from, but you can think of it like any hardware resource; it has certain properties. I can write to a CD-R, but I can't erase that data (in software) once written. Or at a slightly different level, my file system prevents me from modifying files I don't have permission to access. > Thanks for the references and explanation - I'll read up on the references, > you never know when the positive uses of the technology will be handy. A genuine pleasure to have helped. Cheers, Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] Flash required?
On 05/03/07, Andy <[EMAIL PROTECTED]> wrote: > On 05/03/07, George Wright <[EMAIL PROTECTED]> wrote: > > 5) It runs on more archs than you can shake a stick at > > I know where there is an Arm board, do I need to shake a stick at it? > Does Real Player run on Arm? There's always someone who has an obscure > piece of kit. Yup. :) -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] [Fwd: Fwd: Twitter Fever]
At 17:41 +0100 18/4/07, Gordon Joly wrote: > At 15:48 +0100 18/4/07, Ian Forrester wrote: > > > >- > > > >There's huge value in Frameworks. No matter what you may think about > >Rails, you can't call them all bad. :) > > > >Ian > > A framework is a higher level of abstraction. Most of the time, there > come a point where you want to poke around under the bonnet and fine > tune the engine Occasionally. But mostly, abstraction is what good engineering is all about. What more is an operating system than a higher level of abstraction from handling memory management and scheduling in your own code? What more is a CPU architecture than an abstraction from a set of transistors? Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
