Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73

From: "[email-masked]" <[email-masked]>
Date: Sat, 21 Feb 2009 17:45:44 GMT

>ann. i've yet to see this mandated in any protocol suggested here or  
by the AWG. please do not mis-represent the work going on here. this  
is a forum for the discussion and development of technical standards.

No, this is Prokofy Neva speaking, not ann, you've mixed up the posters, although clearly marked.

>again. there are no protocols being considered by this group that  
would REQUIRE the abandonment of the transport of permissions metadata.

Infinity, I never can understand why this statement is always put in the negative when these discussions come up, "there are no protocols being considered that would REQUIRE the abandonment. etc.". Is there a reason why you can't put this in the positive, "We will make sure that the protocols INCLUDE the transport of permissions metadata". Because otherwise, it appears that you are saying essentially this, as you've implied on the LL blog: "We aren't going to deliberately take out permissions" -- but then implicitly, "But we won't work to uphold them with a technical solution, either." This seems like an important distinction, and putting the operation in the positive is important to create a real situation of real free choice, otherwise, not working to include the metadata means that suddenly, you can later say "Oh, well, other people didn't want it so we had to go along with it but it's not our fault". 

>this is not a forum for you to complain about the permissions system  
currently deployed on the second life main grid or linden lab's  
policies regarding digital asset creator's intellectual property  
rights. there _are_ other forums where this is appropriate and i  
encourage you to participate in them.

I'm not complaining about the current permissions system, I'm celebrating it as a good thing and urging that it be used as the standard. It's not about privileging one company over another, as I think the c/m/t regime is a pretty workable and remarkably successful regime that works far better than other solutions that companies have come up with (no UGC allowed, all UGC cleared through a central committee, corporate firewalls on private grids, etc.)

Sure, there are other forums to discuss these things, where you can push concerned people out of sight and out of mind, but if you are going to go about interoperability by refusing to uphold c/m/t at the outset as a positive project, and only taking a passive stance that you won't actively strip it out (but you will not work to uphold it), then it very much becomes *all about* interoperability. Unlike the corporate DRM's that people complain about so much that don't have flexibility for individual users, the "DRM" of c/m/t SL-style is controlled individually by each individual creator, and that's the reason for its success.

I don't think I will need to speak on this subject again, as I think it's fairly well established now that a) Linden Lab will not work to uphold the permissions regime of c/m/t outside its grid, but will enthusiastically hook up to other grids that do not uphold this regime merely for the sake of interoperability, that the inclusion of c/m/t will *not* be on the menu of "trustworthyness"; b) other companies with different IP protection solutions like central clearance or no UGC at all will also not work to uphold a permissions regime of c/m/t. 

Now that we've established those two things, the public then understands the vast implications of interoperability serving corporate rather than public interests. All you need to do is be clear about this, and then the conversation is over. Then the consumer votes with their feet, as needed.

____________________________________________________________
Click to learn about options trading and get the latest information.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIzQb3SJVlegeN9XYLKXO6KzAzRPRmJgtPHGiGx5KlBfH4Slo7bxu/

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 11:13:41 -0800

[email-masked] wrote:
> the menu of "trustworthyness"; b) other companies with different IP protection solutions like central clearance or no UGC at all will also not work to uphold a permissions regime of c/m/t. 
>
> Now that we've established those two things, the public then understands the vast 

You have established nothing of the sort.

I just discussed this with some people I know at There.com, and they 
would be favorable to upholding technical permissions, /in additional 
to/ their central clearing system that often catches these problems 
already. View it as belt AND suspenders.

I've seen you trying to put words in the mouth of others several times 
on this list, and I think it's unbecoming.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 23:46:37 -0800

On Feb 21, 2009, at 9:45 AM, [email-masked] wrote:
> Infinity, I never can understand why this statement is always put in  
> the negative when these discussions come up, "there are no protocols  
> being considered that would REQUIRE the abandonment. etc.". Is there  
> a reason why you can't put this in the positive, "We will make sure  
> that the protocols INCLUDE the transport of permissions metadata".  
> Because otherwise, it appears that you are saying essentially this,  
> as you've implied on the LL blog: "We aren't going to deliberately  
> take out permissions" -- but then implicitly, "But we won't work to  
> uphold them with a technical solution, either." This seems like an  
> important distinction, and putting the operation in the positive is  
> important to create a real situation of real free choice, otherwise,  
> not working to include the metadata means that suddenly, you can  
> later say "Oh, well, other people didn't want it so we had to go  
> along with it but it's not our fault".

