Subject: Re: [vwrap] [wvrap] Simulation consistency

From: "[email-masked]" <[email-masked]>
Date: Sat, 2 Apr 2011 14:12:59 GMT

Vaughn, A key reason the Metaverse construction  cannot be left to coders and other technologists like yourself alone is  this kind of coervice hypothesis, crowbarring a metaphor in service of a  pre-existing agenda. First of all, I don't make  content of any significant amount as an amateur, such as to be concerned  only about "my dresses" and "little dressmaker genocide" as copyleftist  cynics call it. But I express this concern on behalf of my rentals  customers who do make content and who are worried -- and rightly so --  about theft, and most of all, I express this as a *matter of principle*. Second,  the notion that girls travelling to a party at "Vaugh's Immersive  Fabulousness" from "Prokofy's Palm Cafe At the End of the Mind" need not  fear nakedness of Vaughn simply bestirs himself, *in good faith*  (always in short supply with metaversal engineers), to automatically  supply a generic dress or Ruth appearance and outfit in the event that  the server can't fetch the assets for any reason. So that's specious  entirely. Third, if you think customers and their wants  and inciting their hatred of platform providers who can't render their  dresses in all their pretty glory are the way to hijack the metaverse  for the copyleftist/open source cult agenda, think again. Dress shoppers  can become fiercely loyal patrons of the copyright of their favourite  designers. Fiercely.And they will mount the consumer boycott and press  campaign to match their ferocity. Fourth, If you have a  world in which copying the dresses off avatars is a function of the  browser you let connect to your world, like the copybotting Thugs Lyfe,  merely with a mouseclick or two, then you deserve to be ostracized. And  in fact, you and all providers can have a policy about not letting such  TPV viewers connect, as LL does -- and without any pretense that it can  control every manifestation. BTW, the Red Zone statistics of 9 million  scans with only 78,000 rogue viewers captured lets us know that this  problem is exaggerated -- and usually by engineers who claim there is no  technical solution. Fifth, and most relevant, the  metaverse does not have to be built entirely on automatic machines that  only perform rote routines, which are, indeed, only the mechanistic  concretization of human will and "nothing special". It  can be also constructed of polices and agreements rooted in organic  minds and organic institutions. And that's ok. And that would mean a  basic charter, that could be as historical and epic as the Magna Charter  or as mundane as the Bottle Bill of Rights hanging on the wall of your  supermarket. And that charter would spell out that platforms that do not  respect copyright *by including the engineered DRM on creations* and  *by including a TPV policy* do not get the handshake, do not get the  hookup. And that's it. It's not so hard, truly. These  treaties can be forged at real-life in-person conventions, just like  other technical agreements are, including IEEE standards, and they can  be forged ultimately in a "scaling" fashion by having templates that a  server seeking to make a connection with have or not have, not  withstanding Morgaine's wild and hysterical notions that "nothing" can  be trusted on the Internet and trust regimes are all a scam. It's  not about Prokofy relinquishing control for the sake of his customers'  eye candy. It's about two platforms shaking hands on an established  pre-existing agreement that becomes the metaversal standard -- and a  standard created not by a cabal of a few engineers in an obscure IEEF  working group, but open conventions. And please don't  pretend this can't scale. There's about 17 and a half virtual worlds out  there at most that really have any viability and people on them with  stuff that works for the user. So they can make a confederation of  standards that does respect the *technical implementation* of copyright  and intellectual property rights *simply because they can*. It's a  matter of political will, and its absence now is one of blatant  collectivist ideology at work. If you yourself opt to  break your fabulous immersive world by not putting default dresses on  people in decency, and more to the point, not abiding by a simple  protocol to include DRM as a default with the "export to other grids"  box and c/m/t boxes checked, and "TPV policy compliant" then you're the  problem, not Prokofy's fear of crypto communists hiding under the  servers. You seem to be like all followers of the  California Business Model (let all uploads first, sell ads, then DMCA  takedowns later) -- and you seem to be willing to wait for your  customers complain. That's not necessary if you're an  ethical provider -- you can make the agreements first. Forcing the issue  by deploying the age-old "analog hole" argument and whining that you  "must" serve up the view of an asset your customers "expect" to see or  already "can" see doesn't let you off the hook. There is no reason to be  literalist about it. You can weld c/m/t into operability from the  get-go. You can refuse to allow viewers that copybot. Your resistance to  this is purely ideological. And BTW, if you persist in  calling people who rightfully and legitimately raise copyright concerns  and rightly and legitimately point out the copyleftist ideological bias  as "paranoid" and "conspiracy theorists" and "fearful of  cryptocommunists" and "McCarthyites" than you're going to go on being  called the Leninists that you in fact are. Prokofy  
____________________________________________________________
Groupon&#8482 Official Site
1 ridiculously huge coupon a day. Get 50-90% off your city&#39;s best!
http://thirdpartyoffers.juno.com/TGL3141/4d972f1545e6f4f6811st04vuc

---

From: "Patnad Babii" <[email-masked]>
Date: Sat, 2 Apr 2011 11:03:17 -0400

