SLURLs bypass @sendchannel restriction
Issue #159
new
SLURLs of the form secondlife:///app/chat/<channel>/text are useable even when @sendchannel is restricted and <channel> is not excepted.
Comments (7)
-
-
reporter
It’s a tad niche, but here’s an example. Suppose I’m wearing some RR cuffs locked with self-touch and channels restricted. It’s generally assumed that should be sufficient to prevent me from accessing the menu to play the struggling mini-game and escape. however, if I can say secondlife:///app/chat/77/wrist then I can click the link and get the menu. But even worse, suppose I were gagged. If I had the forethought to say all the relevant links to an alt in IM, I can open my conversation log, search for the conversation and click the link from there.
I tested with an old version of firestorm and it didn’t seem to have the same issue.
(and yes, kokua has the issue. I might have reported to you but then you’d probably just tell me to complain upstream
)
-
You’re absolutely right - the correct approach is to record and fix it at the origin and then cascade the fix down to viewers like Kokua that use the same code. That said, this is one of those situations where I’ll probably investigate it and contribute the fix to Marine’s codebase as well as applying it in Kokua directly.
-
Which version and which platform are you using? I’m not able to reproduce it on WIndows with Kokua 6.5.3 or the latest RLV - by not reproduce, I’m meaning I don’t get a menu using the technique described
-
Managed to reproduce it now… on Kokua it needs a right click and ‘run this command’
-
Fixed - Pull Request sent
-
reporter
That certain SLURLs need a right-click 'run this command' or else they bring up a short notice about an 'untrusted source' has bothered me for a bit, but not enough to report it.
- Log in to comment
@Quistessa can you give an example of how that’s (ab)used? I’m curious whether I’ve got the same issue in Kokua (probably)