• You buy a no-copy texture.
• You apply it to a face on a prim.
• The texture is moved by SL into the inventory of that prim.
• If you remove the texture from that prim's inventory, any face it was on is turned to plywood.

So I think it's fairly legit to keep texture permissions.

I am kind of concerned by that url you listed above, though. Does that provide a full-resolution copy of any texture in SL?

For the non-technical:
Enable View Admin options
Select the object you want the textures from.
Press Ctrl-alt-shift-T
Copy the UUIDs.
Use these texture UUIDs from LSL wherever you need them with llSetTexture(uuid, ALL_SIDES);

If "writing a 1 line LSL script" is a huge technical hurdle that somehow makes textures "hard" to copy at will, then the SL userbase is stupider than I thought.

Just a thought that diverting slightly from this thread again, although I agree that users are missled by permissions.

I am drawing on - the copy only function serves to prevent users from passing on textures but with the danger of simple screen print theft.

Perhaps something like texture ''watermarking' would be a useful perm - that could be included or as an addition to the orignial copy perm. Similar to photographers tools in RL. A sort of 'true full perms' and 'limited full perms' option to allow selling of orignal materials with out the associated abuse - if you get my drift. I think watermarking would still allow users to search textures visually (for their own legit use), but 'reduce' other forms of copying etc... I think such an feature would also be highly desireable for sculptie textures.

Although I should say that this idea is being proposed to some degree here:

https://jira.secondlife.com/browse/MISC-288

and similar here:

https://jira.secondlife.com/browse/MISC-330

Almost all locks on houses can be trivially circumvented in a matter of less than a minute through various means. Breaking into a house is still illegal, though. The lock is there less to actually prevent someone from breaking into the house than to prevent them from breaking into it easily; it turns away people who just "test the knob" to see if they walk right in. I think the texture permissions system could be seen to do the same. It's a lot harder to go through the several-step process of acquiring a texture's UUID and then setting it on your own prim with a script than it is to simply drag the texture from your inventory onto a prim or eyedropper it from someone else's object. Those extra steps are often enough to make someone stop and realize they're doing something they're not supposed to do.

Why do browser makers put "view source" as an option in the menu? Surely that should be removed to add a hurdle for would-be infringers, right?

I think the "right thing" would be to redesign the system without any of these circumventions (ex. an explicit set of allowed users for llSetTexture, slightly lossy/watermarked textures from server), but at this point, I can't think of how one could do this without tons of content-breakage and such. I don't think "have no semblance of IP protection at all, after already declaring in-world content as 'yours'" is an option, to be honest.

People like me are able to make a decent business out of selling objects with our own textures, and our business would soon come to an end if everyone could take our textures easily and knew how to do it. Because many people don't know how to steal our texture most buy our items instead of rip them. If they could get them easily, it would soon mean the end of our shop.

So thanks everyone who puts great effort into informing the public of how to do so and coming up with ideas on how to prevent LL from improving anything. A big thanks.

Incidentally is there anything actionable on this issue? if not then it should probably be closed since it's not the place... yes I realize there is no proper place anymore but still.

Remove all texture permission flags, and make them all full perm, to reflect reality.

A bug is defined by there being a disconnect between user expectations and actual program behavior. This is a classic, clear cut bug.

Now, getting someone banned based on TOS violation, that might be doable...

I sure hope that we can find a middle ground between the people who think the permissions system should be abolished and the folks who believe it's something hard and tight and secure and anything that shows up the fact that it's not really much stronger than the "honor system" is a critical flaw that demands overreaction...

"Remove all texture permission flags, and make them all full perm, to reflect reality. "

Just because in reality things can be stolen in a certain way means we should make it as easy as possible? Why not hand out all second life textures full permission right away? Yes DMCA's and lawsuits are possible..but who is gonna do that for a texture?

'A software bug (or just "bug") is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result)... Others qualify as security bugs and might for example enable a malicious user to bypass access controls in order to obtain unauthorized privileges...They arise from oversights made by computer programmers during design, coding and data entry...'

Source (accessed 20/12/2007): http://en.wikipedia.org/wiki/Computer_bug