Let me put it simple, Linden Lab is not forced to use this protocol at ALL and I'm pretty sure as they are a pretty big company with brains, they are not going to allow something that’s going to reduce security or allow more thief to their grid anytime soon.

This protocol is intended mostly for other Open virtual worlds.  If at a point Linden Labs find it an interest in the protocol they might implement it. Linden Labs is not working anymore on grid interop for some time now, so please stop being afraid by the big bad wolf, cause it is not here you are going to find it. 

From: [email-masked] 
Sent: Saturday, April 02, 2011 10:12 AM
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: [vwrap] [wvrap] Simulation consistency

Vaughn,

A key reason the Metaverse construction cannot be left to coders and other technologists like yourself alone is this kind of coervice hypothesis, crowbarring a metaphor in service of a pre-existing agenda.

First of all, I don't make content of any significant amount as an amateur, such as to be concerned only about "my dresses" and "little dressmaker genocide" as copyleftist cynics call it. But I express this concern on behalf of my rentals customers who do make content and who are worried -- and rightly so -- about theft, and most of all, I express this as a *matter of principle*.

Second, the notion that girls travelling to a party at "Vaugh's Immersive Fabulousness" from "Prokofy's Palm Cafe At the End of the Mind" need not fear nakedness of Vaughn simply bestirs himself, *in good faith* (always in short supply with metaversal engineers), to automatically supply a generic dress or Ruth appearance and outfit in the event that the server can't fetch the assets for any reason. So that's specious entirely.

Third, if you think customers and their wants and inciting their hatred of platform providers who can't render their dresses in all their pretty glory are the way to hijack the metaverse for the copyleftist/open source cult agenda, think again. Dress shoppers can become fiercely loyal patrons of the copyright of their favourite designers. Fiercely.And they will mount the consumer boycott and press campaign to match their ferocity.

Fourth, If you have a world in which copying the dresses off avatars is a function of the browser you let connect to your world, like the copybotting Thugs Lyfe, merely with a mouseclick or two, then you deserve to be ostracized. And in fact, you and all providers can have a policy about not letting such TPV viewers connect, as LL does -- and without any pretense that it can control every manifestation. BTW, the Red Zone statistics of 9 million scans with only 78,000 rogue viewers captured lets us know that this problem is exaggerated -- and usually by engineers who claim there is no technical solution.

Fifth, and most relevant, the metaverse does not have to be built entirely on automatic machines that only perform rote routines, which are, indeed, only the mechanistic concretization of human will and "nothing special".

It can be also constructed of polices and agreements rooted in organic minds and organic institutions. And that's ok. And that would mean a basic charter, that could be as historical and epic as the Magna Charter or as mundane as the Bottle Bill of Rights hanging on the wall of your supermarket. And that charter would spell out that platforms that do not respect copyright *by including the engineered DRM on creations* and *by including a TPV policy* do not get the handshake, do not get the hookup. And that's it. It's not so hard, truly.

These treaties can be forged at real-life in-person conventions, just like other technical agreements are, including IEEE standards, and they can be forged ultimately in a "scaling" fashion by having templates that a server seeking to make a connection with have or not have, not withstanding Morgaine's wild and hysterical notions that "nothing" can be trusted on the Internet and trust regimes are all a scam.

It's not about Prokofy relinquishing control for the sake of his customers' eye candy. It's about two platforms shaking hands on an established pre-existing agreement that becomes the metaversal standard -- and a standard created not by a cabal of a few engineers in an obscure IEEF working group, but open conventions.

And please don't pretend this can't scale. There's about 17 and a half virtual worlds out there at most that really have any viability and people on them with stuff that works for the user. So they can make a confederation of standards that does respect the *technical implementation* of copyright and intellectual property rights *simply because they can*. It's a matter of political will, and its absence now is one of blatant collectivist ideology at work.

If you yourself opt to break your fabulous immersive world by not putting default dresses on people in decency, and more to the point, not abiding by a simple protocol to include DRM as a default with the "export to other grids" box and c/m/t boxes checked, and "TPV policy compliant" then you're the problem, not Prokofy's fear of crypto communists hiding under the servers.

You seem to be like all followers of the California Business Model (let all uploads first, sell ads, then DMCA takedowns later) -- and you seem to be willing to wait for your customers complain.

That's not necessary if you're an ethical provider -- you can make the agreements first. Forcing the issue by deploying the age-old "analog hole" argument and whining that you "must" serve up the view of an asset your customers "expect" to see or already "can" see doesn't let you off the hook. There is no reason to be literalist about it. You can weld c/m/t into operability from the get-go. You can refuse to allow viewers that copybot. Your resistance to this is purely ideological.

And BTW, if you persist in calling people who rightfully and legitimately raise copyright concerns and rightly and legitimately point out the copyleftist ideological bias as "paranoid" and "conspiracy theorists" and "fearful of cryptocommunists" and "McCarthyites" than you're going to go on being called the Leninists that you in fact are.

Prokofy

____________________________________________________________
Groupon™ Official Site
1 ridiculously huge coupon a day. Get 50-90% off your city's best!
Groupon.com 

--------------------------------------------------------------------------------
_______________________________________________
vwrap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vwrap

---

