|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 28/Jul/07 09:15 AM
(bumping back down to critical from blocker)
Updated this bug report as I have discovered that it also affects sculpties.
Hi and thank-you for your report! I wanted to let you know this question comes up time to time and I notice it was also asked on our security mailing list ( http://wiki.secondlife.com/wiki/Security_issues
 ) recently.
Phoenix Linden replied with this info: The current protocol for Second Life involves sending the permanent so I'm resolving it as such. I am not talking about intercepting packets. I am talking about the issue where you can see the UUIDs of textures in the official Linden Labs Second Life client when you enable view admin options.
What Phoenix is saying is that the security hole here is fundamental in the design. Removing this from the interface will make it no more secure. In essence what is being requested is security through obscurity and that should always be avoided. By having this feature, it creates no illusion of security.
I'm reopening this after finding copies of my items which used the exact texture (same UUID) being sold by other users. Why should the SL client make it so easy for anyone to grab the UUID?
If we are just going to make this information so easy to get, lets ditch the permission system on objects too. Phoenix claims that anyone can get this info by examining the packets anyway right? All this stuff can be copied anyway
Please recreate the illusion of security, thx. Please don't reopen this for the time being – I'll ask Phoenix if there's more info that we should have here for future reference.
>>Please recreate the illusion of security, thx.
agreed, also I suggest to anyone concerned about textures to use Digimarc: http://www.digimarc.com/mypicturemarc/ I reported this issue to the security list. Its much worse than described here. There is actually a way to get the UUID of any object (even attachments worn by others) regardless of the permissions set on the object.
Phoenix replied with an exact copy past of the reply I see here. This is just UNACCEPTABLE. Just because everything in SL can be copied, doesnt mean we throw our hands up in the air then hand over all the tools to allow it to happen. There are 2 places in the SL interface which display the texture UUID. We simply have to have this BLANKED out. Yes we know there are other ways, but it requires a little bit of effort which 99% of people will never try. Agreed w/ "recreate the illusion of security".
Fine, they can get the UUID other ways. At least we could make getting it slightly difficult. Is there any reason the uuid would even be shown? Really, I'm curious. What's the reason? If there isn't one, please, fix this. The reason "Anyone examining the packets (pcap, libsl, open source client, etc) can always trivially see the uuids." isn't enough of a reason to NOT remove the uuid from the texture picker. How many of the actual SL population does this? However, obviously, EVERYONE has the regular client and can do this.
Because they can get the uuid other ways we want to keep it insanely easy to get? That makes little to no sense. >>>What Phoenix is saying is that the security hole here is fundamental in the design. Removing this from the interface will make it no more secure. In essence what is being requested is security through obscurity and that should always be avoided. By having this feature, it creates no illusion of security.
Hello, and there is a reason macs have no virus and windows machines are plagued with it., well besides (somewhat) BSD. There is no reason to hand the keys to the castle, for no reason that I can think of. At least let them break in. at least that proves they were being malicious as opposed to using the software that was given them. Just because I can go to a bank and rob it with a gun does not mean the same bank should leave their vaults open to the public.
Its quite simple really. Damen Gorilla Thanks for your continued feedback – we have an internal issue to "Remove texture UUID information from UI unless full-perm" which I'll sync with this. Please understand, to be absolutely clear here, that this is an "illusion of security" and won't stop the determined. But if it makes you feel happier, then that's good.
 excellent excellent excellent, ty torley, i love my illusions!
