My friends, we can read any notecard we want, and LL won't stop us! :)

[Domchi Underwood]

Hi everybody.

Please take a look at: http://jira.secondlife.com/browse/SVC-4972

Basically, it's about llGetNotecardLine() not implementing SL permission system - even if a notecard is no-copy and you can't read it, with LSL you can. Is this a security issue which should be fixed, or one of these lot-of-content-depends-on-it-so-set-it-in-stone-and-never-change things?

And additional question for all of you: are there other LSL functions which ignore permissions?

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Dale Innis]

Ummm... How does your proposed solution not break the exact use-case
that you give in the JIRA?  The current behavior doesn't actually
violate the permissions, since you aren't modifying it or copying it.
If you make the object no-mod, then they can't drop in a script that
will read out the contents for them, and you're done, eh?

To your other question, I can't think of any other similar examples,
but it wouldn't surprise me if there were some.  (What exactly does
"no-mod" mean for, for instance, an animation?)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Sasun Steinbeck]

I left a comment in the jira. This is an extremely bad idea. Proposing any kind of change (like this) that would obviously break such an enormous number of existing products is an exercise in futility.

On Oct 27, 2009 6:50pm, Dale Innis <daleinnisemail@...> wrote:

> Ummm... How does your proposed solution not break the exact use-case
>
>
> that you give in the JIRA?  The current behavior doesn't actually
>
>
> violate the permissions, since you aren't modifying it or copying it.
>
>
> If you make the object no-mod, then they can't drop in a script that
>
>
> will read out the contents for them, and you're done, eh?
>
>
>
>
>
> To your other question, I can't think of any other similar examples,
>
>
> but it wouldn't surprise me if there were some.  (What exactly does
>
>
> "no-mod" mean for, for instance, an animation?)
>
>
> _______________________________________________
>
>
> Click here to unsubscribe or manage your list subscription:
>
>
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
>
>

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Oct 28, 2009 at 2:50 AM, Dale Innis <daleinnisemail@...> wrote:

Ummm... How does your proposed solution not break the exact use-case
that you give in the JIRA?  The current behavior doesn't actually
violate the permissions, since you aren't modifying it or copying it.
If you make the object no-mod, then they can't drop in a script that
will read out the contents for them, and you're done, eh?

I'm proposing that script should still be able to read notecard if both script and notecard creators are the same person, so the only use case that would stop working is when script from one avatar reads no-copy notecard created by another avatar, which I suspect is not all that common.

Making object no-mod would be a nice workaround, but as I said, I know there are workarounds, that's not my point. My point is that this does kind of make no-copy permission on notecards and current client behaviour misleading, and I believe that existence of workaround is not a reason to avoid fixing things. LSL already reminds me too much of Internet Explorer 6 of the virtual worlds, which is the example what you get if you don't fix things on the basis that there is too much content which assumes relies on the bugs in the platform.

You're correct though that  current behavior doesn't technically break the permissions, and that's a valid point. But the client works on the same premise when it hides the content of the notecard when it's opened from inventory - it doesn't just disable copying, it actually hides the content. Once user sees the text, it's pretty easy to copy it, be it from notecard window or from communicate window after it's been read by the script, so it seems to me that it's OK to never transmit no-copy notecard text to SL clients.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Dale Innis]

On Wed, Oct 28, 2009 at 5:36 AM, Domchi Underwood
<domchi.underwood@...> wrote:
>
> I'm proposing that script should still be able to read notecard if both
> script and notecard creators are the same person, so the only use case that
> would stop working is when script from one avatar reads no-copy notecard
> created by another avatar, which I suspect is not all that common.

Well hm, that would be extremely weird.  Or at least would be a
feature that is in no other part of the permissions system; nowhere
else does it care who the creator of a thing is when checking for the
authorization of an action.  And all I have to do is get hold of a
copy/mod script created by you somewhere, and all of your secret
notecards go back to being insecure again (because I can modify it to
produce a notecard-revealing script with you as creator).

I agree the SL permissions system, including the LSL aspects, have
some hacks and weirdnesses in them.  But this change would seem to me
to make it more kludgy and complex, rather than less...
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Oct 28, 2009 at 2:35 PM, Dale Innis <daleinnisemail@...> wrote:

> I'm proposing that script should still be able to read notecard if both
> script and notecard creators are the same person, so the only use case that
> would stop working is when script from one avatar reads no-copy notecard
> created by another avatar, which I suspect is not all that common.

Well hm, that would be extremely weird.  Or at least would be a
feature that is in no other part of the permissions system; nowhere
else does it care who the creator of a thing is when checking for the
authorization of an action.  And all I have to do is get hold of a
copy/mod script created by you somewhere, and all of your secret
notecards go back to being insecure again (because I can modify it to
produce a notecard-revealing script with you as creator). 

Yes, you're correct, but you can do a lot of damage to anyone whose full-perm script you have anyway. Even full-perm notecard can do a lot of damage, as Gwyneth Llewelyn found out recently.

But wouldn't it allow scripters to use no-copy notecards as a way to store data that owners can't see, as opposed to another script which burdens the sim?

