Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-40755] Allow unblocking of "Untrusted Browsers" when certain links are clicked such as app/chat #12386

Closed
2 tasks
sl-service-account opened this issue Oct 23, 2016 · 5 comments
Closed
2 tasks

[BUG-40755] Allow unblocking of "Untrusted Browsers" when certain links are clicked such as app/chat #12386

sl-service-account opened this issue Oct 23, 2016 · 5 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 23, 2016 •
edited by sl-issues-importer bot

How would you like the feature to work?

Clicking such link in chat such as secondlife:///app/chat/1/0 gives the should give a warning message box "[Second Life: A SLurl was received from an untrusted browser and has been blocked for your security.] If you would like to unblock these SL URLS please goto the "web tab" and un-check the links type you would like to un block. "
Link Types would be these listed here:
http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space

Why is this feature important to you? How would it benefit the community?

This feature was always beneficial allowing more easy to use content. I personally use them in menus systems which are at time better when listed in chat verses using the built in menus system which can be very clumsy to use when there are large amount of data. My best selling product has been crippled by blocking this feature. It would have been better to look for a non breaking solution to warn people and educate them instead of just killing it. Giving them a warning with the option to un-block it.

Personally I can't figure a way to use app chat to grief. It never worked on zero channel. Therefore the only thing would be scripts could see it. I find many 3rd party viewer still support it.

Links

Related

Original Jira Fields
Field Value
Issue BUG-40755
Summary Allow unblocking of "Untrusted Browsers" when certain links are clicked such as app/chat
Type New Feature Request
Priority Unset
Status Closed
Resolution Unactionable
Reporter Gearsawe Stonecutter (gearsawe.stonecutter)
Created at 2016-10-23T03:35:16Z
Updated at 2016-10-26T18:28:46Z 
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-10-23T02:24:27.665-0500',
  'How would you like the feature to work?': 'Clicking such link in chat such as secondlife:///app/chat/1/0 gives the should give a warning message box "[Second Life: A SLurl was received from an untrusted browser and has been blocked for your security.] If you would like to unblock these SL URLS please goto the "web tab" and un-check the links type you would like to un block. "\r\nLink Types would be these listed here:\r\nhttp://wiki.secondlife.com/wiki/Viewer_URI_Name_Space',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': "This feature was always beneficial allowing more easy to use content. I personally use them in menus systems which are at time better when listed in chat verses using the built in menus system which can be very clumsy to use when there are large amount of data. My best selling product has been crippled by blocking this feature. It would have been better to look for a non breaking solution to warn people and educate them instead of just killing it. Giving them a warning with the option to un-block it.\r\n\r\nPersonally I can't figure a way to use app chat to grief. It never worked on zero channel. Therefore the only thing would be scripts could see it. I find many 3rd party viewer still support it.",
}
@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-10-23T07:24:28Z

Firestorm viewer still supports app/chat links.
When the MAINT-535 changes were merged into Firestorm, it was decided to still allow app/chat because removing it broke too much content.
Ref: http://jira.phoenixviewer.com/browse/FIRE-13437

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-10-23T07:29:05Z, updated at 2016-10-23T07:30:35Z

Note Soft's comment on BUG-5702

Soft Linden added a comment - 17/Apr/14 8:09 PM

The chat method has historically been abused in dangerous and embarrassing ways. If this there's a compelling case for bringing it back, it should display a confirmation dialog before each use advising a user of what is about to happen. That dialog could be suppressible ("never show again") but it should be enabled by default so that only users who opt out of protection are affected adversely.

In the example of the HUD above, what's the benefit to having the HUD make the user act as a proxy? It sounds like a really unusual design. Usually a script like this would communicate directly with the target object. If there's concern about impersonation, a script can still display a confirmation dialog. A confirmation dialog introduces no more steps than having the user click a link in chat. If the author of the HUD script is trusted, the communication protocol can include a hash to sign the message and prevent third parties from issuing it, eliminating the additional confirmation step completely.

Soft Linden added a comment - 22/Apr/14 6:44 PM

Janet: Many scripted objects implicitly assume that anything spoken by an avatar was deliberately spoken, and that content predates the secondlife:///app/chat method. This bypasses permission checks if users click a link. Prices can be changed on land rental boxes, security orbs can be altered, scripted attachments can do unexpected things, etc. We heard one example where an avatar's partner's collar unwittingly leashed them to an instructor during a building class because they clicked a link in an IM.

@sl-service-account
Copy link
Author

Gearsawe Stonecutter commented at 2016-10-24T05:06:41Z

So the addition of the warning box would be acceptable with the ability to "never show again and allow". The Style would be much like the permissions to debit money.
I use llDialog for many products but sometimes the menus can become unwieldy with the building list for buttons. see below. Where after 9 items you have to use 3 bottoms for previous, next, exit. Where the chat is far more simple to implement. No wasted memory building lists and tracking which page they are on. I decided to implement this for speed and ease of use. Unfortunately shortly after taking a break from SL this feature was blocked. On a second note let say a user had lets say 100 items in the inventory they would have to click thru several pages to get to the last item. Just to find out it was not the right one. Now they must go through the many pages to get to the next one.

http://www.joe-brown.net/SecondLife/PostImage/UposerMenu.PNG

I'm sorry people just click on any link they see. There has to be some education in this world. I do not open email and blindly click link in them which can be more more disastrous.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2016-10-24T06:58:22Z

This also affects several of my yet to be released products. I have a shield system that stores proximity alert data and chats labeled chat uri's for each alert so the owner can choose which data to access and I have security system components that chat access uri's for stored details for rezzed and attached objects that exceed set thresholds.

I would rather have an annoying, but suppressible popup over chat uri's being completely blocked.

As Whirly says, this change breaks content.

@sl-service-account
Copy link
Author

Kyle Linden commented at 2016-10-26T18:28:47Z

Hello Gearsawe,

Thank you for your suggestion. The team has reviewed your request and determined that it is not something we can tackle at this time.
Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team. This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests

Thanks again for your interest in improving Second Life.

This was referenced Feb 14, 2024
Open
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account