-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[API Feature Request] Extension sandboxing and permissions system #200
Comments
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
From a User Perspective
(Note: I'm not expert with web/app security, and I know extensions are in beta. These are just some quick thoughts I had). |
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 |
hey raycast team, are you planning to update security privacy issues on the extension core? |
Any update on this? Seems to be rather important. |
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. |
I hope the Raycast team will give an answer (negative or positive) one day, at least |
One year on, has there been any improvement in security? |
has any response else? |
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. |
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 🙌 |
Any update on this? |
Hiya, it's been over an year. Any update, if it's open source I wouldn't mind working on it |
@ajwadjaved I can pitch in too! cc @peduarte can we submit a PR(s) for this feature? |
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 |
@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? |
We are experimenting with it but Raycast itself isn't open source |
any traction here? Discovered ray cast recently and love it but this is a dealbreaker for me |
@sf8193 they are gatekeeping the software and they're experimenting with the nodejs api permissions.
|
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 |
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 toapi.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?
permissions
section, which might resemble the permissions a Chrome extension can request or the permissions that Deno exposes.Who will benefit with this feature?
Who loses?
The text was updated successfully, but these errors were encountered: