[#SVC-3247] Allow content just to be viewed by trusted SL-compatible clients

2. Second Life Service - SVC

Allow content just to be viewed by trusted SL-compatible clients

Created: 16/Oct/08 05:53 AM Updated: 18/Oct/08 07:24 AM

Return to search

Component/s:

Permissions

Affects Version/s:

None

Fix Version/s:

None

Issue Links:

Relates

This issue Relates to:

MISC-1213 Label Bots, Enable Land Menu to Ban Them, and Allow for Use Only by Premium Accounts

Description

« Hide

1) Change the SL grid login process to include an exchange of digitally signed credentials. Trusted SL clients would present a valid certificate to LL's login servers, one that is deeply tied to a specific version of the client (e.g. a checksum). Avatars logging in to the LL grid would have their session being flagged as "coming from a trusted viewer".

2) Establish a Certificate Authority For Trusted Developers. This would allow the emission of digital signatures, based on a submitted SL client (to extract the checksum). Trusted Developers, to access the certification programme, would have to provide LL with validated data about themselves and agree to abide by a special set of ethical rules.

Developers suddenly found to be violating the rules would have their certificates immediately revoked, thus instantly preventing people to use their tools to download content illegitimately.

3) Parcels would be able to be flagged to "allow content in this parcel to be viewed by trusted SL clients only". Avatars using an untrusted client would never see any content there (no prims + textures would be streamed from the sim to the client). This is similar — but not exactly like — muted content, but done server-side to prevent untrusted SL clients to be able to illegitimately copy content.

All parcels would by default have this flag checked.

4) Assets — from prims to textures, animations, sounds, etc. — would also have a flag "allow only to be rezzed on parcels allowing trusted SL clients". Rezzing them on parcels allowing untrusted content would fail as if the avatar didn't have permissions to rez an object on the parcel.

All existing content would gave by default this flag checked (it does not deal with already pirated content, but future content would not be easily copied).

This does not prevent two things from happening:

'bots to be used for legitimate purposes (doing what LSL doesn't allow: invitations to groups, sending group notices, retrieving statistics from sims, allowing scripts to work that always require the script owner to be rezzed in-world, etc.)
legitimate copies/backup of content by content creators wishing content to be transferred to other grids (they would just uncheck the flags, get it backed up, and check the flags again)

3 requires some programming effort; 4, however, should be just a single "if(avatar requesting asset is flagged as coming from a trusted client) then send avatar list of available assets to request streaming". It's the work of a few minutes (before QA tests of course). Just implementing 4 without 3 is a good compromise to seriously reduce the opportunities of illegitimate content copy.

Description

The ultimate purpose is to allow content on the SL grid to be viewed only by "trusted clients" that have complied with a set of developer guidelines, in particular, disallowing the easy copy of content without permission. 1) Change the SL grid login process to include an exchange of digitally signed credentials. Trusted SL clients would present a valid certificate to LL's login servers, one that is deeply tied to a specific version of the client (e.g. a checksum). Avatars logging in to the LL grid would have their session being flagged as "coming from a trusted viewer". 2) Establish a Certificate Authority For Trusted Developers. This would allow the emission of digital signatures, based on a submitted SL client (to extract the checksum). Trusted Developers, to access the certification programme, would have to provide LL with validated data about themselves and agree to abide by a special set of ethical rules. Developers suddenly found to be violating the rules would have their certificates immediately revoked, thus instantly preventing people to use their tools to download content illegitimately. 3) Parcels would be able to be flagged to "allow content in this parcel to be viewed by trusted SL clients only". Avatars using an untrusted client would never see any content there (no prims + textures would be streamed from the sim to the client). This is similar — but not exactly like — muted content, but done server-side to prevent untrusted SL clients to be able to illegitimately copy content. All parcels would by default have this flag checked. 4) Assets — from prims to textures, animations, sounds, etc. — would also have a flag "allow only to be rezzed on parcels allowing trusted SL clients". Rezzing them on parcels allowing untrusted content would fail as if the avatar didn't have permissions to rez an object on the parcel. All existing content would gave by default this flag checked (it does not deal with already pirated content, but future content would not be easily copied). This does not prevent two things from happening:

'bots to be used for legitimate purposes (doing what LSL doesn't allow: invitations to groups, sending group notices, retrieving statistics from sims, allowing scripts to work that always require the script owner to be rezzed in-world, etc.)
legitimate copies/backup of content by content creators wishing content to be transferred to other grids (they would just uncheck the flags, get it backed up, and check the flags again)

