[sldev] 3rd party viewer policy post on blogs.secondlife.com

[Tigro Spottystripes]

Oh, and use a Question/Reply thing like how they do it with GSM chips to
avoid a repetition attack

Tigro Spottystripes escreveu:
> How about somthing lke this, people who LL trust to make good viewers
> get a  key to sign their binaries, the source code as it has been
> pointed out already is tooo pliable to be trusted. Viewers that got the
> LL signature are viewers that were copiled into binary by people LL trusts.
>
>
> This wouldn't make any difference in regards to avoiding malicious
> viewers illegally reproducing data, but it would serve to help users
> avoid malicious binaries that would harm them.
>
>
> There should be a simple way to check if the binary is signed with an
> authroized LL key that hasn't been revoked yet, so people would easilly
> verify the authenticity of whatever viewer they download.
>
>
> The exact requirements to receive a LL key should be discussed
> separately, this proposal is just about the underlying system for the
> "registry of LL trusted viewers" thing
>
> The actual grid servers wouldn't need to know anything about this, it's
> just about keeping the user safe when choosing viewers. But the servers
> might be involved in the verification proccess, as well as being made
> aware of the status of viewers, so for example, people could only allow
> LL signed viewers on their sim, or even an additional bit of data for
> assets that tells the server to only send that asset to LL signed viewers.
>
>
> Of course we can't expect all the people LL trusts with keys to forever
> manage to maintain them secret,  so keys can be revoked, and with
> specific keys for each trusted developers, simply don't send a new key
> to the developer that leaked their key when renewing keys after the
> revocation (with a decent legal system so people can resort in case they
> believe they've been unfairly accused of not being trustworthy)
>
>
>
> Since this isn't somthing that needs to happen in real time and stuff,
> use a key size so big that not even quantum computers can break with
> bruteforce before the heat death of the universe
> .
>
>
> Of course there is still the issue of something external to the viewer
> running in paralell, or with a man-inthe-middle attack snatching the
> data that was server tot he trusted viewer, there isn't a solution for
> that, we don't need to think about it. It's like that saying "You can do
> somthing about it? Then there is no point worrying.You cannot do
> anything about it? Then there is no point worrying" (I can't rememebr
> the exact words, but that's the general idea)
>