Because that's the case I'm defending; apart from scripter's use, it seems that noone can think of a valid use case for no-copy notecards. But as a scripter, I can use notecard to store configuration, or localization data...  For example, think of a classic adventure game - you have to find a key to open a door... so use no-copy notecard which you can drop in the door to open it, and which optionally returns you the notecard afterwards. You can even give the key to other player. I could use a script for the same purpose, but why not notecard which consumes less resources?

I can think of a number of uses for no-copy notecards, but a lot of them fail if user can "crack" the notecard. If I don't distribute any full-perm scripts, I'm safe, but currently, I can't do anything to prevent user from reading my no-copy notecards.

If there is no interest among the scripters for this, than maybe the other alternative in my JIRA entry is in order - disabling "no-copy" checkbox for notecards altogether.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Dale Innis]

On Wed, Oct 28, 2009 at 10:41 AM, Domchi Underwood
<domchi.underwood@...> wrote:
> ...
> But wouldn't it allow scripters to use no-copy notecards as a way to store
> data that owners can't see, as opposed to another script which burdens the
> sim?

I'm not at all sure that a bunch of llGetNotecardLine calls is cheaper
than having a storage script that one talks to via link messages.
Someone would have to do an evaluation.

> If there is no interest among the scripters for this, than maybe the other
> alternative in my JIRA entry is in order - disabling "no-copy" checkbox for
> notecards altogether.

No, I think it's still useful to have no-copy notecards in no-mod
objects, at the very least.  Then the scripts in the object can read
them, but the user can't.  Seems like a significant use-case.

Maybe you should be asking for an additional property of a notecard,
called 'readable only by scripts with the same creator'?  Rather than
changing the existing functions...
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Harold Brown]

If this is changed to how you propose, same creator required for script / no-copy notecard.  It will impact every script that reads a user provided notecard.  Vendors, Doors, Security systems, Xcite Partner scripts, etc. etc.

Honestly I'm kinda shocked people saw notecards as a "Secure" storage medium in the first place.  I've known for about 2 years you could read a No-Copy / No-Mod script with LSL to get the content.  Any "confidential" information required for my scripts is compiled in the LSL itself.

On Wed, Oct 28, 2009 at 8:30 AM, Dale Innis <daleinnisemail@...> wrote:

On Wed, Oct 28, 2009 at 10:41 AM, Domchi Underwood

<domchi.underwood@...> wrote:

> ...

> But wouldn't it allow scripters to use no-copy notecards as a way to store
> data that owners can't see, as opposed to another script which burdens the
> sim?

I'm not at all sure that a bunch of llGetNotecardLine calls is cheaper
than having a storage script that one talks to via link messages.
Someone would have to do an evaluation.

> If there is no interest among the scripters for this, than maybe the other
> alternative in my JIRA entry is in order - disabling "no-copy" checkbox for
> notecards altogether.

No, I think it's still useful to have no-copy notecards in no-mod
objects, at the very least.  Then the scripts in the object can read
them, but the user can't.  Seems like a significant use-case.

Maybe you should be asking for an additional property of a notecard,
called 'readable only by scripts with the same creator'?  Rather than
changing the existing functions...

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Oct 28, 2009 at 4:30 PM, Dale Innis <daleinnisemail@...> wrote:

> But wouldn't it allow scripters to use no-copy notecards as a way to store
> data that owners can't see, as opposed to another script which burdens the
> sim?

I'm not at all sure that a bunch of llGetNotecardLine calls is cheaper
than having a storage script that one talks to via link messages.
Someone would have to do an evaluation.

Well, for starters, notecards don't have heap and stack and it should mean one less script running in the sim... hard to generalize though, as always.

> If there is no interest among the scripters for this, than maybe the other
> alternative in my JIRA entry is in order - disabling "no-copy" checkbox for
> notecards altogether.

No, I think it's still useful to have no-copy notecards in no-mod
objects, at the very least.  Then the scripts in the object can read
them, but the user can't.  Seems like a significant use-case.

I agree. 

 

Maybe you should be asking for an additional property of a notecard,
called 'readable only by scripts with the same creator'?  Rather than
changing the existing functions...

Hm. I guess I'm simply having problems wrapping my head around the fact that no-copy notecard behave inconsistently depending who handles them - script or the user. In my opinion, that inconsistent behavior is a security flaw, even if there is no simple way to fix it.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Oct 28, 2009 at 5:19 PM, Harold Brown <labrat.hb@...> wrote:

If this is changed to how you propose, same creator required for script / no-copy notecard.  It will impact every script that reads a user provided notecard.  Vendors, Doors, Security systems, Xcite Partner scripts, etc. etc.

I didn't suggest that same creator is required. This is my original suggestion:

• Does owner have copy permission for the notecard? If yes, allow read.
• Are script and notecard creators the same person? If yes, allow read.
• Otherwise, deny read request.

Besides, all the products you mention use copy notecards instead of no-copy.

 

Honestly I'm kinda shocked people saw notecards as a "Secure" storage medium in the first place.  I've known for about 2 years you could read a No-Copy / No-Mod script with LSL to get the content.  Any "confidential" information required for my scripts is compiled in the LSL itself.

If I can't open no-copy notecard through viewer, I would expect that I won't be able to read it through my own LSL script as well. The current behavior wasn't intuitive to me, but luckily I tested it before actually creating a product which relies on it.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters