Hubris, was Re: [sldev] Cache politics: performance vs obfuscation

[Barney Boomslang]

I have to agree with Ordinal here. Yes, obviously, data sent to the client
is decodeable by the client and not possible to protect perfectly. That's a
given. But that does not say at the same time that you should make things so
simple that taking textures is obvious. We still don't put bars on our
windows, even though we absolutely know that breaking glas is easy. We still
put paper envelopes around our letters despite everybody knowing that paper
envelopes don't protect their content. Yes, the professional thieve won't
have a problem with breaking your doorlocks - but that doesn't say you rip
out your door and let anybody walk in unhindered.
The very same reasoning works for software, too. Right, there is no perfect
protection. It's pointless to flog that dead horse all the time - but it's
at least as pointless to throw all limitations out the window just because
of that argument. There are ways to give content at least a token protection
that will prevent the most stupid ways of content to spread. No, that won't
keep professional thieves out. And yes, it would be ridiculous to go to the
lengths the music industry tried to do with DRM, because that will actually
harm the users more than the thieves.

Practical example: watermarking images in SL and checking those watermarks
on re-upload would be an easy way for said token protection against too
simple copying. And would add ways to claim ownership. No, definitely not
perfect protection, but doable without adding harm for users or degrading
performance (as the check is done on upload only and the watermarking right
after upload). Would that solve texture-theft? Nope. But it would at least
keep some of it onder control. Don't underestimate the results of the
proverbial slap-on-the-wrist with most people.

bye, Barney

On Mon, Jun 9, 2008 at 11:22 PM, <ordinal.malaprop at fastmail.fm> wrote:

>
> On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote:
>
>  Dante Tucker wrote:
>>
>>> Lets all just stop pretending anyone who wants to steal textures can't
>>> with the current system. Anyone who wants them can already get them. The
>>> only thing storing data raw would do is make them more accesable to people
>>> who don't want them and have no knoledge of how to get them currently. And
>>> if they don't want them then whats the harm?
>>>
>> Agreed.
>>
>> I tire of people moaning about IP security.
>>
>> Your stuff is already stolen, deal with it.
>>
>> ~Tom
>>
>
> Not to pick on Tom particularly here, but this is the sort of m message
> that reinforces my opinion that:
>
> (a) the people involved in discussing assets don't understand what those
> _creating_ the assets want or think;
> (b) they don't care.
>
> The level of snobbery applied here is breathtaking, endless references to
> pitchforks ho ho, you know, they're all irrational peasants. But even in the
> current situation, textures not being instantly obtainable by just going to
> the right directory and dragging to somewhere else is a disincentive to
> pirates.
>
> YES, we do all know about glintercept and all the other ways to get hold of
> textures. YES, we know that there is an intrinsic problem here, that
> displaying the damn assets implies that they are received by the client.
> YES, we've all heard these teenage extropian "information wants to be free"
> tropes, thanks all the same.
>
> Amazingly enough, people appreciate the practical issues. What they don't
> like is the idea that they are being treated as idiots and rubes by LL and
> assorted geeky types because they dare to get worried about the reason that
> they are there and building the world for you lot to play about with in the
> first place. Because, you know, if it wasn't for people who make content,
> you and I would not be here discussing this stuff, as I've said before.
>
> If you can't offer anything to content creators apart from "ha ha your
> stuff has already been stolen stupid n00bs" then you might as well close the
> whole company down right now.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/01281b0f/attachment-0001.htm