In this respect Gigs comment in removing permissions to reflect reality has significant weight in emphasising the true nature of this problem. Although I would have to agree for the moment, at least, there is a small semblance of protection for texture designers, from the casual and inexperienced user, to protect their images by means of current permissions provided untill a satisfactory patch is provided. However, there is no getting away from the fact that textures are probably the most vulnerable element in SL and Gigs is right to highlight this problem as a bug that misleads people into thinking they are fully protected, particularly in the way these permissions are presented to users in the client software.

In order to avoid messing up all legitimate texture references in scripts, the permission check should pass for textures that aren't copy/transfer if the texture is:

a) created by the script creator;
or b) created by the current script owner;
or c) owned by the current script owner.

Copy/trans textures are no problem, of course. But how many legitimate textures are accessed in a script where the script creator doesn't even own them?

Sure, this does nothing to stop screen shots. It may not even help with certain other methods if the texture can be captured and re-uploaded without needing to display the original via a script first, but I suspect a change of this nature would render the vast majority of texture-snagging methods useless.

Am I mistaken?

Or is changing the code to perform this permission check next to impossible?

That wouldn't accomplish anything, since you can just as easily reupload the texture with yourself as the owner. If anything, allowing LSL to apply textures by UUID without regard to permission makes it easier to catch people doing something they aren't supposed to.

All any of these things do is make it harder to catch people actually infringing on copyrights.

I know that resource theft can never be 100% prevented, but making it rediculously easy certainly doesn't help. Alot of thieves steal because it's easy. Once it becomes harder, it begins to seem like work.

My guess is that programmers often don't realise what a huge amount of work goes into making a texture map, so this function seems fine to them.

Imagine if Linden Lab made a llCopyScriptFullPerms() function? I imagine alot of scripters would feel frustrated when every noob could steal their work in a few clicks.

The viewer are just as a web-browser when you put info into SL or on the web people can (and will copy) it's reality, one have to adopt once sale model after it, not build up false hopes.

Nadine, that was very well put. Regardless of how easy it is to steal textures in SL or images off the web, it's still against copyright law. The permissions system does provide a convenient way to make it clear whether or not you, as a copyright holder, intend to allow others to copy and distribute your content.

That in and of itself is enough of a reason to keep texture permissions, and it means that they DO do something.

It would be much more useful to replace them with a copyright license that conveys your intent in a precise legal way. Permissions are vague and open to interpretation. An explicit license lets everyone know what your intent was with distribution terms.

Sections 3.2-3.4 seems pretty clear to me:

3.2 You retain copyright and other intellectual property rights with respect to Content you create in Second Life, to the extent that you have such rights under applicable law. However, you must make certain representations and warranties, and provide certain license rights, forbearances and indemnification, to Linden Lab and to other users of Second Life.

3.3 Linden Lab retains ownership of the account and related data, regardless of intellectual property rights you may have in content you create or otherwise own.

3.4 Linden Lab licenses its textures and environmental content to you for your use in creating content in-world.

Translation:

ALL YOUR DATA ARE BELONG TO LINDEN LAB.

3.3 Means that you don't own your "account", in so far as you can't sue Linden Lab for closing it, you can't license your account, or sell your account on Ebay.

3.4 Means you can use the Linden Library textures/objects and other stuff that comes free with your client for building things in SL.

3.2 ..You also understand and agree that by submitting your Content to any area of the Service, you automatically grant (or you warrant that the owner of such Content has expressly granted) to Linden Lab and to all other users of the Service a non-exclusive, worldwide, fully paid-up, transferable, irrevocable, royalty-free and perpetual License, under any and all patent rights you may have or obtain with respect to your Content, to use your Content for all purposes within the Service.

3.3 You agree that even though you may retain certain copyright or other intellectual property rights with respect to Content you create while using the Service, you do not own the account you use to access the Service, nor do you own any data Linden Lab stores on Linden Lab servers (including without limitation any data representing or embodying any or all of your Content)..

3.4 During any period in which your Account is active and in good standing, Linden Lab gives you permission to create still and/or moving media, for use only within the virtual world environment of the Service ("in-world"), which use or include the "textures" and/or "environmental content" that are both (a) created or owned by Linden Lab and (b) displayed by Linden Lab in-world.

****

Talk about covering your ..err.. assets. Basically if you've went through all the legal hassle of procuring real world copyrights and trademarks you retain those real world intellectual property rights, although the way the remainder of the stipulations read to me as if all in game content (including user uploaded content) is OWNED by Linden Labs and given freely to the users of Secondlife to be used solely for in game purposes. Here's the real kicker though:

3.2 ..You further agree that you will not make any claims against Linden Lab or against other users of the Service based on any allegations that any activities by either of the foregoing within the Service infringe your (or anyone else's) patent rights.

Now is it just me, or does that really say it's against the terms of service to accuse someone of "stealing" content in game? =^.=

3.3 This is just expanding what you said it said earlier, you don't own your account, i.e. the fixed representation of bytes sitting on a hard disk at LL's data center. That's mostly to protect LL if they should lose all your data. You also can't go to LL's HQ and demand a copy of all your data if you account is banned.

3.4 This says you can pretty much use any Linden created content for whatever you want.

Although you CAN easily (or not) copy textures, doesn't mean its right. The texture permissions are a way for the creator to communicate their copyright intentions on the texture, up to them to use any means to enforce it or not.

I CAN steal my neighbors car too ... actually quite easily. But its not right.

I agree that the best we can do is communicate intent. Permissions, as they exist today, are a very poor way to do that. They mislead some creators into believing that it's an effective technical means to protect their creations, when no such technical means exists. That is what this bug is about.

My worry is not the overall discussion about texture copyright and ways to deal with it. It is a complex issue. What I do worry about is this: There seems to be a way to rip textures from objects Inworld, with just a few mouseclicks, when some debug settings are changed.

I do not understand why ripping is made so simple!

There's no point in try to make it "hard". Think about the web. You can save any image you want off the web right? If one browser made it harder to do, people would just use a different browser. It's the same with SL, people can use whatever viewer they want. I can guarantee you that people that want to rip textures off will just use a viewer that doesn't make it "hard".

Anyway even though people can save images off the web, sites still make a living selling images. It's not impossible.

Name me one site that sells images that has no build-in security to prevent ripping. That is the point, in making it 'hard'. And that is why they make money. Look:

http://www1.istockphoto.com/file_closeup/object/4974211_isolated_linden_tree_leaves.php?id=4974211

So I guess your point is that watermarks and low-res previews are a good idea for shops selling textures. That's not a bad idea for texture stores in SL as well. But for most "textures" (images) in websites, it's as easy as right-clicking and selecting "save as.." to grab the image. Or you can simply open the image cache directory of your web browser or SL viewer to get the image, which is already on your hard drive.

VWR-1919 is already undone on the most popular ui-modded SL viewer that I know of, so I don't see the point in crippling ctrl+alt+shift+t for getting texture UUIDs in the main viewer. But if this security model is valid, maybe we should make fork of Firefox that doesn't let the user view HTML source code or save images? I'm sure it could be a hit ; )

It's this geek "0/1" or "100 percent or nothing" extremism that really hobbles the discussion. And it is being decided here by NON stakeholders who are not making and selling content with permissions and whose livlihoods do not depend on doing this. That's unjust, and wrong.

The discussion on SL-DEV has been disgraceful, and ideological, and not technical.

The permissions system must remain, even if it has holes, because it signals intent, and most people comply with the creator's intent and most people do not have the technical ability to rip off a content creator. Most people on the web, in fact, are deterred by either copyright notices or by prevention of right-clicking. Most people are not going to bother to tinker with printsqueen or various devices to try to copy content. So signally intention, putting in hindrances, and invoking laws and social polices are all necessary, and no one of them can work alone.

This is a feature, not a bug, and the persistence of the Lindens in allowing it to be presented as a "bug" is the sort of extreme Stallmanitism that they should be curbing here.

It's actually a fully relative cost-benefit analysis that leads to the conclusion that imperfect protection should be avoided.

Any client side protection is fundamentally flawed in that it can be easily circumvented by any programmer. You say "everyone isn't a programmer"... That's true. But it only takes one programmer to write the program, and then, anyone who likes can circumvent the protection. So what does it actually accomplish? People who have a legitimate reason to back up a copy of their stuff have to jump through extra hoops, and are lumped in with someone who actually wants to commit real infringement. Because the benefit is so small (malicious infringers need to locate some freeware), and the there are non-negligible drawbacks for legitimate users, it doesn't make sense.

But that's not what this issue is about. This issue is that there isn't any protection currently, but the permission system implies that there is. One way to solve it would be to add some sort of non-trivial protection... But obviously that's not a resolution that I personally think makes sense.

The presence of a user utilizing a viewer known to have circumvented DRM type controls should be viewed with interest by LL.
So should the intent of the person that wrote the code.
If LL removed people from SL that demonstrate clear intent to circumvent LL's controls then perhaps we would see less of this type activity.

example/analogy not directed at anyone in particular: If a person has a lock picking tool set in their possession and they are not a licensed locksmith then what do they need such tools for.

At minimum every person connecting with a non LL browser should go into a suspect registry and when something is found to be stolen the data mining done to see if intent was present in the form of using viewers coded to circumvent controls. If so then all assets of the guilty party are removed and machine bans enforced.etc etc.

LL needs to bring some real world thinking into this mix.
I would love to hear from LL's general counsel on the topic of LL's liability for not providing controls on what code can directly access LL's network assets.

That's not technically possible. I can gain access to anything generated on my computer, especially if I can see the source code of the client and see how it retrieves the token from the library.

> At minimum every person connecting with a non LL browser should go into a suspect registry...

I run the Nicholaz third-party client. I'd rather not be in ANY "suspect registry", even if it's only used as you describe. People make mistakes, make false assumptions, etc. I don't want someone accusing me of stealing resulting in all my data getting wiped.

> I would love to hear from LL's general counsel on the topic of LL's liability for not providing controls
> on what code can directly access LL's network assets.

The iron-clad law of computing is that I can reverse-engineer anything that happens on my computer and fool any authentication mechanism (such as DRM and the like) if that mechanism runs on my computer.

This proposal is a false dichotomy, there are more then two solutions here. The problem stems from users assuming that permissions are DRM. That permissions impose technical restrictions.

The correct solution to this is to make it plain and obvious to all users that permission only convey the intent of the texture creator and not provide any significant technical restrictions. That the permissions dictate the licensing agreement between the user and the creator, and that while it is possible to skirt the agreement, to do so would be illegal.

If the user base understood that permissions were a form of licensing agreement and nothing more, then issue VWR-2909 would evaporate because there would be no misleading.

The usual solution is to make the behavior match the expectation, in this case, it's probably going to be easier to make the expectation match the behavior.

There are multiple ways to accomplish this, and really I'd be happy to see any of them go in. As long as we maintain this "false illusion of effectiveness" though, we have a problem.

It complicates DMCAs badly because the content creator risks damaging their own content by having the content blocked to the infringer. it's a huge mess, and permissions need an overhaul > if to just do a little checking on WHO should be using assets, as opposed to letting leeching just go unchecked. And say if its another grid leeching LL assets > don't you think there should be at least SOME server side checking.

I'm in the category of those that say yeah, there needs to be better security on the server side, in regards to assets. It doesnt have to be STRONG DRM, but come on, bandwidth leeching is sort of an old WWW issue, and its sure likely to rear its head again before long.

Arguing about this pjira entry is rather pointless wouldn't you say? The same 3 permission settings are present for each and every item in inventory. It is not going to change. Utterly pointless pjira.

An intelligently written pjira feature request for this would be part of a request for a permissions system overhaul (which is needed but unlikely to be done with the existing staff of LL unless ordered by the CEO).

This issue needs to be closed as irrelevant.
([Closed - Irrelevant] <- a needed jira resolution eh?)

Flickr is a great WWW example. They very effectively block linking to private and restricted content hosted on the service. You can right click > save as all you want ... you can even save out pictures at low res if they block the save as function (but you'll only get a low res picture), but you can't link a restricted Flickr picture on your own site. Only open Flickr content is linkable. It's that way by design

There are two issues being mixed up here. right click > save as never did have anything to do with inline content. Using UUIDs which you haven't got permissions to use has far more to do with inline content linking and nothing really at all to do with the ability to save content you view on a website.

UUID's are a security issue if in fact you don't have permissions to use them. And yes, its also a copyright issue if you in fact do broadcast the restricted asset in question.

I think it's important to understand that textures need to be easily used and displayed, therefore there will never be airtight security where this is the case. Sure, that's fine. I in fact have no problem with that. I'm well aware that if you can see it, you can copy it. This is in fact not what I am after. You may even notice I am sort of arguing a situation that forces one to rip and reupload instead of using restricted UUIDs easily. Why that? Because its far easier to block the infringing content through technical and legal channels without damage to legit content if that's the case

It's not a feature request. It's actually not a big deal. It's simply a bug report.

Reproduction:

1. Upload a texture.
2. Mark that texture "no-copy" or "no-transfer" or "no-modify".
3. Give that texture to another user
4. Note that they can still freely copy/modify/transfer the texture using any one of several means.

Expected behavior:
That the no-copy/no-modify/no-transfer flags actually accomplish something.

Actual behavior:
The copy/mod/transfer flags on textures do not function properly.

If we had any other feature that claimed to do something but failed utterly at doing what it was supposed to do, we'd file a bug report. Just because people get uptight about this subject doesn't change that.

As for how to solve this bug, well, there's two options. Invent a DRM system that works, or get rid of the permissions that are broken.

They already work, kinda. And I have hope that LL will in fact, finish the rest in light of the recent copybot fiascos.

First off > It's not DRM, and it never was. There is no DRM in the files themselves > this is done by the backend asset server system, just like any network system > you have users with various rights to various files and directories. It's a simple prevention from using a UUID when you haven't got perms for it. It's in fact, NOT a difficult thing and contrary to people who claim "the world will be falling" > should not cause SL to fall down. (if it does > geez do we need a better architecture!)

I don't know why people think its hard. It's simple rights settings for files and users > do I have next owner permissions to this file > yes/no > allow linking/block linking

I learned this stuff way back in the old pre-WWW days when I was working with Novell networks. It's how sites like Flickr work (is this open content/restricted content > open content > link works — restricted content > link fails). Why can't SL?

It could be that the current perms system isn't enough > fine, then let us have a restricted to our own content option which prevents any copy or transfer, basically a "view only" setting as suggested in VWR-4970.

http://en.wikipedia.org/wiki/Access_control_list

That is what we're talking about here. File attributes for access control lists. How best to go about it, I'm all ears. But its NOT DRM. Never was, and still isn't.

If you think UUIDs should have permission checking, go file a new issue. That's not what this one is about.

then it's about file attributes. Which you originally wanted to remove. Which makes no sense, really. Every operating system and network has file attributes.

UUIDs are just one feature of that > its just the "file name".

Quacks like a duck, walks like a duck... its not a mouse. Really.

Actually, are they really broken?

Modify on a texture > allows you to change the textures name.

Works > check

copy on a texture > allows you to make multiple copies in your inventory

Works > check

transfer on a texture > allows you to transfer that texture from your inventory to someone else's inventory

Works > check

Are the texture permissions in fact broken or just not working as people expect them to?

More likely the latter. But they do in fact, work.

People assume that the texture permissions are working to prevent people from actually requesting access to textures they upload. They do not. There is no access control on textures.

Should there be, or should not be > good question. But again, it's not DRM. It's Networking 101.

As I talked about above, a bug is defined by a disconnect between user expectations and actual behavior. That's what this bug is about, users being mislead into incorrect conclusions. See the title.

With the latest RC, my textures are only transferrable when uploaded, I have to make sure i checkmark modify/copy if I want the next owner to have those permissions.

Getting texture info with admin options doesn't give them the UUID.

I think this should be resolved as fixed. If people still want to nitpick about how textures can still be stolen then open a new issue and mark it as MONITOR related because the textures are displaying on my MONITOR. o.O

Not so the wider Metaverse, where Lindens and AWGroupies are going to the IETF to put the case for standardization of virtual world technologies for interoperability. There, they are not promoting c/m/d.

So in effect, the Lindens continue to put it up in their own world as a temporary ruse to keep their current customers satisfied and not panicked, but in the wider context of IETF they abandon it as technical not feasible.

So if you are concerned about this, vote for withdrawal of the MMOX proposal from IETF until a decision is made to promote and enforce c/m/d

The permissions work as intended: They prevent copies from being made or transferred as individual inventory items. This was NOT intended to prevent a UUID from being used in a script for adding a texture to objects.

Right now, you do not and this very entry ALONG with some of the comments is doing nothing at all but PROMOTE the means you CLAIM are covered but not functioning.

Once again: Texture permissions are NOT MEANT to control the use of a UUID or other methods to copy said texture. They are meant ONLY for the actual asset itself and to control how the entry in the database is transmitted.

Gigs, if you'd like a leg to stand on for this in making the ethics call ... delete all of the comments you've made that outline how to circumvent the permission system.

Failure to do so is aiding and abetting such actions.