From: Carlo Wood <[email-masked]>
Date: Sat, 2 Apr 2011 17:19:23 +0200

On Sat, 2 Apr 2011 14:12:59 GMT
"[email-masked]" <[email-masked]> wrote:

> BTW, the Red Zone statistics of 9 million  scans with only 78,000
> rogue viewers captured lets us know that this  problem is exaggerated
> -- and usually by engineers who claim there is no  technical solution.

Just for the record, from a hacker/engineer: there is no technical
solution. It is possible to copy everything (and without being detected
by a "Red Zone" which can only detect rogue viewers that were released
to the public and explicitly make a point of being detectable
in the first place (call that bragging: no fun in releasing a "k3wl"
viewer if others (or even the coder himself) can't see that it is being
used.) So, there is a psychological advantage for the detectors, but
not really a technical one.

Lets concentrate on textures for the moment to explain this.

In order to see an object, or clothing, with the appropriate textures,
those textures have to be downloadable for the viewer. There is nothing
you can do about that short of running the whole viewer server-side
and providing a video. But even in that case it would technically be
possible to rip the textures: they are still visible (ie, you could
make a screenshot of the surface of a wall). I don't consider the
video-broadcast to even be remotely interesting, certainly not from the
viewpoint of VWRAP so lets forget that for the moment and just accept
that it is possible for anyone to store whatever they SEE to their harddisk.

Secondly, if the first creator could upload this texture then so can
the ripper. And don't tell me software exists that can detect if
an uploaded texture "looks like" one of the already existing billion
textures that were uploaded before. If the texture is converted twice,
ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a
human to look at the original and the newly uploaded texture at the
same time to judge that it is MAYBE a copy - which then can only be
proved in court if the original creator can prove that his original
textures are 100% his own and not, for example, downloaded from the
internet somewhere (because in that case the other uploader could
have used the same source).

A real problem, currently in SL, is imho the complete lack of
support for FREE things. The amount of restriction (for people with
honest viewers) is tremendous: if you're not an expert or do not pay
attention for a second, then your creation is not truely free anymore.
Everything defaults to very copyleft unfriendly settings. I'm trying to
get my friends, who are very willing in that regard, to only create
full permission stuff, but it's simply near impossible to keep
something full permission and often we're stuck with something nobody
else can change or edit because the creator forgot to set the bit of
the contents of an object after changing the group etc blah blah...

For example, last a good friend of me wanted my help with making a
large amount of changes on his sim: hunderds of objects had to be
adjusted... He was willing to:
1) Add me to any group necessary.
2) Give me his build rights
3) Transfer any object to me (temporary ownership transfer)
4) Make any adjustments to the objects and the objects contents
   needed to allow me to access what I needed to access.
etc etc

The end result: He had to do it all by himself. It was impossible to
give me enough access to help him (for those who don't believe that,
one of things involved changing the "anyone can move" bit of an
object in the contents of objects: it is not possible to take anything
out of the contents (ie copy it to your inventory) when it's no
transfer, and therefore you can't edit it, even though it's modify
and you get all the rights that the owner can give you).

Sorry, but that is unacceptable; and it CLEARLY shows that something is
missing from the protocol.

Now the above example doesn't show that a free object is not supported,
it only make clear that non-free objects can be very annoying even in
situations where the owner has all the rights to do what he wants to
do. There are many other such examples. Hence, it shows that it is very
annoying that an object is non-free by default at so many levels that
you need an IQ of over 140 to create one and those permissions erode
quickly to non-free. Even the so called "freebies" are non-free by the
way: they are almost always no transfer. Hell, even the default shape
that you can when you create a new account is no transfer, what kind of
insanity is that?!

I think you might find a lot of people, like myself, a lot more willing
to help out with thinking of ways on how to protect property in virtual
worlds when first it is assured that those who want to create things
that are FREE are equally supported as the commercial guys out there.

-- 
Carlo Wood <[email-masked]>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 2 Apr 2011 09:52:34 -0700

the likelihood that linden will use any output from this group at this
point is about nil.

if they were, they would likely actually pay someone to participate.

