3 ms·

Makes sense! I am particularly interested whether your security model could support the following: I'm working on an accounting app, and want to support lettin

Makes sense! I am particularly interested whether your security model could support the following: I'm working on an accounting app, and want to support letting the app automatically pull transactions from the user's bank accounts, mint.com-style. So the app needs to be able to log into the bank's websites as the user, probably using a real web browser. But I (as the developer) don't want to have access to the user's credentials or have the app capable of phoning home to me. I also want users to have confidence that they can use third-party contributed, bank-specific plugins for pulling this data, but be guaranteed that these plugins can't steal their data or their money. A slightly difficult problem, given that once you have a bank login, you can probably use it to move money around. But curious if you have an answer to this! The tight security of the app model is compelling, given how sensitive my users data would be. > PS. offtopic but can you merge this PR? :D I totally had a long-ish reply typed out but must have closed my browser before I hit "submit" -- d'oh! Sorry, will get to that now.

kentonv 11y ago
Yes, absolutely, that sounds like a perfect fit for Sandstorm's security model. We are still working on some of the details, but the user will be able to ensure that the app can, say, talk to bankofamerica.com but not any other web site. You could also have each "bank connector plugin" be in a separate grain, so only that grain has outside access, and then a security-paranoid user only needs to review the connector code to make sure it doesn't do anything nasty, rather than reviewing the whole app. The core app would only have permission to talk to the connectors. Of course the next question is: will any user actually understand how to set this up? I think with the powerbox UI, it will actually be quite reasonable. It would look like this: - User installs the base app, which initially has no permission to talk to the outside world. - User clicks "add an account", causing the app to make a powerbox request for an object implementing "BankAccountConnector". - The user doesn't have any of those yet, so Sandstorm would guide the user through finding a matching app on the app market, installing it, and setting it up. It's not hard to imagine a reasonable UI here: You see a list of matches like "Bank of America Connector", "Wells Fargo Connector", etc. - As part of installing an app, the user will be able to see who the author is, look at reviews, and (if they are so inclined) click through to code. - Once installed, the connector app prompts for the user's bank credentials and then makes a powerbox request for "access to bankofamerica.com" (or whatever). Sandstorm asks the user if the app may access this site, and the user confirms. - Everything now resolves and the user is returned to the original app, which now is able to pull data from their bank account. This is, of course, still very vaporware right now, but that's the vision, and there honestly aren't many open questions about how it will work, just code to write.
- haberman 11y ago
  Cool -- that's a really compelling story! And I presume the two apps (the main app and the connector app) can send messages to each other? The only part of this that seems short of ideal to me is: I want the connector to use a real web browser to talk to the bank's website, for several reasons, but chief among them is that if the website asks the user something unexpectedly (like a security question), or something doesn't work, it's easy for the user to see what is going on. That is one aspect of the client-side approach I liked: the browser running the accounting app is the same browser being used to actually fetch the data. Do you have an answer for this?
  - kentonv 11y ago
    > And I presume the two apps (the main app and the connector app) can send messages to each other? Yep. Through Cap'n Proto RPC -- or HTTP layered on top of Cap'n Proto RPC. > I want the connector to use a real web browser to talk to the bank's website Interesting. That does add complication, but it seems doable. Perhaps the connector grain could act as a proxy, embedding the bank's UI in an iframe, where the iframe src of course doesn't point directly to the bank but points back to the connector grain in proxy mode. FWIW, we definitely want grains to be able to embed each other's UIs in iframes (with proper permissions), which might play a part in this.
    - haberman 11y ago
      > Interesting. That does add complication, but it seems doable. Perhaps the connector grain could act as a proxy, embedding the bank's UI in an iframe, where the iframe src of course doesn't point directly to the bank but points back to the connector grain in proxy mode. You're saying MITM the user's HTTP connection? I can't imagine how that would work with SSL? This might be too tricky to actually be feasible, just dreaming here! Hopefully it is useful to help you imagine cool scenarios and possible requirements.
      - kentonv 11y ago
        > You're saying MITM the user's HTTP connection? I can't imagine how that would work with SSL? The browser wouldn't think it's talking to bankofamerica.com. The browser would think it's talking to your sandstorm server. The user is willingly letting the grain MITM the connection so that the app can get their data out. There would certainly be complications, though.

kentonv 11y ago

Yes, absolutely, that sounds like a perfect fit for Sandstorm's security model. We are still working on some of the details, but the user will be able to ensure that the app can, say, talk to bankofamerica.com but not any other web site. You could also have each "bank connector plugin" be in a separate grain, so only that grain has outside access, and then a security-paranoid user only needs to review the connector code to make sure it doesn't do anything nasty, rather than reviewing the whole app. The core app would only have permission to talk to the connectors. Of course the next question is: will any user actually understand how to set this up? I think with the powerbox UI, it will actually be quite reasonable. It would look like this: - User installs the base app, which initially has no permission to talk to the outside world. - User clicks "add an account", causing the app to make a powerbox request for an object implementing "BankAccountConnector". - The user doesn't have any of those yet, so Sandstorm would guide the user through finding a matching app on the app market, installing it, and setting it up. It's not hard to imagine a reasonable UI here: You see a list of matches like "Bank of America Connector", "Wells Fargo Connector", etc. - As part of installing an app, the user will be able to see who the author is, look at reviews, and (if they are so inclined) click through to code. - Once installed, the connector app prompts for the user's bank credentials and then makes a powerbox request for "access to bankofamerica.com" (or whatever). Sandstorm asks the user if the app may access this site, and the user confirms. - Everything now resolves and the user is returned to the original app, which now is able to pull data from their bank account. This is, of course, still very vaporware right now, but that's the vision, and there honestly aren't many open questions about how it will work, just code to write.

haberman 11y ago
Cool -- that's a really compelling story! And I presume the two apps (the main app and the connector app) can send messages to each other? The only part of this that seems short of ideal to me is: I want the connector to use a real web browser to talk to the bank's website, for several reasons, but chief among them is that if the website asks the user something unexpectedly (like a security question), or something doesn't work, it's easy for the user to see what is going on. That is one aspect of the client-side approach I liked: the browser running the accounting app is the same browser being used to actually fetch the data. Do you have an answer for this?
- kentonv 11y ago
  > And I presume the two apps (the main app and the connector app) can send messages to each other? Yep. Through Cap'n Proto RPC -- or HTTP layered on top of Cap'n Proto RPC. > I want the connector to use a real web browser to talk to the bank's website Interesting. That does add complication, but it seems doable. Perhaps the connector grain could act as a proxy, embedding the bank's UI in an iframe, where the iframe src of course doesn't point directly to the bank but points back to the connector grain in proxy mode. FWIW, we definitely want grains to be able to embed each other's UIs in iframes (with proper permissions), which might play a part in this.
  - haberman 11y ago
    > Interesting. That does add complication, but it seems doable. Perhaps the connector grain could act as a proxy, embedding the bank's UI in an iframe, where the iframe src of course doesn't point directly to the bank but points back to the connector grain in proxy mode. You're saying MITM the user's HTTP connection? I can't imagine how that would work with SSL? This might be too tricky to actually be feasible, just dreaming here! Hopefully it is useful to help you imagine cool scenarios and possible requirements.
    - kentonv 11y ago
      > You're saying MITM the user's HTTP connection? I can't imagine how that would work with SSL? The browser wouldn't think it's talking to bankofamerica.com. The browser would think it's talking to your sandstorm server. The user is willingly letting the grain MITM the connection so that the app can get their data out. There would certainly be complications, though.