I word my statements to provide the meaning in intend. when i say  
"there are no protocols being considered by this group that would  
REQUIRE the abandonment of the transport of permissions metadata," i  
say it because there are, in fact, no protocols being considered by  
this group that would REQUIRE the abandonment of the transport of  
permissions metadata. What LL blog post are you talking about? Perhaps  
you have me confused with someone else (enh. it's an easy mistake.)  
But yes, we won't be working on a protocol that mandates them UNLESS  
there is unanimous consent that all implementers want to transport  
permissions metadata via OGP (or whatever we wind up calling it) and  
there is unanimous consent that the second life model for permissions  
metadata is appropriate for all implementors.

Let me give you an analogy.

There is a standard called TLS which is widely used to provide message  
confidentiality and origin integrity for messages flowing across the  
internet. Some options in TLS are considerably less secure than  
others. Specifically... the TLS_RSA_WITH_NULL_MD5 ciphersuite does not  
even encrypt messages flying across the wire. Think about this... TLS  
is _the_ standard used to protect your credit card numbers and it's  
perfectly legitimate within the context of a TLS protected message  
stream to NOT USE ANY ENCRYPTION WHATSOEVER!!!!!!

So why haven't we heard of wide-scale credit card fraud stemming from  
bad guys stealing credit card numbers off the wire using the  
TLS_RSA_WITH_NULL_MD5 ciphersuite? Because banks and online merchants  
all know not to use that option. In short... just because a standard  
says you can shoot yourself in the foot... honestly... you don't have  
to. When you have a protocol where not all options make sense for all  
participants, you generally see people develop policies with names  
like "interoperability profiles" or "interop policy." These policies  
detail which options are allowed and which are forbidden, and under  
what conditions.

So why make broken protocols?

TLS_RSA_WITH_NULL_MD5 is not evidence of brokenness, it is evidence of  
flexibility. There are many situations where encryption is not needed  
but origin integrity is. In some of these situations, the use of  
encryption is actually counter-productive. If you want to use TLS for  
encryption, you use the ciphersuites that specify a bulk encryption  
cipher. If you want to use TLS only for origin integrity, you MAY use  
a ciphersuite with a NULL cipher. Like all tools, there is an  
assumption that the user will have some understanding of it's use.

And so it is with permissions meta-data. It is highly likely we will  
produce one or more protocols that do not even mention it. LLSD for  
instance makes no mention of permissions meta-data, but this does not  
mean that permissions don't work on the second life grid. (to be sure,  
there are occasional bugs, but the bugs don't emerge because the LLSD  
specification failed to define permissions meta-data.) and this is why  
it is not a failure to define a protocol without permissions meta- 
data. just because one protocol doesn't define it doesn't mean another  
one won't. and just because a suite of protocols doesn't define it,  
doesn't mean it won't be used in some implementations of the protocol.

>> this is not a forum for you to complain about the permissions  
>> system currently deployed on the second life main grid or linden  
>> lab's policies regarding digital asset creator's intellectual  
>> property rights. there _are_ other forums where this is appropriate  
>> and i encourage you to participate in them.
>
> I'm not complaining about the current permissions system, I'm  
> celebrating it as a good thing and urging that it be used as the  
> standard. It's not about privileging one company over another, as I  
> think the c/m/t regime is a pretty workable and remarkably  
> successful regime that works far better than other solutions that  
> companies have come up with (no UGC allowed, all UGC cleared through  
> a central committee, corporate firewalls on private grids, etc.)

so.. you want world of warcraft, penguin cafe, qwaq, there.com, sony  
home, eve online, osgrid, etc. to all use the second life permissions  
system instead of the one they made for their user base because you  
may one day want to use those worlds?

good luck.

> Sure, there are other forums to discuss these things, where you can  
> push concerned people out of sight and out of mind, but if you are  
> going to go about interoperability by refusing to uphold c/m/t at  
> the outset as a positive project, and only taking a passive stance  
> that you won't actively strip it out (but you will not work to  
> uphold it), then it very much becomes *all about* interoperability.  
> Unlike the corporate DRM's that people complain about so much that  
> don't have flexibility for individual users, the "DRM" of c/m/t SL- 
> style is controlled individually by each individual creator, and  
> that's the reason for its success.

again. this is not the forum for this discussion. this is a forum for  
people who are implementing virtual worlds software. and honestly,  
your participation here is puzzling to me as you have publicly equated  
the IETF with a BDSM cult.

> I don't think I will need to speak on this subject again, as I think  
> it's fairly well established now that a) Linden Lab will not work to  
> uphold the permissions regime of c/m/t outside its grid, but will  
> enthusiastically hook up to other grids that do not uphold this  
> regime merely for the sake of interoperability, that the inclusion  
> of c/m/t will *not* be on the menu of "trustworthyness"; b) other  
> companies with different IP protection solutions like central  
> clearance or no UGC at all will also not work to uphold a  
> permissions regime of c/m/t.

huh? where do you get this? but again... this is not a forum managed  
by Linden Lab and it is not a forum devoted to Linden Lab's policies.  
if you have a problem with Linden's policies, please use the  
appropriate channel. IETF != Linden Lab.

> Now that we've established those two things, the public then  
> understands the vast implications of interoperability serving  
> corporate rather than public interests. All you need to do is be  
> clear about this, and then the conversation is over. Then the  
> consumer votes with their feet, as needed.