but... i don't speak for linden anymore, so take that last statement
with a grain of salt.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Sat, Apr 2, 2011 at 8:03 AM, Patnad Babii <[email-masked]> wrote:
> Let me put it simple, Linden Lab is not forced to use this protocol at ALL
> and I'm pretty sure as they are a pretty big company with brains, they are
> not going to allow something that’s going to reduce security or allow more
> thief to their grid anytime soon.
>
> This protocol is intended mostly for other Open virtual worlds.  If at a
> point Linden Labs find it an interest in the protocol they might implement
> it. Linden Labs is not working anymore on grid interop for some time now, so
> please stop being afraid by the big bad wolf, cause it is not here you are
> going to find it.
>
>
> A key reason the Metaverse construction cannot be left to coders and other
> technologists like yourself alone is this kind of coervice hypothesis,
> crowbarring a metaphor in service of a pre-existing agenda.
>
> First of all, I don't make content of any significant amount as an amateur,
> such as to be concerned only about "my dresses" and "little dressmaker
> genocide" as copyleftist cynics call it. But I express this concern on
> behalf of my rentals customers who do make content and who are worried --
> and rightly so -- about theft, and most of all, I express this as a *matter
> of principle*.
>
> Second, the notion that girls travelling to a party at "Vaugh's Immersive
> Fabulousness" from "Prokofy's Palm Cafe At the End of the Mind" need not
> fear nakedness of Vaughn simply bestirs himself, *in good faith* (always in
> short supply with metaversal engineers), to automatically supply a generic
> dress or Ruth appearance and outfit in the event that the server can't fetch
> the assets for any reason. So that's specious entirely.
>
> Third, if you think customers and their wants and inciting their hatred of
> platform providers who can't render their dresses in all their pretty glory
> are the way to hijack the metaverse for the copyleftist/open source cult
> agenda, think again. Dress shoppers can become fiercely loyal patrons of the
> copyright of their favourite designers. Fiercely.And they will mount the
> consumer boycott and press campaign to match their ferocity.
>
> Fourth, If you have a world in which copying the dresses off avatars is a
> function of the browser you let connect to your world, like the copybotting
> Thugs Lyfe, merely with a mouseclick or two, then you deserve to be
> ostracized. And in fact, you and all providers can have a policy about not
> letting such TPV viewers connect, as LL does -- and without any pretense
> that it can control every manifestation. BTW, the Red Zone statistics of 9
> million scans with only 78,000 rogue viewers captured lets us know that this
> problem is exaggerated -- and usually by engineers who claim there is no
> technical solution.
>
> Fifth, and most relevant, the metaverse does not have to be built entirely
> on automatic machines that only perform rote routines, which are, indeed,
> only the mechanistic concretization of human will and "nothing special".
>
> It can be also constructed of polices and agreements rooted in organic minds
> and organic institutions. And that's ok. And that would mean a basic
> charter, that could be as historical and epic as the Magna Charter or as
> mundane as the Bottle Bill of Rights hanging on the wall of your
> supermarket. And that charter would spell out that platforms that do not
> respect copyright *by including the engineered DRM on creations* and *by
> including a TPV policy* do not get the handshake, do not get the hookup. And
> that's it. It's not so hard, truly.
>
> These treaties can be forged at real-life in-person conventions, just like
> other technical agreements are, including IEEE standards, and they can be
> forged ultimately in a "scaling" fashion by having templates that a server
> seeking to make a connection with have or not have, not withstanding
> Morgaine's wild and hysterical notions that "nothing" can be trusted on the
> Internet and trust regimes are all a scam.
>
> It's not about Prokofy relinquishing control for the sake of his customers'
> eye candy. It's about two platforms shaking hands on an established
> pre-existing agreement that becomes the metaversal standard -- and a
> standard created not by a cabal of a few engineers in an obscure IEEF
> working group, but open conventions.
>
> And please don't pretend this can't scale. There's about 17 and a half
> virtual worlds out there at most that really have any viability and people
> on them with stuff that works for the user. So they can make a confederation
> of standards that does respect the *technical implementation* of copyright
> and intellectual property rights *simply because they can*. It's a matter of
> political will, and its absence now is one of blatant collectivist ideology
> at work.
>
> If you yourself opt to break your fabulous immersive world by not putting
> default dresses on people in decency, and more to the point, not abiding by
> a simple protocol to include DRM as a default with the "export to other
> grids" box and c/m/t boxes checked, and "TPV policy compliant" then you're
> the problem, not Prokofy's fear of crypto communists hiding under the
> servers.
>
> You seem to be like all followers of the California Business Model (let all
> uploads first, sell ads, then DMCA takedowns later) -- and you seem to be
> willing to wait for your customers complain.
>
> That's not necessary if you're an ethical provider -- you can make the
> agreements first. Forcing the issue by deploying the age-old "analog hole"
> argument and whining that you "must" serve up the view of an asset your
> customers "expect" to see or already "can" see doesn't let you off the hook.
> There is no reason to be literalist about it. You can weld c/m/t into
> operability from the get-go. You can refuse to allow viewers that copybot.
> Your resistance to this is purely ideological.
>
> And BTW, if you persist in calling people who rightfully and legitimately
> raise copyright concerns and rightly and legitimately point out the
> copyleftist ideological bias as "paranoid" and "conspiracy theorists" and
> "fearful of cryptocommunists" and "McCarthyites" than you're going to go on
> being called the Leninists that you in fact are.
>
> Prokofy
>
>
>
> ________________________________

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 2 Apr 2011 10:01:43 -0700

yes. there is something missing in the protocol. it's trust. you don't
put "trust" in a protocol, you put "security" in a protocol. at the
end of the day, the people using this protocol will need to decide
whom they trust. this is why there was a security model and the
ability of the protocol to "securely carry trust."

the idea is that the protocol would carry cryptographically
unforgeable attestations of an endpoint's identity. this identity
would then be evaluated by protocol participants to see if it is
"trusted."

there's no place in the protocol that says "you must trust a specific
entity," but rather a mechanism deployers can use to carry the
identity of people wishing to be trusted.

at the end of the day, an asset service should only barf up assets to
trusted simulation services. simulators SHOULD only allow people on
the grid they trust (for some definition of the word "trust.")

