Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Menuless World Traversal Hurdle - Custom Launch Option Security Warnings #1

Open
smsithlord opened this issue Jun 6, 2019 · 0 comments

Comments

@smsithlord
Copy link

World Traversing Event
During @madjin's world traversal event we launched various shortcuts to standalone & web apps that would automatically load us directly into a particular server & spawn us at a particular location within it. This type of menuless app launching & world connecting bridged together the various experiences that would otherwise be distinct.

Essential how it worked was special shortcuts were created for each app that would provide the app with special parameters telling it what server to connect us to & where to spawn us. With these parameters, the apps would bypass any kind of welcome screens or home menus and instead take us directly to where we wanted to be.

Each app had its own parameter names and value formats, but that didn't break anything. As long as the app defined some parameter that could be used to connect & spawn us, then it could be added to the shortcut. No standardized set of parameters was required for this to work.

The apps we traversed were designed to accept these types of parameters specifically to allow users to bypass all menus or welcome interactions and instead get directly in-game to where they are going. During the event we were passing these apps these parameters on-the-fly through special shortcuts created to take us directly to our next destination.

Security Warning Issue
While the world traversal did succeed, there were some issues encountered during the event.

Launching standalone apps through custom protocols such as steam:// or vrchat:// is relatively safe and no extra security warning is needed in these cases. However, when shortcuts provide their own custom launch options to use on the standalone app, an extra security warning is presented. It's when a very obvious and understandably abnormal security prompt comes up and warns you about custom launch options, shows you the custom launch options trying to be used, and tells you to allow it only if you recognize them. This issue exists because platforms cannot be certain that an arbitrary app if safe to launch with the provided launch options.

image

Providing these options dynamically through the link is essential in tying together worlds across different apps, and this extra securing warning impacting standalone apps is an issue.

Proposal
If all apps had at least one launch option that was always treated as if it was insecure by the app (ie. it does its own sandboxing on what the option can impact) then platforms would not have to show users that cumbersome security warning.

A standard metaverse input launch option that is always considered insecure by the apps that implement it. That way the common situation of wanting to pass simple metaverse info, such as which server to join & where to spawn, can be done in a safe way.

No standard within that safe launch option is needed - we don't need a universal set of parameters. We just need a safe interface to pass the app what ever simple "metaverse info" parameters it is setup to take.

Some app launchers disable custom launch options all together, or only allow them to be defined locally, not dynamically in the shortcut itself. Both of these solutions have a negative impact on direct world traversal because if the shortcut cannot provide the options about what server to join and where to spawn, the user must interact with menus themselves.

Merely one launch option that apps are expected to treat as insecure could help move everything in the right direction for menuless world traversal.

Perhaps an alternative would be for apps to be able to declare a set of launch options that are safe to pass to it. Anything that allows for at least one launch option that is always treated as if it was insecure would be sufficient.

Web App Note
Web apps consider all URL parameters to be insecure, so they inherently avoid this issue, but many standalone apps do not consider parameters to be insecure and suffer from this world traversal-impacting issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant