Malicious links filtering system
tracked
Send Starlight
Currently if someone types [SOME_UNSAFE_URL SOME_SAFE_URL] into an IM they can convince a person to click a malicious link that looks entirely safe visually. I propose a way to correct this:
A new Preferences -> Chat -> Chat Windows checkbox called Enable URL Filtering. When unchecked it disables the Allowed URLs button.
A new Preferences -> Chat -> Chat Windows button called Allowed URLs.
When this button is clicked a filter list similar to the Firestorm Media Filter list pops up allowing the user to add or remove allowed domains.
By default the following domains should be allowed:
This way users can perform basic operations like connecting to friends on Discord, visiting support help links on firestorm or secondlife's website, visiting the marketplace, and viewing youtube links.
Beyond that if someone needs to visit additional domains, they need to add them to the allowed filter list. Then if someone were to attempt to hit them with a malicious link, it wouldn't work by default.
I think this would be a quick and efficient way to fix the problem for the most users. I understand this would make things more difficult for any url not on the list, but people could just display those urls as plaintext and users could copy and paste them if they truly want to visit them. And, in this way, they wouldn't be concealed by a malicious clickable link. And, any links added to the filtering allow list would become clickable if desired.
A checkbox which is on by default, could be provided for unchecking to turn off the security feature. But, it should be on default for all users, unless the user chose not to use it. With a warning that pops up when attempting to uncheck explaining why that might not be a great idea that they could then ignore and even "don't show me this warning again."
Log In
Otoa Kiyori
I have experienced something related to this last couple of weeks. I have a few anti-virus/malware software on Windows PC. They beep when I or my programs try to load something from the Internet that are "malicious". When I ride YavaScript pod, they sometimes beeped on dullahan_host.exe (the support program that comes with the viewer) reporting that it was trying load suspicous website URL probably from media prims on the road.
I would feel much safer about going around in Second Life if the urls (or any resource identifiers that can be loaded) submitted to chat/IM/notecard/notice or through media are checked somehow, before they are shared with outers.
If it could at least give us some type of visual warning (certificate vaildity, Virus Total analysi summery etc), I would feel much safer. I have been paranoid about hacker trying to take over my computer for last few weeks; while I have been hoping the hacker is just imaginary...
Talia Tokugawa
Hmmm Secondlife.com or SecondIife.com ?
misstoriblack Resident
no just no ... I hate that kind of things. I have my own server, I often send my own links over there to friends. That would basically block it cause "it's not secure".
It's responsibility of everyone to do his/her own verification. Displaying a small warning when clicking "be careful when following a link" is fine but that's about it.
Disabling links is an extreme solution to a user problem. If you don't trust a link, just don't click it !
Send Starlight
misstoriblack Resident What about the the alternative version that I provided?
"The alternative version of the idea, the feature could be disabled for everyone by default. However, when the filtering is disabled, the clickable link then shows the raw URL and not the alias. When the filtering is enabled, the clickable link would show the alias instead of the raw link and any non-whitelisted domains would only show plaintext unclickable urls."
This would seem to satisfy your concerns.
misstoriblack Resident
Send Starlight showing the link is enough, no need for any blocking feature. Especially if disabled by default. If disabled by default the people who might need it would not enable it.
As I said, a warning in the window asking if you wanna open in the embedded browser or your system browser is far enough.
Send Starlight
misstoriblack Resident Well, we already have a popup window warning and the virus is spreading.
If it is an opt in feature, then I don't see how there can be any arguments against it. You literally don't have to turn it on and can ignore that the feature exists.
The reason that my alternative approach still protects users is that by default they can see the raw clickable link. While users who want the extra protection of not ever clicking such a link if it is potentially malicious can turn on the extra protection.
And, they'd still see the plaintext url when the filter system is enabled and can copy paste the url if they really want to visit it.
To me, this is like disliking that people use adblockers. It just doesn't make sense to be this against the idea.
Sorry if I come off a bit exasperated and annoyed in my reply I didn't realize I was going to have to defend the idea this extensively.
Chaser Zaks
Discord.com links can also have files that people uploaded, just saying.
Also disabling links entirely for non-whitelisted sites is a TERRIBLE IDEA, not only from a convenience standpoint but accessibility standpoint as well.
Don't get me wrong, I've thought of ways to try and counter this, but there is a point to where inconvenience out ways the protection. People will find ways around it, such as social engineering.
If you tell people "copy this link into your browser for free L$!!1!11", the same people who'd fall for the malicious link stuff would also fall for copying the link. In the end, it just creates a inconvenience for people rather than solving the issue.
I'm not opposed to say, LL dropping (aka: not sending) specific messages that contain certain links at server level, or making it harder to split URLs or just show the URL someone is visiting on the confirm open dialog. But disabling URLs for non-whitelisted domains, or disabling URL anchors is a non-starter.
Send Starlight
Chaser Zaks I almost clicked it myself and only did not because I decided I didn't want to try the new preview viewer. If I had fallen for it, it would have spread to an additional 1600 people.
Did you see my alternative version below? Are you against that form of the solution, it defaults to things seeming to stay the same while still protecting users.
Regarding Discord, I already addendum'd removing that part of my suggestion after Lucia pointed out it wasn't a good idea below. Canny doesn't let me edit an old suggestion, so I can only really update it via comments.
Nyx Onyx
Just some thoughts of mine on this matter: perhaps at least the cases of when an alias looks like a URL (which is then likely to be fraudulent), it could be rendered unclickable or perhaps result in a pop-up "You clicked on [alias], which is a link to [real URL]. This is a [type of link based on protocol] link. Do you want to proceed to [open site / perform action]?" And provide buttons based on the action: an abort option, open link in external browser, open link in internal browser, or an affirmative (if it's a Viewer action).
Send Starlight
Nyx Onyx No one actually reads those long paragraph popups, they just click OK.
Nyx Onyx
Send Starlight If there is a color-coded warning about the alias not matching the actual URL (when the alias looks like a URL), along with the action buttons being labeled "Open in external browser anyway" / "Open in internal browser anyway" and "Abort" / "Cancel" / "Stop" would summarize it well I think. Also, the action buttons having a different label when it's a Viewer action should help many by the mere fact that they're different, such as "Perform payment" or "Send text" or "Open X window". You'll never help everyone in all situations, but you can improve things for many in this way.
Send Starlight
Nyx Onyx I'm not certain color coding would stop people from clicking it, also you'd have to choose a color blind palette, e.g. would orange / yellow be as scary as red which we can't use? I guess research could go into testing if that would help. But, then you're just experimenting with your end user's livelihood and safety on a whim because you don't want to implement something safer. I suspect people would click the link anyway. I'm still firmly behind the idea that the only way to prevent them from clicking the link is to whitelist safe domains.
With your idea there's still a high probability, due to popup warnings already not protecting users, that isn't currently measurable because we don't know how users would react if at all to color codes, that the virus would continue to spread. While there is still a low probability with my alternative suggestion, which was weakened to satisfy critics, that it still spreads, e.g. maybe people would see the url that is now visually and obviously incorrect and visit it anyway. But, at least it gives most people a fighting chance. Whereas with my original suggestion above, it stops the virus completely.
In the end LL is going to implement or not implement things whatever way they've decided is the right way. To be absolutely honest, I don't have high hopes they're going to do it safely. I had a bit higher hopes when I created the suggestion, but now that I see this is so controversial I think they'll side with a very weak implementation or no solution instead.
The fact that the Firestorm team just announced that their solution is to put the links on their website and tell people not to give them out and that this is somehow going to solve it means to me they don't have high hopes for a solution either. Just hoping your users don't click links because you said you won't be sending them out, in a private preview group notice, and hoping the word spreads is just security theater. It is good that they're going to move to a website page instead, though. But, it isn't going to end the spread of the virus, people not in the preview group (99% of the rest of the SL population) will still click the links. Someone will say, here's the new page!
Not to mention a new version of FS is only the tip of the iceberg. They can come up with any reason to get you to click a link.
Send Starlight
Addendum: I just thought up an idea that might actually satisfy opponents to the suggestion. In this alternative version of the idea, the feature could be disabled for everyone by default. However, when the filtering is disabled, the clickable link then shows the raw URL and not the alias. When the filtering is enabled, the clickable link would show the alias instead of the raw link and any non-whitelisted domains would only show plaintext unclickable urls.
Send Starlight
Addendum: If implemented, the filtering should be enabled by default.
spirit Wingtips
I think an option to include in this is
within the viewer
you have the ability as well to ADD and SUBTRACT ( much like how you do the media streams or Ban/Access Lists in the land) links you want to be able to click like the official Second Life URL.Send Starlight
spirit Wingtips Agreed. Removing or adding to the list was implied. In the mock screenshot of what it should look like that I provided there is an Add button and a Remove button.
Send Starlight
Woolfyy Resident Nope. There are skilled hackers on this platform you've just been lucky not to bump into any of them. And, they're definitely having fun and making money.
There are obviously other ways of being hacked, e.g. media on a prim, but that's out of the scope for this particular feedback. The fact that you can be hacked in a lot of different ways doesn't mean that there isn't merit in closing this one.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Otoa Kiyori
Perhaps, show an Icon for verified approved domains (or use different color for verified and unverified)? So people would see if URL was one of the LL approved safe URL domains? (Like SSL pad lock icon on the browser.
I also think SLURI secondlife:// protocol probably should be somehow identified. Since it is part of SL mechanics - https://wiki.secondlife.com/wiki/Viewer_URI_Name_Space
What do you think?
Send Starlight
Otoa Kiyori My suggestion was to make the link unclickable to prevent viruses. I suppose showing a verified icon could help too, but I think it would still lead to some people clicking the link. Browsers experimented with verified green indicators and decided it led to users becoming complacent. If the link is unclickable a lot of the problem just goes way.
I agree that internal URI namespaces should be automatically allowed, and wouldn't have to show up in the whitelist.
Otoa Kiyori
Send Starlight I just learned that if the computer that viewer is running on is already contaminated - if the cerfiticate authority setting is already compromised, the pad lock check (the certificate validation on the viewer) would not work too well, so I'd love if "link" is submitte in some form to the grid, if the SL grid validates the cerftificate of the link and flag that part of the url string be validated, before viewer sees it and makes its own decision, I'd feel more safe about the links...
Load More
→