if you're a company like Linden that needs to respond to DMCA takedown
requests, you're likely to require the client trust knob turned up a
bit. if you're an enterprise, you're going to want that trust knob
turned all the way up. if you're the pirate bay, you're going to
intentionally want that trust knob turned all the way down.

as protocol developers, it's our duty to create a protocol that meets
everyone's use cases. so... i mean... feel free to try to define a
protocol that mandates the use of DRM or blesses a particular trust
point, but the likelihood of it being widely supported is..
approximately nil.

my recommendation has always been... "define mechanism, not policy."

-cheers
-meadhbh

---

From: Carlo Wood <[email-masked]>
Date: Sat, 2 Apr 2011 19:48:53 +0200

On Sat, 2 Apr 2011 10:01:43 -0700
Meadhbh Hamrick <[email-masked]> wrote:

This is not exactly what I was refering too :p
What I meant is that it should be possible to tag
a creation as "GPL-ed" or "Common Creations" etc,
and that the result is that that thing stays that
way. That it is not possible to accidently break
such free licenses by making it 'no mod' because
someone forgot to check a box.

Although this seems to be a client-side issue,
and thus something internally to grid (and thus
not related to VWRAP), it DOES mean that such
information has to be supported at all levels:
the fact that something IS explicitely allowed
to be copied etc, has to be stored in asset
servers and be transported to others who obtain
a copy if it.

If everyone is willing to work as hard on guaranteeing
support for such free product as on the use case
for proprietary products, then I'm willing to think
hard of ways to support the latter.

