5 ms·

How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?

by moxie 10y ago

kentonv 10y ago
It looks to me like your article is really arguing for central control of the code, rather than central control of the serving infrastructure. Having everyone running the same code means changes can be made quickly because only one implementation needs to change. Centralized serving infrastructure makes central control of the code easy. But if you look at mobile, we have central control of the code there without central control of the infrastructure: everyone has their own phone, yet runs the same apps that stay up-to-date via app stores. Sandstorm is basically taking that model to servers: within 24 hours of an app update, everyone gets a notification and can click one button to update their copy, so everyone tends to stay up-to-date. (Disclosure: I'm the lead developer of Sandstorm.)
- pdkl95 10y ago
  > central control of the code That's just an excuse to not implement backwards compatibility in the protocol. Central control is also a security risk, as we've seen recently with Apple and the FBI. If the code is controlled centrally, the FBI (or whomever) only has to strong-arm one target. > gets a notification and can click one button to update their copy That sounds like you're trying to keep the user in control, which is great. I haven't head of Sandstorm before, but it sounds interesting. Have you considered the problem of forced updates? I'm not sure there is a good way to protect against the FBI trying something similar to the recent drama with Apple, where they order you to force a "special" update on {someone,everyone}.
  - kentonv 10y ago
    There's certainly a trade-off here. I think that making updates as frictionless as possible is overall a big win for security and development velocity. The down side is, of course, that malicious updates take effect more quickly. FWIW, Sandstorm is already designed to limit the possible damage from malicious apps in general, by making sure each app has only the minimum privileges it needs to do its job (and making sure the UX to grant said privileges is painless for the user). For example, we've seen quite a few security vulnerabilities in apps that were largely mitigated when running the app on Sandstorm: https://docs.sandstorm.io/en/latest/using/security-non-events/ https://docs.sandstorm.io/en/latest/using/security-non-event... Hypothetically, in the Sandstorm model, you could architect a messaging app which is incapable of leaking messages to a third party: for each contact, you would create a separate grain (fine-grained instance, in Sandstorm terminology) of the app, and you would permit that grain to communicate only with that contact's corresponding grain they created for you. If the app cannot communicate with other grains of itself -- much less third parties -- then it cannot leak any communications. Obviously, there are a lot of UX questions raised by this design. It is a goal of the Sandstorm project to solve those UX issues, and we believe they are solvable, but I can't claim to have all the answers today. More likely what you'd run today is a single grain which can talk to all your contacts. In this case an evil app update could almost certainly find a way to covertly leak any message through the network of contacts. (And, of course, another issue, if communications are crossing the internet, is traffic analysis and covert channels embedded therein.) So, yeah, there may or may not be a good technical solution here. But on the bright side, the Apple-FBI case seems to indicate that the government doesn't have the power to compel false signatures on code updates. I can only hope that interpretation stands and is reinforced over time.

How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?

by moxie 10y ago

How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?

It looks to me like your article is really arguing for central control of the code, rather than central control of the serving infrastructure. Having everyone running the same code means changes can be made quickly because only one implementation needs to change. Centralized serving infrastructure makes central control of the code easy. But if you look at mobile, we have central control of the code there without central control of the infrastructure: everyone has their own phone, yet runs the same apps that stay up-to-date via app stores. Sandstorm is basically taking that model to servers: within 24 hours of an app update, everyone gets a notification and can click one button to update their copy, so everyone tends to stay up-to-date. (Disclosure: I'm the lead developer of Sandstorm.)

pdkl95 10y ago
> central control of the code That's just an excuse to not implement backwards compatibility in the protocol. Central control is also a security risk, as we've seen recently with Apple and the FBI. If the code is controlled centrally, the FBI (or whomever) only has to strong-arm one target. > gets a notification and can click one button to update their copy That sounds like you're trying to keep the user in control, which is great. I haven't head of Sandstorm before, but it sounds interesting. Have you considered the problem of forced updates? I'm not sure there is a good way to protect against the FBI trying something similar to the recent drama with Apple, where they order you to force a "special" update on {someone,everyone}.
- kentonv 10y ago
  There's certainly a trade-off here. I think that making updates as frictionless as possible is overall a big win for security and development velocity. The down side is, of course, that malicious updates take effect more quickly. FWIW, Sandstorm is already designed to limit the possible damage from malicious apps in general, by making sure each app has only the minimum privileges it needs to do its job (and making sure the UX to grant said privileges is painless for the user). For example, we've seen quite a few security vulnerabilities in apps that were largely mitigated when running the app on Sandstorm: https://docs.sandstorm.io/en/latest/using/security-non-events/ https://docs.sandstorm.io/en/latest/using/security-non-event... Hypothetically, in the Sandstorm model, you could architect a messaging app which is incapable of leaking messages to a third party: for each contact, you would create a separate grain (fine-grained instance, in Sandstorm terminology) of the app, and you would permit that grain to communicate only with that contact's corresponding grain they created for you. If the app cannot communicate with other grains of itself -- much less third parties -- then it cannot leak any communications. Obviously, there are a lot of UX questions raised by this design. It is a goal of the Sandstorm project to solve those UX issues, and we believe they are solvable, but I can't claim to have all the answers today. More likely what you'd run today is a single grain which can talk to all your contacts. In this case an evil app update could almost certainly find a way to covertly leak any message through the network of contacts. (And, of course, another issue, if communications are crossing the internet, is traffic analysis and covert channels embedded therein.) So, yeah, there may or may not be a good technical solution here. But on the bright side, the Apple-FBI case seems to indicate that the government doesn't have the power to compel false signatures on code updates. I can only hope that interpretation stands and is reinforced over time.