Steps 1 and 2 are quite easy to implement; 1 is supported by libcURL directly, and there are plenty of open source applications to set up a certification authority quite easily (using standard SSL certificates). Algorithms for establishing checksums on a submitted file are also pretty standard. 3 requires some programming effort; 4, however, should be just a single "if(avatar requesting asset is flagged as coming from a trusted client) then send avatar list of available assets to request streaming". It's the work of a few minutes (before QA tests of course). Just implementing 4 without 3 is a good compromise to seriously reduce the opportunities of illegitimate content copy.

Show »

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Gwyneth Llewelyn added a comment - 16/Oct/08 05:59 AM

MISC-1213 does not define procedures on how bots can be effectively "flagged" as such (a bot is just an avatar logged in from a client). ~~SVC-3247~~ proposes a methodology to allow flagging of "trusted SL clients" (viewers or other applications) by providing a registration service for "trusted developers" and a certification authority handing out digital cetrtificates; and one description of a possible in-world implementation. The focus of ~~SVC-3247~~ is, however, on restricting illegitimate content copy and less about 'bots roaming the grid for legitimate purposes (although the mechanisms to keep illegitimate 'bots away from parcels would also work for MISC-1213)

[ Permlink | « Hide ]

Chalice Yao added a comment - 16/Oct/08 06:41 AM

Here's a WWW analogy:

Websites can be flagged to only play sounds, javascript and show images to certified clients
Every developer who makes any kind of html library, tiny client or coded http interface need to get a certificate to get to show all content.
Tied to the checksum, so on a good development day, the certificate needs to be renewed 20+ times to fully test the developed application.
Since the browsers, http libs etc. do their evil things client-side and are not detectable on the www server, a big set of employees need to review the regular source code changes ever so often.
Thieves, especially those who could write their own browser, use Netscape and just go through the cache to get the things.

Sorry, but while it's certainly an interesting start, LL barely is able to do audits on their own viewer with their manpower. Pair that with the need to renew the certificate over and over and over during a small development session to full test things, and I personally think this might become more than just a little taxing for all parties involved, with only a small benefit in the end.

[ Permlink | « Hide ]

Gwyneth Llewelyn added a comment - 16/Oct/08 07:21 AM

I might politely disagree on the "taxing" vs. "small benefit".

For a development phase there is certainly absolutely no need to get 20+ certificates per minute or so. In fact, the whole point of being able to flag parcels to allow untrusted clients is to be able to develop and test pretty quickly if everything is working without going through the mess of getting a certificate. This is not unlike, say, using the Preview Grid to upload millions of textures and animations until you get them "just right", then going back to the main grid, and uploading the texture/animation just once.

Similarly, testing during a development cycle could be done without a valid certificate for a long period, using the parcels allowing that, and only after making sure things work flawlessly, they could go through the submission process. One that is, in my mind, fully automated — so, no, the proposal is not for having LL validate the code of each and every application, but just allow swift action if someone complains about a tool violating the "ethical code of use". This is pretty much what Apple & Microsoft do with their own developers as well; no, they don't check code (code is not even submitted!) for each and every application that gets developed by trusted developers. They just have a way to revoke certificates swiftly if one of those developers suddenly misbehaves.

Thieves can copy textures from the cache, but not prims And that's just because LL allows the cache to be so easily read. Granted, the more complex the cache is, the less funcional it becomes (after all it's about quick recovery of files from there), but there are certainly ways to develop a better cache which is harder (but not impossible) to decrypt. I'm pretty sure, though, that this is also way low on LL's priorities.

[ Permlink | « Hide ]

Zwagoth Klaar added a comment - 16/Oct/08 10:46 AM

Let me point out that the SL viewer is an open source project. This alone makes it almost impossible for any type of cache obfuscation or encryption to have any purpose at all. A cache is there to attribute quick retrieval of data without having to ask the server for it a repeated number of times, never to hide data from view.

Side effects of this:
• All current third party viewers of any type no longer may access ANY in world content.
• All previous versions of the viewer may no longer function for any purpose.
• LL must review the clients that can be allowed to connect to their platform, binary or not, it takes manpower and lots of work.
• LL takes responsibility for every tool it accepts, if a hidden feature of one is slipped past and copies content, LL is blamed for it because they approved it. They are not going to go for that.
• LL must rewrite core logic within the simulator code, both adding parcel flags to an already full flag field, as well as adding still more flags to each instance of a viewer.