> >> rogue viewers captured lets us know that this  problem is
> >> exaggerated -- and usually by engineers who claim there is no
> >>  technical solution.
> >
> > solution. It is possible to copy everything (and without being
> > detected by a "Red Zone" which can only detect rogue viewers that
> > were released to the public and explicitly make a point of being
> > detectable in the first place (call that bragging: no fun in
> > releasing a "k3wl" viewer if others (or even the coder himself)
> > can't see that it is being used.) So, there is a psychological
> > advantage for the detectors, but not really a technical one.
> >
> > In order to see an object, or clothing, with the appropriate
> > textures, those textures have to be downloadable for the viewer.
> > There is nothing you can do about that short of running the whole
> > viewer server-side and providing a video. But even in that case it
> > would technically be possible to rip the textures: they are still
> > visible (ie, you could make a screenshot of the surface of a wall).
> > I don't consider the video-broadcast to even be remotely
> > interesting, certainly not from the viewpoint of VWRAP so lets
> > forget that for the moment and just accept that it is possible for
> > anyone to store whatever they SEE to their harddisk.
> >
> > textures that were uploaded before. If the texture is converted
> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd
> > need a human to look at the original and the newly uploaded texture
> > at the same time to judge that it is MAYBE a copy - which then can
> > only be proved in court if the original creator can prove that his
> > original textures are 100% his own and not, for example, downloaded
> > from the internet somewhere (because in that case the other
> > uploader could have used the same source).
> >
> > attention for a second, then your creation is not truely free
> > anymore. Everything defaults to very copyleft unfriendly settings.
> > I'm trying to get my friends, who are very willing in that regard,
> > to only create full permission stuff, but it's simply near
> > impossible to keep something full permission and often we're stuck
> > with something nobody else can change or edit because the creator
> > forgot to set the bit of the contents of an object after changing
> > the group etc blah blah...
> >
> > object in the contents of objects: it is not possible to take
> > anything out of the contents (ie copy it to your inventory) when
> > it's no transfer, and therefore you can't edit it, even though it's
> > modify and you get all the rights that the owner can give you).
> >
> > Sorry, but that is unacceptable; and it CLEARLY shows that
> > something is missing from the protocol.
> >
> > Now the above example doesn't show that a free object is not
> > supported, it only make clear that non-free objects can be very
> > annoying even in situations where the owner has all the rights to
> > do what he wants to do. There are many other such examples. Hence,
> > it shows that it is very annoying that an object is non-free by
> > default at so many levels that you need an IQ of over 140 to create
> > one and those permissions erode quickly to non-free. Even the so
> > called "freebies" are non-free by the way: they are almost always
> > no transfer. Hell, even the default shape that you can when you
> > create a new account is no transfer, what kind of insanity is that?!
> >
> > I think you might find a lot of people, like myself, a lot more
> > willing to help out with thinking of ways on how to protect
> > property in virtual worlds when first it is assured that those who
> > want to create things that are FREE are equally supported as the
> > commercial guys out there.
> >
> > --

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 11:28:50 -0700

> ability of the protocol to "securely carry trust."

Well said! +1

> would then be evaluated by protocol participants to see if it is

Exactly!

Perhaps some assume content is always digital-deliverables for 
evaluation rather than only digital-context and the need to evaluate 
analog-content (separately). I know the issue is that I can write that 
easy and yet the overall task is complex, especially when one tries to 
wrap their head around the concept of analog-content evaluation over 
digital networks.

Maybe kinetics (as now popularized by Microsoft) can help people 
comprehend these steps without the need to know the bounds of math, 
omegas, within the limits, and beyond, as we can more easily assume with 
ray-tracer knowledge. I mention this because know such knowledge would 
help ease the hearts of those in concern of asset security, yet I don't 
always have easier ways to explain things as Meadhbh did above.

Imagine the only way to establish some sign-on is a specific diet and 
motion in front of the MS-Kinetic cam. That is analog data. If you think 
of single captures of the images then that is the digital renders of 
analog samples. The point is analog can only be sampled. The question of 
"trust" becomes how many samples does it take before some other 
participant acknowledges. (Or...,) How many milliseconds go by before 
you even recognize someone and trust your own cognition?

Something to keep in mind while this list assumed digital-security (and 
exploitation) was the only argument possible.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 02 Apr 2011 11:42:06 -0700

Not everything has to be copied. Wrap your mind around the ability for 
one simulator A to act as the client to another simulator B. In such 
case, the assets are not copied if they are only ray-traced. The 
ray-traced rendition can then allow user C to connect to sim A and see 
some appearance of assets froms sim B, yet not the exact copies.

Now, consider many asset servers to be the original analog-version of 
assets that are being simulated individually, and simulators will need 
to connect to these asset simulators in order to get some sampled view 
of the original. The sample view is the only allowable copy, and the 
original is never transfered. Detail of the sample view may vary. 
Consider some jewelry has some very unique, highly detailed, intricate 
work, the sampled version will never come close to the original, 
especially given limits on number of samples and resolution. One would 
have to trade the original manually in order to transfer it.

Convex/concave samples outside of ray-tracers are not always easy. It's 
doesn't always begin with a prim for these concepts.

Again, the idea is individual (and original) asset simulators instead of 
region simulator that (own and) simulate everything about requested assets.

Related concepts:

http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/HttpCastRayLLSD

http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html

--

---

From: Morgaine <[email-masked]>
Date: Sat, 2 Apr 2011 23:09:52 +0100

On Sat, Apr 2, 2011 at 6:01 PM, Meadhbh Hamrick <[email-masked]> wrote:

>
> if you're a *company* like Linden that needs to respond to DMCA takedown
> bit. if you're an *enterprise*, you're going to want that trust knob
> turned all the way up. if you're the *pirate bay*, you're going to
To avoid the possibility that new readers might get the wrong impression,
I'll point out that there aren't just two types of player in the virtual
worlds scene, honest enterprise people and evil pirates.  I wouldn't want
anyone new to think that such an impression was being conveyed or endorsed
by anyone here, and of course I'm positive it was not the intention in
Meadhbh's comment.

Education, research, Free/Open Source Software and Creative Commons
communities and a plethora of other groups deal either largely or
exclusively in free/libre content, sharing their work with each other
totally legally and honestly, and very frequently using content licenses
that permit unlimited distribution and require neither DRM nor any machinery
of trust when this content is conveyed.

Groups such as these make up what is sometimes called the "open community"
segment of Internet users, and it is a huge, vibrant, and very forward
looking community.

Many of us here share a mindset with that open community as users or
developers and consider ourselves part of it, and we are working towards VW
interop protocols that will allow our worlds to bloom and flourish as a
result of freely sharing open-licensed content and creating enormous synergy
by combining people's efforts without inappropriate barriers.

It is this open community which has important requirements that differ in
some ways from corporate ones, not some pirates, and I would strongly
encourage that the security aspects of VWRAP be addressed in this light,
before someone accuses us of fear-mongering.

As Carlo pointed out very well, the needs of the open community are not
being met *at all* by current VW services, and this is a major shortcoming
which we will need to remedy in VWRAP.  I am looking forward eagerly to that
aspect of our protocol design effort.

Morgaine.

=========================

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 3 Apr 2011 12:36:20 -0700

there is no way for a protocol to enforce the processing behavior on
either end of a connection unless you want to mandate the use of MAC
or DRM.

the reason you "trust" someone is that you can't complete a
transaction without trusting them. in the original VWRAP model, we
assumed assets were bits of data and meta-data that could be securely
moved around. "license" was just another bit of meta-data, as was
"distribution." the protocol didn't require you to add either of these
fields. neither did the protocol require you to honor them.

that's because there's no way a protocol can REQUIRE a consumer of
information do anything with that info.

instead, we provided a mechanism to communicate structured information
and described the processing expectations. but ultimately, if a "bad
actor" that wants to steal digital content participates in a protocol
transaction, it won't matter that the protocol will say "honor
permissions metadata." there is nothing magical about protocols that
require adherence to specified processing expectations.

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 21:46:09 +0100

Very good points made by Meadhbh, and I agree 100%.

It's an unfortunate reality that a puzzlingly large proportion of users have
a hard time grasping the total absence of content security in a platform
architecture which sends nearly all content types to client machines by
design.  It was designed that way for very good reasons, and those reasons
are as valid today as they were at the time that it was being designed, but
it can be hard to get across that this is how it is intended to be and not a
fault.  Some people's aspirations are destined to be forever unsatisfied
because this does not reflect their concept of digital reality.

It doesn't matter how much machinery of trust or security or encryption or
DRM or VPN or anything else we employ, at the end of the day the client
endpoint has open data at its disposal which it needs to get its job done,
and no technical barriers against doing with it whatever else it wishes.

It's incongruous that we speak of "trust domains" (it's those fluffy clouds
again) when all we really have are cryptographically assured endpoint
identification and no trust at all.  You can't trust someone whom you don't
know as a person, and it's a fiction to claim that trust has been obtained.
We would be more honest if we exchanged "Trust Placebo Tokens", and then we
could at least laugh at our own eclectic joke, while openly admitting that
we are not actually providing anything of value beyond knowledge of the
endpoint.