Hmm even if its just stops only the not determined people it will be good!
One less person who steals is one extra, right? Thanks Torley! Changing type – this isn't a bug, as it's currently working as designed. This is a feature request.
If this is a feature it's a VERY BAD feature.
I have been warned to avoid countless people who are apparent texture UUID stealers. I don't think it's right that I spend HOURS working on sets of textures to sell my products, only to have them ripped by some person who could replicate or use my textures to sell and for their own benefits. This happens A LOT and IS a big deal. To me, this is stealing copyrighted material, and could be grounds to sue or ban if a person should and COULD go far overboard with this "feature." Might as well stick copyrights on everything you make now, people, or exploits like these will have you losing money with no way to stop it. if people are just able to steal our hard work that we have to pay to upload.... why should we have to pay for it when someone is just gonna steal it for free..
you fix the ability to freely grab a uuid you stop one of the proccess of a copy bot.... so it seems like if you guys fully fix this then you also eliminating half of the copybot situation... 1 1/2 birds with one stone.... Many of you are obviously not reading what the linden's are trying to tell you, just don't care, or don't understand.
Unless you want to not show the image to the viewer, people will ALWAYS be able to figure out how to grab/copy that image. UUID or otherwise there is no secure method to display an image to a computer and still stop that computer from making a copy that isn't 'protected'. (....without having software to restrict with the person can do with his/her computer, think music, Sony tried to give us a CD that we could listen to on our computer, but not copy the music we were hearing. You can't do that just like you can't stop an image from being copied. They instead installed secret software on people's computers to block them from being able to copy the music, because if you don't tell people about it, they won't know to disable it. Problem here lies that this is what Trojan's and Virus's and also breaks several laws. ) So while they could waste their time changing the uuid system to protect the images downloaded (which has already been done a few times they just don't go announcing it) the people who want the images will always break such fixes. Hope this helps clear up any delusions that this problem can somehow be 'solved', it can't. @ drew " Unless you want to not show the image to the viewer, people will ALWAYS be able to figure out how to grab/copy that image."
This is not true. People will not ALWAYS be able to figure out the more difficult way. Many people aren't smart enough or determined to do so. Many people give up if it gets too difficult. The more difficult it is the less people will succeed so the amount of actual rips will be lower. 80-20% decrease in rippers is always better than the 0% decrease we will get for doing nothing. I am tired of the negative people saying "hey it always can be stolen some harder way so lets do nothing and just give up and leave tthings like they are" What would happen if the car-business would think this way? It should be the same way for textures, everything that can be done to make it harder, should be done! Covering up UUID's in our viewer won't ensure that third party viewers do the same. We're probably going to see competitors with right-click > Save As functionality, like web browsers. If, when that happens, content creators have spent that much longer believing that asset permissions do something that they don't, can you imagine what their reaction would be?
Ultimately: Will we protect content by relying on people to use a gimped viewer? I know this topic came up in the wake of http://blog.secondlife.com/2007/12/13/tip-of-the-week-15-how-to-get-texture-info/
and I've been pointing Residents here.
This is still an open concern to us – I've asked fellow Lindens that we investigate this further. Thanks for your continued feedback. VWR-2909 contains a solution to this. The root cause of this problem is the expectation that textures can ever have a such thing as "limited permissions".
If there was a way to anti vote for this I would, this is absolutely pointless as the texture UUID is in the open to every client anyway and even to the LL viewer there are plenty of other ways (not even including intercepting the packet stream) to get the UUID of a plain texture, not entirely sure about sculpties, and any non LL viewer will probably just ignrore this anyway and still show the UUID in the window. Torley, please don't give into the mob when it means diverting even a minute of time that can be spent on much more useful dev goals.
removing "This is a texture security bug" line from the beginning of the summary as according to Torley this isn't a bug it's a feature request to change the intended behavior.
What is it with you guys? Nothing can ever be stopped, but you can reduce the incidence and likelihood of it happening, and that helps. May not help you, but might help Granny Smith down the road.
Every effort is worth it. Think on this: corporate fraud goes on. If Jeff Skilling had not ben jailed for his Enron doings, what do you think would have happened? More people trying it? Do you think that be sending him to a Fed pen for 20 years, other people will think that could happen to me, so I won't do it? Jailing him won't stop such fraud altogether, but it sure as hell made everybody wobble, and reduce the incidence. Just why is it that Linden do not seem to "get" their own creation, and what their paying customers do with it? Think on this. Every time you decide to ignore your customers, they can't wait for the day when you are taken over, and everybody sacked, or for a decent competitor to come along, one who does take notice of their concerns. Either way you will be out of a job. Want to wait until then, or try now and address your customer's issues, some of which we have been BEGGING you to fix for over a year. At the rate you are going, and the joke that SL is becoming in the global media over exactly these issues, you'lll find yourself leaving off any reference to SL on your CV if you don't want to be on welfare for the rest of your lives. I for one can't wait until I can test out the new Google thingy, and I suspect 499,000 out of your 500,000 regulars will do the same. They certainly will have read your blog, seen the comments there, on SLX and all the other blogs, seen the media, looked on the JIRA, talked to people, and will be avoiding those "mistakes". You've had 8 out of 9 of your lives now guys. You're on your last chance. Oh, and it wasn't very helpful for Torley to point it all out on the blog. Must have been about the most serious lack of judgement by a Linden since, oh I dunno, how about the asset server fiasco of Tuesday?
Hey lookie! anybody and their momma can edit the jira entries. That really inspires confidence in the jira system! NOT.
The texture hounds and uncreative hackers don't want anything done to reduce their ability to steal intellectual property so they are going to be out in force fighting tooth and nail to stop responsibility and ethics from being thrust upon secondlife. sure a criminal can steal anything. what we want is a way to lessen the ease with which the noob criminals can freely operate in sl. maybe we need the capability to run data warehouse reports listing texture UUID use on objects not owned by the owner/initial uploader of the textures. will this stop determined scumbags from screenshotting and using tools to intercept the data? No. is it a TOS violation to use such means to acquire data? If so will Linden Research take aggressive actions against people that are found to be in possession of stolen content? this is not an easy situation. Or yes it is easy. just ignore it and watch sl wither and die because only a moron will upload intellectual property into a farcical system literally engineered to make content theft easier than buttering warm bread. Torley did not point out anything about texture ripping in the blog, it was pointed out in comments to his blog entry.
And the easy method has been around for years and SL hasn't whithered and died. You can't set up an economy based on intellectual property rights then when someone points out an easy way IP can be stolen throw up your hands and say, "Well it can all be stolen anyway." That's just
How hard would this solution be? Really? It would only actually be hypocritical if LL were the ones doing the stealing which unless Phillip has a side hobby stealing textures (I doubt it) they aren't.
It is naive though to say that just hiding one thing from the UI is going to solve texture theft, it probably will not even reduce it as anyone who already steals textures more likely than not knows other ways to get that information, the only thing that this would do would raise the barrier to entry to anyone wanting to start stealing textures and even then only slightly so it's giving a false sense of hope at best and is in my opinion an utter waste of LL's time to fix something that at least appears to be a design decision on their part. downgrading to major, there are several related issues including the ones linked in the related fields to this one all of which are rated either major or lower, This definitely meets the standard for a major issue but not really for critical.
I see people arguing that textures can be stolen even if the UUID is removed from the UI. Well, I got some news for you. Almost everything can be lifted from SL. With your logic, we may as well remove the permission system from objects too. Hey, they can be stolen anyway!
I dont think anyone here believes this request will stop texture ripping. This is not an unreasonable request. It will help reduce casual copying. We are not looking for a solution to texture ripping. If you look at the bigger picture, this also has the potential to reduce the number of DMCAs LL has to process. I completely removed the UUID display from Ctrl-Alt-Shift-T "Select Texture Info" and the title bar of the texture picker dialog. Residents can still get the texture IDs for full-perm textures they own via right-click "Copy Asset ID" in their inventory and in the texture picker.
Fixed in 1-18-6-Viewer, so you should see the code in the next release candidate. I wish I could understand the exact nexus where you folks' religious zeal for some kind of idealistic "dystopia" has is with reality.
ALL security is only enforced along a slope of difficulty. "Why mask out passwords in a text field with 's," you folks might say, "Someone could just be sniffing the line anyways.." How many steps away from that is "Why encrypt? Someone could just brute-force crack it anyways." I know, I know, greetings Professor Falken and information ***wants** to be free, and all that jazz. (Did I use enough **'s?) You CAN get into a bank with 30 tons of TNT, but MOST people won't. The basic tenet of security is that you'll never keep ALL of the dishonest people out, but you aim to keep MOST out, within reason. The argument here is akin to someone saying "Well, why lock the bank doors, when someone could just ram them in with their car?" Oh, and let me stop y'all before you go there: if you wan to niggle about shades of grey "well packet sniffing isn't the same as someone ramming a door with their car", please just save your breath. I'm not talking about how savvy YOU might be with WireShark. Seriously, good job and all that - but if LL wants to protect their content providers, they should at least take basic precautions to keep the most lazy of the lazy from unbridled infringement. I don't quite get the schizophrenic attidue where everything on the grid should be free and copyable, yet Linden seems to forget what keeps their lights on. If you guys want to do this "for the love of the code" and grow your Stallman beards out, fine - but don't expect it to keep you in pants. It won't. Web 2.0, facebook, blog vlog blogosphere synergistic social network. (That last sentence was included so all you new-new-era technologists who were in underoos when the first "new economy" disappeared in the great Flooz depression will understand.) P.P.S. You know, you don't have to take one side or the other. In my "RL" job, we use FOSS all the time where appropriate, but sometimes, somehow, nothing quite satisfies like a 10,000 enterprise user license from Computer Associates, Sun, or BEA. Well the good news on this is LL is listening to the residents.
The bad news on this is that LL is listening to the residents and trying to fix "issues" that is time better spent on real problems like stability instead of wasting their time on this. Gordon, if you don't like it then stop your whining and get out. It's people like you that fill up the LL blog with whiny negative crap, especially on positive posts by LL.
Actually it's people like me who realized that LL doesn't listen to comments much anymore on the blog posts because of all the negative whining crap so it's hardly worth bothering to write a blog comment nowadays.
And here is a prime example of why open sourcing the client was a noble failure and exactly why secondlife needs to be closed to unauthorized clients:
--------------------- Cinos Field Posted: Mon Dec 17, 2007 1:22 pm Luckily I'll be using a modded client where it's still possible. Close the grid to these mods that are used expressly for the purpose of fraud and theft. the open source freaks have enough code now to go it alone. let them go steal from one another and have a ball being unsuccessful in business and in life in general. Thanks for the continued discussion and for keeping it somewhat civil despite the differing opinions here. I know all too well that this is a heated, controversial issue, but as you now know, James Linden worked on this because we do care.
Remember that we can deter this and similar efforts (analogies of locked doors despite glass windows abound), and those are practical actions, but it's ALWAYS important to learn + comprehend why "security" here isn't so easy as simply removing UI controls – I'm aware some folks can't relate to the technical details and just want us to "FIX IT!!!!", but unrealistic abstractions and dramatic proclamations are trumped by rational community awareness and social pressure. It's always good to learn more, and reading up @ http://wiki.secondlife.com/wiki/Open_Source_Portal These sorts of discussions never end and ultimately should serve to better Second Life; so again, thanx in earnest for your interest and caring enough to comment how you feel. Hey, Ann, what web browser do you use? Does it include a popup blocker or ad blocker function? Did you know that a lot of people have been going around trying to get websites to block access to browsers that provide those capabilities?
On the other hand, the best selling products I have are the ones I sell full permission, including the source code, and tell people that they're free to pass them on to their friends... "but of course I'd prefer that they come to my store and buy them instead". And people do... that is, they come to my store and buy them, even if they don't have to. I've got a couple of people who come buy regularly to buy updates, even if they don't have to. And they come and tell me about people who are selling my stuff... and when I go talk to the folks who do that, most of them are happy to direct business my way. I can count the number of stubborn SOBs on one hand... on the thumbs of one hand. And I've got business from his ex-customers. Most people are not out to get you. Most people consider even screwing around with texture UUIDs too much trouble, let alone messing about with a third-party client. You only need the slightest incentive to keep folks happily buying your stuff. For an awful lot of people "I'd like it if you'd come buy and buy it" is plenty. I agree that information should be hidden for the normal user to show, what can be gotten legally. But as for View Admin Options, I think, it should reveal informations, that are sent by the simulators anyway, like Texture UUIDs, Sound UUIDs, Animation UUIDs, Object IDs, etc. Though, while revealing this with Admin Options, I think there should be a warning when first activating these, that usage of it can be against TOS, yet allowing to see, what is below the curtains.
For protecting of content theft, there is the community. Vigilant people using the Inspect tool from time to time to check, if the creator is really the creator and reporting people who have obvious copies. And for textures, the texture creators know, who they sold textures to, when a product uses one of these illegally there is always a chance of being caught. So this should give enough incentive to actually buy a license to use content. I admit that I know enough ways to copy content in SL, I just don't do it, because I can and I do support content creators and I prefer to support them by buying a license to use their content. I will not use/resell/profit from any copied things. If the community knows that things can be copied, they will be more careful to get the original. It's more important to have ways to check the originality and legality of content, than to just hide the fact, that it can be copied. And for the comparison with locks for a car. There is a difference between matter (real hardware) and information. All of us may want it fixed, but most people who are smart enough to post on jira will probably realise it will just help stop some rips, but not all.
I am sure most of the 54 voters on https://jira.secondlife.com/browse/SVC-676 Amonst the 54 voters are many of secondlifes big skin creators which businesses are in danger because their skins have been ripped and are beeing spread as freebies. When I see a complete newbie with an expensive skin, I usually try to figure out where they got it. I've got quite a collection of ripped skins, of which most have another creator listed than the original. I can send you a whole bunch of ripped skins and bring you in contact with many big shop owners which items have been ripped. In sl there are more and more signs in shops from creators who feel helpess fighting against copies of their stolen skins which are freebie in world and are beeing spread asking their customers to keep buying the originals. The copies spread faster than the shops words, theres no way a shop owner can compete with that. Most rips are NOT on the original creators name (they list another as the creator) and most shop owners CAN prove these skins are rips (even in court) Why isn't it possible to delete these copies so these peoples businesses aren't destroyed? Many of us would like to know which ideas are possible, which aren't and why. We feel we are beeing ignored and the issue is beeing ignored. (no linden ever replied to SVC-676) Peoples shops are in danger of beeing ruined, please help! I just cannot believe how face-palm amazingly stupid this is. It's almost as stupid as it would be to display user passwords in avatar nametags for all to see, and then rely on people's honesty for not stealing accounts...
Linden Lab can either have a totally transparent open-source geek-project, or a business driven creative community. Not both. If nothing is done to protect property, then SL's creative economy will die out sooner or later. Why buy when you can steal? People have subjective morals... I've heard the lamest excuses for theft. Wake up please. Nizzy, it seems like you are the one who needs to wake up.
CopyBot's been dead and been dead for a long while. It only worked for about 3 weeks somewhere in the 1.16/1.17 series. TestClient, which has been shipped with the libsecondlife SVN since the CopyBot days, has had the same prim export and import function that people maligned CopyBot for. The number one requested feature for Second Life since 2003 that I've heard is "Let me download my items to my harddrive so LL doesn't lose them / I don't lose them". LibSL comes through, and they're the bad guy, just because of a poor decision naming it, and a couple off-color comments in IRC from Baba. Sheesh. The @#$%ing annoying copybot killers that attempt to IM anyone with !quit are COMPLETELY flawed, because even the 'good' copybot direct from libsl DID NOT RESPOND TO OBJECTS IMing !quit, only AGENTS. Now, about this TOS arguement. If my memory isn't mistaken, doesn't the TOS grant LL a license to use and display any and all uploaded textures to ANYONE at any time? Under the following in the TOS: Notwithstanding the foregoing, you understand and agree that by submitting your Content to any area of the service, you automatically grant (and you represent and warrant that you have the right to grant) to Linden Lab: (a) a royalty-free, worldwide, fully paid-up, perpetual, irrevocable, non-exclusive right and license to 3.4 Linden Lab licenses its textures and environmental content to you for your use in creating content in-world. 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. ---------- If I'm not mistaken, with such a reciprocal license, does that not imply that we too may display and / or use any texture uploaded to the service? I've changed all fixed internally issues to Resolved: Fix pending.
Security by opacity is a delusion.
Removing this feature would not prevent pirates to steal your textures, while it would prevent you to verify that some object has been textured with your own textures. And by the way, there are much better (much more efficient) ways for a pirate to steal the textures (by using the cached files, for example)... I don't think anyone seriously believes this will stop texture theft. It's more... stopping texture theft by keyboard shortcut. I doubt most users know what to do with a UUID, but I bet a good many of them know at least one person who does, and I'm pretty most sure all of them know how to use a three-letter hotkey.
I really don't see your point about preventing verification, Henri. If it's your texture and you're not selling it, you should be able to recognize it on someone else's build (which is better verification than just UUID. If they used certain ways to steal it, the UUID would be different anyway). If you're selling it, then you really have no way of telling if it was stolen or not. How do you know they pirated it, instead of just having a friend texture their prim instead? There's really no way of telling. Or I suppose you could just steal the texture back to compare. As you said, there are far better ways, aren't there? @ McCabe
> I really don't see your point about preventing verification, Henri. If it's your texture and you're not selling it, No. I f they "stole" it by the mean of this feature, they actually merely wrote down the UUID and applied the As for "recognizing" your texture, there is no proof you did not get it from some website and that the other If a pirate steals your texture(s) from the cache, for example, they will re-upload them and then the UUID So in fact, it is best if the pirate takes the easy path and uses that feature so many people want removed, Still yelling and stamping feet over this eh? its over. they took out the imbecile's means of ip theft.
i find it interesting that the people stamping of feet and yelling loudly about this never talk as though anyone actually created textures. Ann, I feel sorry for you if your still deluding yourself into thinking that this will make an ounce of different, congratulations you removed a feature just to help deal with your paranoia and that of your panic mongering buddies.
Ann,
I've spent several hundred USD paying texture artists for custom textures before. I did this knowing fully well they can be trivially copied. If someone does, they will be prosecuted to the full extent the law allows. This is how copyright works. Not by pretending it's possible to prevent copying in the first place. " This is how copyright works. Not by pretending it's possible to prevent copying in the first place" I do not agree. In real life that is indeed the way copyrights work. However, there is no reason for limiting ourself in second life to the possibilities we have in real life. Ater all ,stealing in second life is also not limited to the possibilities that someone has in real life. In real life it is not possible just to 'copy' armani suits in 5 seconds, buy a store for 3 dollar and make money 15 minutes later with an alt that is just created on some random computer, making the stealer totally anonymous. In real life one should at least create clothes that look like armani, have the money to hire a store and get all sorts of permission before you're even allowed to open a store in a decent location, and of course get legal charges that will either cost you money or your freedom (jail). ...What are the consequences in second life? Things are very different in second life than in real life, so we should adapt our way of approaching this problem in second life as well. Of Course there is the example of the cd's that are downloadable on huge amounts of places on the net, but do you We should realise that people that steal in real life , as well as in second life, do it for a reason. They have a goal in mind.. most possibly they just want to make money, without having to spend huge amounts of time/money on creating, hiring and having the chance to fail. The reason stealing is the best option in almost every case worldwide, is just because it's the easiest way. Do you think that if stealing would take more time, money or effort than doing it the legal way, there would be so much theft? I dont think so. Ask any bankrobber why they rob a bank. Most possibly he will just do it to make alot of money in a short time. It's always the benefits against the bad side. Would there not be more theft if criminals werent send to prison for years, but had to pay 100 bucks instead? Of course there would be more theft . People compare the things they can win with stealing, to what it might loose (their money / their freedom) If ripping textures would take as much, or even more time/skill/money than creating/buying them, they will for sure have a second thought about that. So the whole point of making things harder to rip, is just to make it a LESS ATTRACTIVE ALTERNATIVE after all, most people do not rip for the fun of ripping on its own, but because it seems such an attractive option.... Removing this was a complete waste of time, and the removal of a legitimate feature for anyone who works on group builds, not to mention anyone who wants to steal a texture will just google GLINTERCEPT and be able to download .tga files right to their hard drive...
Once again ignorance, paranoia and confusion have won out over the very simple facts of the matter. The removal of this feature is just that.. one less potentially useful feature in the official SL client. Though the TOS snippet of section 3.2-3.4 is rather insightful.
Alot of people also seem to overlook that both the UUID and corresponding texture are stored locally in the cache\textures directory. Browsing the raw cache data doesn't create lag like an OpenGL debugger and as far as I can tell this "Environmental Content" is free to reuse and/or reupload in world as long as you have an active SL account. I think Phoenix's reply is quite eloquent - after all do you really expect LL to admit / explain / justify how they've tried to create a secure business model on top of a bizarre amalgamation of open source protocols? The only security that exists in SL is obscurity.. and mass confusion. Anyways, now that the official client code is open source it's a safe bet it'll be a matter of days before there's an add-on that restores this functionality within the client. So... Has anyone created a jira issue for bringing this feature BACK yet?
One thing I noticed though, is that the group that's most vocal against theft and such is the skin creators – content on which this method doesn't work at all. I'm not going to assume anything. I just think this is interesting. EDIT: Also, this feature was useful for those of us with no-copy but moddable objects, for example if we wanted to re-texture one such object, and then go back to its original texture for whatever reason. This feature is useless, it only creates new problem and don't help out preventing anything. (Yes, Ann i have mane loot's of textures) However I see The viewer in the same way as i see a web browser, people can without problem steal the images I have on websites. I can't prevent that, seeing the UUID help me looking at objects, not often but at least once, I by mistake change the wrong texture (when uploading and making textures from a friend), i made My stuff to the wrong item. But help of this feature it was possible to restore the item back to the original looks, without using some other mean, cache, glintercept and upload a copy of the original texture again.
And why isn't there a vote against feature in the JIRA. Then issue http://jira.secondlife.com/browse/VWR-5030
is created to get the stuff back.
I would say there is very little difference between seeing it as a bug when the stuff you used stops working even if that was a deliberate change or not, making that distinction is may I use the word childish. The 4050 was files because the stuff didn't work and it was lined from HERE by the creator of that issue, definitely aware that this JIRA had been implemented. Keep this feature implemented, even though there are workarounds.
DO NOT UNDO THIS! It's at least a tiny step towards stopping theft. Now we need to see some more serious steps, maybe starting with storing checksums and calculations based on the first pixels in textures, and comparisons when people are uploading textures to trigger further investigations - or a full compare which could prevent upload or alert someone. It's true that theres nothing you can do as textures exist on clients, so the simple solution is do thing on the server. Come on LL .... help content creators get some peace-of-mind that you are looking to help them. This is "fixed" in the current release now, so I'm resolving it fixed.
All of this back and forth looks like a missed opportunity on both sides.
1. The protocol needs the UUID in order to work. A UUID is just a number. Knowing or asking for the number isn't the problem. 2. Textures are artwork. Someone makes it and the original exists on their hard drive. 3. The key to the problem is grinding out the reprint on demand. 4. LL could implement the following: The TEXTURE PROPERTIES dialog should give the uploader the same controls, so they can revoke these rights at any time, UNLESS the texture has reverted to royalty, or was marked royalty-free to begin with. The TEXTURE TABLE in the database would need the addition of several fields per texture, including # of uses remaining until next royalty payment. The permission checker that decides if you can work on object is extended to check the UUID of the requester is then extended to check the texture permissions. This won't stop a determined thief, but it will let people already fighting rippers have a tool to get back some controls, a create a revenue stream to reward texture artists, based on the real-world reprints and photographic royalty model. Just some ideas from off in left field. edit too bad its buried here at the end of a "closed as fixed" issue |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Remove texture UUID information from UI unless full-perm
use, reproduce and distribute your Content within the Service as permitted by you through your interactions on the Service, and (ii) use and reproduce (and to authorize third parties to use and reproduce) any of your Content in any or all media for marketing and/or promotional purposes in connection with the Service, provided that in the event that your Content appears publicly in material under the control of Linden Lab, and you provide written notice to Linden Lab of your desire to discontinue the distribution of such Content in such material (with sufficient specificity to allow Linden Lab, in its sole discretion, to identify the relevant Content and materials), Linden Lab will make commercially reasonable efforts to cease its distribution of such Content following the receipt of such notice, although Linden Lab cannot provide any assurances regarding materials produced or distributed prior to the receipt of such notice; (b) the perpetual and irrevocable right to delete any or all of your Content from Linden Lab's servers and from the Service, whether intentionally or unintentionally, and for any reason or no reason, without any liability of any kind to you or any other party; and (c) a royalty-free, fully paid-up, perpetual, irrevocable, non-exclusive right and license to copy, analyze and use any of your Content as Linden Lab may deem necessary or desirable for purposes of debugging, testing and/or