Things to note:
• Microsoft developer program never prevents the execution or distribution of anything, it simply means it cannot carry the "Approved by Microsoft" label.
• Thieves can read source code and write their own tools, if they couldn't, they wouldn't exist.
• Any data streamed over a computer or pushed to screen is readable by any code on the computer, regardless of encryption or otherwise. If you can see it, it can be recovered.
• GLIntercept will recover any texture currently sitting on the video cards memory, you may try it if you do not believe it true, you cannot prevent this, third party viewer or not. Even a trusted viewer could be used alongside this tool.
• GLIntercept is open source, you can use any of the methods inside it to write your own texture or prim thieving tools.
• Prims ARE cached. If you don't believe me you may wish to look in the cache folder for files that end with .slc. They contain every prim within a specific region. This is a HUGE performance gain, it also makes viewing SL over a slow connection possible.
• You mention backup of legitimate material. Thats so very much off topic from this proposal. I would advise you to focus it more upon a single item, it is far more likely to be approved.
• There are several thousand sub projects that connect to SL, they span many languages and connection mediums. An automated test enviornment is both impossible as it is infeasible. Automated tests cannot account for unknown items without very advanced logic.
• LL does not even have an automated test for their own client, all bugs are reviewed and worked out by hand, as all of them should be. A long standing QA process is used.
• I laughed really really hard.

[ Show » ]

Zwagoth Klaar added a comment - 16/Oct/08 10:46 AM Let me point out that the SL viewer is an open source project. This alone makes it almost impossible for any type of cache obfuscation or encryption to have any purpose at all. A cache is there to attribute quick retrieval of data without having to ask the server for it a repeated number of times, never to hide data from view. Side effects of this: • All current third party viewers of any type no longer may access ANY in world content. • All previous versions of the viewer may no longer function for any purpose. • LL must review the clients that can be allowed to connect to their platform, binary or not, it takes manpower and lots of work. • LL takes responsibility for every tool it accepts, if a hidden feature of one is slipped past and copies content, LL is blamed for it because they approved it. They are not going to go for that. • LL must rewrite core logic within the simulator code, both adding parcel flags to an already full flag field, as well as adding still more flags to each instance of a viewer. Things to note: • Microsoft developer program never prevents the execution or distribution of anything, it simply means it cannot carry the "Approved by Microsoft" label. • Thieves can read source code and write their own tools, if they couldn't, they wouldn't exist. • Any data streamed over a computer or pushed to screen is readable by any code on the computer, regardless of encryption or otherwise. If you can see it, it can be recovered. • GLIntercept will recover any texture currently sitting on the video cards memory, you may try it if you do not believe it true, you cannot prevent this, third party viewer or not. Even a trusted viewer could be used alongside this tool. • GLIntercept is open source, you can use any of the methods inside it to write your own texture or prim thieving tools. • Prims ARE cached. If you don't believe me you may wish to look in the cache folder for files that end with .slc. They contain every prim within a specific region. This is a HUGE performance gain, it also makes viewing SL over a slow connection possible. • You mention backup of legitimate material. Thats so very much off topic from this proposal. I would advise you to focus it more upon a single item, it is far more likely to be approved. • There are several thousand sub projects that connect to SL, they span many languages and connection mediums. An automated test enviornment is both impossible as it is infeasible. Automated tests cannot account for unknown items without very advanced logic. • LL does not even have an automated test for their own client, all bugs are reviewed and worked out by hand, as all of them should be. A long standing QA process is used. • I laughed really really hard.

[ Permlink | « Hide ]

Thomas Shikami added a comment - 17/Oct/08 04:00 PM - edited

and to add my stuff to what Zwagoth said above,

any executable, however it is encrypted or protected, can be analysed to create a client that fakes a successful authentication to look like an officially approved client. It's just a matter of how much effort is put into it and there seems to be no upper limit for famous projects.
So, your step 1 isn't even difficult to implement, but impossible technically.

[ Permlink | « Hide ]

Gwyneth Llewelyn added a comment - 18/Oct/08 07:24 AM

After some thoughts (expressed here: http://gwynethllewelyn.net/2008/10/18/stepping-back-from-the-analogue-hole/) I've decided to withdraw the suggestion.