As you say, there is nothing we can actually do about this, because all we
can do is exchange messages containing structured information, and we can't
control people.  "Trust" about what happens beyond the endpoint is something
that our technology cannot convey, and really using terms that suggest
otherwise just deludes people who don't have the background to know better.

We should avoid doing that, even when a phrase sounds too sexy to give up.

Morgaine.

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 14:10:03 -0700

You mock fluffy clouds, yet you wrote "It was designed". To not write 
even close to formal English, when you made use of subject-less 
sentences, and complained about meanings and (glossary) usage, is 
incongruous.

Just state you don't like the word "domain". There is no need to mock me 
or anybody else to win points.

Morgaine wrote:
> It's an unfortunate reality that a puzzlingly large proportion of 
> users have a hard time grasping the total absence of content security 
> in a platform architecture which sends nearly all content types to 
> client machines by design.� It was designed that way for very good 
> reasons, and those reasons are as valid today as they were at the time 
> that it was being designed, but it can be hard to get across that this 
> is how it is intended to be and not a fault.� Some people's 
> aspirations are destined to be forever unsatisfied because this does 
> not reflect their concept of digital reality.
>
> It doesn't matter how much machinery of trust or security or 
> encryption or DRM or VPN or anything else we employ, at the end of the 
> day the client endpoint has open data at its disposal which it needs 
> to get its job done, and no technical barriers against doing with it 
> whatever else it wishes.
>
> It's incongruous that we speak of "trust domains" (it's those fluffy 
> clouds again) when all we really have are cryptographically assured 
> endpoint identification and no trust at all.� You can't trust someone 
> whom you don't know as a person, and it's a fiction to claim that 
> trust has been obtained.� We would be more honest if we exchanged 
> "Trust Placebo Tokens", and then we could at least laugh at our own 
> eclectic joke, while openly admitting that we are not actually 
> providing anything of value beyond knowledge of the endpoint.
>
> As you say, there is nothing we can actually do about this, because 
> all we can do is exchange messages containing structured information, 
> and we can't control people.� "Trust" about what happens beyond the 
> endpoint is something that our technology cannot convey, and really 
> using terms that suggest otherwise just deludes people who don't have 
> the background to know better.
>
> On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>
>
>
>
>     On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Meadhbh Hamrick <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     <mailto:[email-masked]>
>     >>
>     >>
>     >>
>     >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> > "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >> >
>     >> >> BTW, the Red Zone statistics of 9 million �scans with only
>     78,000
>     >> >> rogue viewers captured lets us know that this �problem is
>     >> >> �technical solution.
>     >> > � needed to allow me to access what I needed to access.
>     >> > etc etc
>     >> >
>     >> > Carlo Wood <[email-masked] <mailto:[email-masked]>>
>     >> > [email-masked] <mailto:[email-masked]>
>     > Carlo Wood <[email-masked] <mailto:[email-masked]>>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

--

---

From: Morgaine <[email-masked]>
Date: Sun, 3 Apr 2011 22:22:00 +0100

I like domains, Dzonatas.  I use them thousands of times daily in the Domain
Name System, and such domains have very precise definitions, concrete
services that implement them, a well defined network protocol and many APIs
and bindings.  These domains are something concrete, and productive.

In contrast, Agent Domain and Trust Domain are neither.

I'll leave it at that and let you have the last word, because this
discussion is similarly unhelpful.

Morgaine.

========================

On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas Sol <[email-masked]> wrote:

> You mock fluffy clouds, yet you wrote "It was designed". To not write even
> close to formal English, when you made use of subject-less sentences, and
> complained about meanings and (glossary) usage, is incongruous.
>
> Just state you don't like the word "domain". There is no need to mock me or
> anybody else to win points.
>
> Morgaine wrote:
>
>> It's an unfortunate reality that a puzzlingly large proportion of users
>> have a hard time grasping the total absence of content security in a
>> platform architecture which sends nearly all content types to client
>> machines by design.� It was designed that way for very good reasons, and
>> those reasons are as valid today as they were at the time that it was being
>> designed, but it can be hard to get across that this is how it is intended
>> to be and not a fault.� Some people's aspirations are destined to be forever
>> unsatisfied because this does not reflect their concept of digital reality.
>>
>> clouds again) when all we really have are cryptographically assured endpoint
>> identification and no trust at all.� You can't trust someone whom you don't
>> know as a person, and it's a fiction to claim that trust has been obtained.�
>> control people.� "Trust" about what happens beyond the endpoint is something
>> On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Apr 2011 15:15:19 -0700

