Re: [vwrap] [wvrap] Simulation consistency

Meadhbh Hamrick <ohmeadhbh@gmail.com> Sat, 02 April 2011 17:00 UTC

Return-Path: <ohmeadhbh@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F034A3A6866 for <vwrap@core3.amsl.com>; Sat, 2 Apr 2011 10:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Level:
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oVvA6Dtm4dB for <vwrap@core3.amsl.com>; Sat, 2 Apr 2011 10:00:24 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 169013A6864 for <vwrap@ietf.org>; Sat, 2 Apr 2011 10:00:22 -0700 (PDT)
Received: by iye19 with SMTP id 19so5331234iye.31 for <vwrap@ietf.org>; Sat, 02 Apr 2011 10:02:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=w96bUo9FBnSJygNoJckd+Gxo3Qc405zWTy1GIk07PJI=; b=AaIT3hNlI9WDKqqMFNhhHR5Dd5kDRN+A0f1Cy7BxK4IA+EyoJD2LeVNBrnUu7ensmO /WHL4+u1fgRq17qrYWzRN+TtWg3idK98LWGU2mQGIpnMVMVqTdmKtYQ+hiTUFdBw5tnV ybKpBBOnbPDV5AF1VEBusb9ex09qeq4ohiw2w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SsM0UdkaDZlQ5Aotfyt90piMFFRWp9oEgXG+QA7U7f/i1YnE4Fav4Y+b/l1qBz0OGw IWPNnPlsEIfJMSRK6LnPPvwueJYatggvlnNpZE5xG7mxfSVxHPDY+FnyVTpCgja4B2tn 5C4Alw+ESF7KhK/yUT1tY6h/d1XwuzzJpSHlI=
Received: by 10.43.57.78 with SMTP id wf14mr1800213icb.138.1301763723153; Sat, 02 Apr 2011 10:02:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.225.199 with HTTP; Sat, 2 Apr 2011 10:01:43 -0700 (PDT)
In-Reply-To: <20110402171923.13176462@hikaru.localdomain>
References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Sat, 02 Apr 2011 10:01:43 -0700
Message-ID: <AANLkTinAFea45Kxhqu4mCqtPVZnmkM96rMWepKeTywmt@mail.gmail.com>
To: Carlo Wood <carlo@alinoe.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: vwrap@ietf.org
Subject: Re: [vwrap] [wvrap] Simulation consistency
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Apr 2011 17:00:26 -0000

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/ * OhMeadhbh@gmail.com



On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <carlo@alinoe.com> wrote:
> On Sat, 2 Apr 2011 14:12:59 GMT
> "dyerbrookme@juno.com" <dyerbrookme@juno.com> 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 <carlo@alinoe.com>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>