Describe the feature and the current behavior/state.

Motivation

I'm a long-time Alfred user (and recent Raycast convert!), and the main reason I don't use more workflows / extensions is that giving full access to my computer to a random extension I found on the internet scares me. A poorly-written extension might wreak havoc on my computer, accidentally overwriting files or consuming all my computer's resources. A malicious extension could steal all sorts of sensitive information.

Having extensions go through this repository (with a review process) ameliorates the situation but 1) doesn't help for extensions that never make it into the official store, and 2) isn't foolproof – it's certainly conceivable that a rogue extension could sneak past review.

Proposal

It'd be great if extensions were run in a sandbox, limiting the damage a rogue extension could do. By default, extensions would have no access to the filesystem, network, clipboard, dangerous syscalls like fork, execve, etc. Ideally the amount of CPU and memory the extension can consume would also be restricted.

Extensions could then declare the permissions they require via the package.json manifest file — for instance, if an extension required access to the GitHub API, it could request network access to api.github.com. Or a Bear extension might ask for read-only filesystem access to ~/Library/Group Containers/9K33E3U3T4.net.shinyfrog.bear/Application Data/database.sqlite. When a user goes to install the extension, they'd be told about the permissions the extension requires, allowing the user to make an informed decision about whether to install the extension. If an emoji lookup extension wants full access to my computer, I might think twice before installing it. Conversely, if it required no permissions at all, I could install it with confidence that it's unlikely to harm my computer.

There are lots of options for how this could be implemented: WASM-based sandboxes, Deno's permissions system, v8 isolates, even Docker containers at the heavier-weight end of the spectrum.

I appreciate this would represent quite a significant amount work, but I think it'd be worth it and enable a robust and trustworthy ecosystem to be built around Raycast 🚀

Will this change the current api? How?

1. Manifests have a new optional permissions section, which might resemble the permissions a Chrome extension can request or the permissions that Deno exposes.
2. A facility for querying permissions to enable optional permissions (e.g. ask to use a web API for up-to-date Emoji data but fall back to bundled data otherwise).
3. Built in error handling for when an extension tries to use permissions that haven't been granted, perhaps.

Who will benefit with this feature?

• Raycast users, as they can be more confident they're not installing malware and make more informed decisions about which extensions to install.
• Raycast extension developers, as they can be more confident their extension won't cause unintended adverse consequences to users.
• Raycast, as this will help build a large and trusted ecosystem around the product.

Who loses?

• Evil hackers! 👿