4 ms·

> In addition to improving privacy and control, this is the only way to make Open Source web apps viable. What about client-side web apps? Like Chrome apps?

• kentonv 11y ago
  Hey Josh, For apps that fit the model, a client-side approach can work well. There are a lot of limitations, though, that make it not ideal for a lot of apps. An incomplete list of issues: - Basically all existing apps with server-side code would need to be rewritten to fit in this model. (Sandstorm can run arbitrary Linux binaries.) - A large class of apps fundamentally need to be running even when you aren't present. E.g., a mail server. - Sharing with other users, or connecting to other app instances, is tricky at best when there's no server to mediate. - Real-time collaboration requires much lower latency than you can get when syncing through Dropbox and the like. You could maybe pull it off through WebRTC but it's much easier to use a server. - Access control is really hard to enforce without an app-aware server. E.g. if you want to give users permission to comment on your doc but not edit it, how do you do that with dropbox permissions? - Limited sandboxing: Generally you can't e.g. prevent the app from secretly phoning home to its developer, at least given the security model currently provided by e.g. Chrome. PS. offtopic but can you merge this PR? :D https://github.com/google/protobuf/pull/710 https://github.com/google/protobuf/pull/710
  • haberman 11y ago
    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?
• dudus 11y ago
  That's a different use case. A client side web app is supposed to mimic the use case for native apps. While sandstorm seem to mimic the use case for Web Apps. If you are the only user I guess you could try to port it as a Chrome App, but Sandstorm seems to be aiming for something available online to be accessed by multiple users.