Re: [vwrap] Simulation consistency

[Meadhbh Hamrick <[e-mail]>]

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


--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood <[e-mail]> wrote:
> On Sat, 2 Apr 2011 10:01:43 -0700
> Meadhbh Hamrick <[e-mail]> 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.
>
>> 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
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>
>>
>>
>> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <[e-mail]> wrote:
>> > On Sat, 2 Apr 2011 14:12:59 GMT
>> > "[e-mail]" <[e-mail]> 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 <[e-mail]>
>> > _______________________________________________
>> > vwrap mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/vwrap
>> >
>
>
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>