[API Feature Request] Extension sandboxing and permissions system

[hmarr]

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! 👿

[nonissue]

I agree with this whole-heartedly. I really like Raycast, but there are already seem to be extensions that request/store sensitive information, and I have some concerns:

From a Developer / Contributor Perspective

• I skimmed through some extensions that store sensitive information (like API keys, sessions, usernames, etc), and there doesn't seem to be a convention or pattern around storing aforementioned sensitive data. Some extensions store sensitive data as preferences, others store it in localStorage (this is a big issue IMO), and others still write it to disk or cache it. I couldn't find any guidance in the developer docs on how best to do this.
• Things I'd like to see covered:
  • localStorage vs Preferences
  • what kind of data is appropriate to store
  • details about scope and access

From a User Perspective

• Extensions that request sensitive information from users at the very least should display a warning. It looks like at the moment extensions are reviewed before being added to the store, but I still think it's possible something slip through.

(Note: I'm not expert with web/app security, and I know extensions are in beta. These are just some quick thoughts I had).

[nonissue]

Related:

#213
#101

[superandrew]

hi, is this something in the work? Is there an idea about when this could be implemented? I was considering switching to raycast when I found this issue that I think is a big one for many useres

[Sly777]

hey raycast team, are you planning to update security privacy issues on the extension core?

[vleeuwenmenno]

Any update on this? Seems to be rather important.

[alexphl]

Trying to hack together a permissions system around Node is a monumental task, and containerizing extensions would make an already slow runtime just stupidly inefficient.

Now, I have no idea why Raycast went with Node instead of Deno (which has a native per-module permission system), we can only assume there were good reasons for that beyond just NPM. If migration is at all possible, it would be ideal for both security and performance reasons. It would force almost every extension that uses npm packages to look elsewhere, but at least that's a solvable problem.

[Sly777]

I hope the Raycast team will give an answer (negative or positive) one day, at least

[iSteveyang]

One year on, has there been any improvement in security?

[dengshenkk]

has any response else?

[ayadagain]

Happy new year Raycast team!, is there any updates on this? I really like Raycast but having all the extensions accessing everything is quite scary tbh. I do understand that most of the extensions are open-source and they can audited by anyone but no all the users are tech savvy. Also, I don't see what can restricts something like the The Great Suspender scenario from getting repeated again (ref: greatsuspender/thegreatsuspender#1263) but this time with more severity as there is nothing that restricts the permissions.

[unnamedd]

cc @mathieudutour

[peduarte]

Hey, thanks for taking the time to write such a detailed suggestion. It's really appreciated. This is something we want to address. I can't promise exactly when, but it'll happen in the foreseeable future. We have created an issue internally to track this, so I'll close this issue. Thank you 🙌

[benajaero]

Any update on this?

[ajwadjaved]

Hiya, it's been over an year. Any update, if it's open source I wouldn't mind working on it

[ayadagain]

@ajwadjaved I can pitch in too!

cc @peduarte can we submit a PR(s) for this feature?

[mathieudutour]

We are thinking about using NodeJS permissions to solve this: https://nodejs.org/api/permissions.html

There are a few drawbacks tho: it's not possible to specify a set of domains to access via internet nor is it possible to restrict the file system access to certain directories (or read-only access). If you'd like to contribute, you can head to the NodeJS project and contribute there: https://github.com/nodejs/node

[ayadagain]

@mathieudutour is this approach underdevelopment in Raycast (if yes, please specify which branch/PRs as I'm curious about the implementation) or is it a theoretical approach?

[mathieudutour]

We are experimenting with it but Raycast itself isn't open source

[sf8193]

any traction here? Discovered ray cast recently and love it but this is a dealbreaker for me

[ayadagain]

@sf8193 they are gatekeeping the software and they're experimenting with the nodejs api permissions.

We are experimenting with it but Raycast itself isn't open source

[sf8193]

gatekeeping seems harsh, they're trying to make money and i can respect it. Just want to make it known that from my perspective it seems like a tool used mostly for devs, who are also probably the most (or one of the most) security conscious community. Hard to advocate for (a really great) tool like this knowing there's a potential gaping security hole only held up by reviews