This discussion is very helpful, and this is not about "the last word".

Figure-of-speech like ""It was designed" is not anywhere near any 
complete idea without assumptions. Appeals to common sense are still 
within the realm of figure-of-speech (and obviously does not meet 
accessibility needs). Concrete sense needs complete ideas and neither 
common-sense nor assumptions. Grammatic informal English allows 
assumptions, yet still does not allow incomplete ideas by subject-less 
or ill-verb usage. This all is very helpful knowledge (requirements) in 
documentation that makes sense to everybody. If someone writes totally 
crazy and "lacking" in abilities to type complete sentences, yet they 
write anywhere near formal English with complete ideas, that someone is 
not stupid. That someone might have took all day to write what they day 
compared to what it takes you to write in minutes. How do you think 
someone feels even when slightly mocked under such conditions?

There is no need to mock people (even non-chaletly) due to their 
accessibility needs, which you now appear ignorant about where you wrote 
"because this discussion is similarly unhelpful."

Agent Domain and Trust Domain are use-cases, which have been used as-is 
in past documentation and current glossary entries. If that is the end 
of your discussion then that proves there was no reason to complain 
about past usage of those instances (because "you can't change the 
past"). Those still exist despite the implementations did not happen 
(...publicly).

In contrast, documentation without implementation is not concrete. UNIX 
is the only system, yet, that still remains purely written in 
documentation without implementation. All other implementation based on 
UNIX are derivatives . UNIX proves exactly the depth of documentation 
that needs to exist before any real implementation can exist.

Further, this is the IETF list, and thus not limited to LL/OpenSim only 
politics of what exists and what doesn't.

Morgaine wrote:
> I like domains, Dzonatas.  I use them thousands of times daily in the 
> Domain Name System, and such domains have very precise definitions, 
> concrete services that implement them, a well defined network protocol 
> and many APIs and bindings.  These domains are something concrete, and 
> productive.
>
> On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     You mock fluffy clouds, yet you wrote "It was designed". To not
>     write even close to formal English, when you made use of
>     subject-less sentences, and complained about meanings and
>     (glossary) usage, is incongruous.
>
>     Just state you don't like the word "domain". There is no need to
>     mock me or anybody else to win points.
>
>     Morgaine wrote:
>
>         It's an unfortunate reality that a puzzlingly large proportion
>         of users have a hard time grasping the total absence of
>         content security in a platform architecture which sends nearly
>         all content types to client machines by design.� It was
>         designed that way for very good reasons, and those reasons are
>         as valid today as they were at the time that it was being
>         designed, but it can be hard to get across that this is how it
>         is intended to be and not a fault.� Some people's aspirations
>         are destined to be forever unsatisfied because this does not
>         reflect their concept of digital reality.
>
>         encryption or DRM or VPN or anything else we employ, at the
>         end of the day the client endpoint has open data at its
>         disposal which it needs to get its job done, and no technical
>         barriers against doing with it whatever else it wishes.
>
>         It's incongruous that we speak of "trust domains" (it's those
>         fluffy clouds again) when all we really have are
>         cryptographically assured endpoint identification and no trust
>         at all.� You can't trust someone whom you don't know as a
>         person, and it's a fiction to claim that trust has been
>         obtained.� We would be more honest if we exchanged "Trust
>         Placebo Tokens", and then we could at least laugh at our own
>         As you say, there is nothing we can actually do about this,
>         because all we can do is exchange messages containing
>         structured information, and we can't control people.� "Trust"
>         about what happens beyond the endpoint is something that our
>         technology cannot convey, and really using terms that suggest
>         On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>            <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>
>
>            On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood
>         <[email-masked] <mailto:[email-masked]>
>            <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>         <mailto:[email-masked]>
>            <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>            >
>            >> if you're a company like Linden that needs to respond to
>         DMCA
>            takedown
>            >> requests, you're likely to require the client trust knob
>         turned
>            up a
>            >> as protocol developers, it's our duty to create a
>         protocol that
>            meets
>            <mailto:[email-masked] <mailto:[email-masked]>>
>
>            >>
>            >>
>            >>
>            >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood
>         <[email-masked] <mailto:[email-masked]>
>            <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>            >> > "[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>"
>
>            <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>            >> >
>            >> > visible (ie, you could make a screenshot of the
>         surface of a
>            wall).
>            >> > Secondly, if the first creator could upload this
>         texture then
>            so can
>            >> > an uploaded texture "looks like" one of the already
>         existing
>            billion
>            >> > twice, ie from jpeg2000 to jpg to tga and then
>         uploaded, then
>            you'd
>            >> > need a human to look at the original and the newly
>         uploaded
>            texture
>            >> > honest viewers) is tremendous: if you're not an expert
>         or do
>            not pay
>            >> > impossible to keep something full permission and often
>         we're
>            stuck
>            >> > do what he wants to do. There are many other such
>         examples.
>            Hence,
>            >> > default at so many levels that you need an IQ of over
>         140 to
>            create
>            >> > create a new account is no transfer, what kind of
>         insanity is
>            that?!
>            >> >
>            >> > Carlo Wood <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>            > Carlo Wood <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

--