|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
WarKirby Magojiro - 30/Oct/07 07:43 AM
I'm inclined to agree, gigs. If someone ccan see a texture, they can copy it trivially. Print scren. Gl intercept. UUIID grabbers. And this new search too, apparently. Sounds, animations, etc. Can be copied, with some difficulty. But textures are pointlessly trivial as to maker permissions useless.
Texture permissions are still useful. I know that YOU can trivially copy any texture, but most technical people don't know how. The permissions system does enforce texture permissions. Example:
* 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? It's not legit at all.
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. That URL provides slightly scaled versions. The steps above provide full versions, as do GLIntercept, adding the headers back on the textures in cache, or any other of a dozen ways that inherently require no serious technical knowledge.
A very good point Gigs - on the UUID etc - programming level.
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 I know this is kind of an old discussion at this point, but in coming back here and rereading this, I have to say I'm still of the same opinion. I know that, technically speaking, nothing protects textures. However, that doesn't mean that it's _okay_ to copy any texture you see on someone else's object. Technically speaking, it's quite possible, but legally speaking, it's against the law. Why not make the system put hurdles in the way of those people who want to break copyright law and copy a texture illegally? Those hurdles are ultimately circumventable, but that doesn't mean that they don't serve a purpose.
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. Lex,
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? To be frank, I've been wondering why that has still been in the menus ever since the whole patent/intellectual patent mess started making headlines. (For example, viewing source could become some feature hidden into the plugin API, for example, so at least one'd need an explicit add-on to do it. It might be a slight pain for web developers, but to be honest, we usually use plugins like Firebug anyway.) But I suppose the reason could be that the tradition started in the days when the IP mess wasn't as severe or visible.
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. Go take a look into the real SL people. Most residents CANNOT script. Most residents CANNOT make a one line script.
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. Celierra, I wouldn't be a fan of locking llSetTexture() down to some registered group of allowed coders... that'd be a big mess and I'm not a fan of restricting the language like that. Watermarking could be interesting, but I'm not sure how feasible that is when using lossy compression like SL does.
Lex, I agree in terms of watermarking and I believe it is feasible but only if done on the server side before the texture is sent to the client and no non watermarked texture data is sent to the client (due to open source clients not having to enforce any non server side restrictions)
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. There are legitimate reasons for at least LSL to have access to texture UUIDs even if a way was implemented to prevent them from being visible, an example of this is a billboard I made where people can use _________ (scripters have to have their secrets after all) to plant their textures on the billboard but for that to happen the board has to be able to access the texture via it's UUID for several purposes, I'm entirely opposed to crippling LSL though even if it were a way to make UUID's available to LSL without them being available to the scripter (unfeasible in several major ways) or any other way, I also don't think LL would agree to something like that.
I agree that it's a change in designed behavior not a bug and have changed it as such.
Yes, of course there is something actionable:
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. I think you're going to have a hard time arguing in court that copying texture UUIDs is against the law. You're not copying the texture. It all stays in LL's asset servers. And the reality is, you *have* to copy the texture to view it at all. Several times. You are not going to be able to make any copyright infringement claims based on "copying" UUIDs.
Now, getting someone banned based on TOS violation, that might be doable... A bug is a flaw in the coding or design of a system, the fact that you do not want this feature does not make the existence of such a feature a bug. I am disappointed that both you and apparently Linden Labs are willing to give into the panic mongering crowd that would rather have the illusion of security rather than work towards actually having more true security where it is really needed i.e. preventing transaction exploits and scam, grid stability,... etc.
I agree with Seg on that, if someone is copying textures you have the right to send an abuse report to LL (which they make or may not act on), A DMCA (which they have to act on) or sue them and whoever stole the texture (once you sue LL to get their RL info). I also agree with the comparison to a web browser hiding the save image button, or to take it even farther you'd probably like it if every browser was outlawed from having a view source button since viewing webpage source code can be used for all kinds of infringement. Your argument breaks down if you look at those two comparisions.
I've taken the liberty of emailing Torley since he's been following the various permissions issues recently, hopefully he'll pull himself away from his other issues to chime in on one side or the other on this.
I don't have a problem with Linden Labs providing an incentive to follow the permissions system, by making it a bit inconvenient to bypass, so while I agree with the sentiments in the subject I don't believe the proposed solution is necessarily desirable.
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... I know I've been made out to be the bad guy here but I just want to clarify that I don't want to scrap the permissions system, I just don't think that security through obscurity is the answer, and really the fact that this is even an issue is the fact that the permissions system is flawed from the symbol {, It is also flawed to blame the open sourcing of the client for the recent issues with the permissions system, the open sourcing just made it more evident that the system is flawed. Unfortunately there's no waY to currently fix the system that I can see without doing a massive overhaul that would undoubtedly screw over every content creator, every scripter, and everyone with >0 objects in their inventory that they either didn't create or already have full perms since it would require massive server side changes to how permissions are handled not to mention how assets are handled in the client.
I apologize for the last comment being one big blurb, I'm too tired right now to bother with proper paragraphing, I tried to keep it somewhat short though so it's at least moderately readable.
Nor will I and I won't revert it if Gigs decides to change it back to bug though I'd ask respectfully that he not.
Instead of hiding and making it harder to get at the bits of an UUID there should be more incentive to not copy stuff at all. Content theft is seen as bad behaviour and should be seen as that. The community is a better copy protection than software alone can give. Better work on tools to detect content theft and provide a warning for View Admin Options usage, giving the incentive to not abuse that feature.
For Texture permissions I only see two of them being really useable: modify: to allow renaming and changing description transfer: to allow sharing the texture with others I really do not agree with the comment:
"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? My concern with this issue and comments in similar vein (e.g. on
I think there have been some very interesting comments and views in relation to the use of permissions. However in regards to Gigs comments I agree with his concept of bug. To elaborate:
'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. While I'm sure it's not trivial to make this change (and of course, it's not 100% foolproof), is there a reason why a permission check couldn't be made for any script trying to set a texture with a UUID?
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? Fnordian,
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. llSetTexture in its current state is similar to netbanking not requiring a password. You can just type a name and withdraw whatever you need.
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. As texture and web content maker, I know anyone that see can copy, I don't get fooled that any technical system can prevent this and live but this real life rules. The permission however is an easy way to show my intentions to the receiver of the texture.
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. "The permission however is an easy way to show my intentions to the receiver of the texture."
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. Actually, that's a good reason to get rid of texture permissions.
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. I do agree with good intentions. However, that does not make it "copyright law".
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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Open
Normal
Users are misled into thinking texture permissions do anything.
