Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
Karl Fogel kfo...@red-bean.com writes: Nick liberationt...@njw.me.uk writes: The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. F-Droid does a lot of this. I couldn't find a standard way to get the exact source snapshot a particular app's build comes, nor what the build parameters were, although via the web site the app pages do give release numbers. They're hard at work on deterministic builds now, apparently, and I would guess that some of these essentially UI fixes will happen along with that. That info is in the server metadata file for the app (for example the git tag for the source that was used to build the app, and the build parameters). Probably just needs to be exposed in the UI. -john -- John Sullivan | Executive Director, Free Software Foundation GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=8096. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
John Sullivan jo...@fsf.org writes: Nick liberationt...@njw.me.uk writes: The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. F-Droid does a lot of this. I couldn't find a standard way to get the exact source snapshot a particular app's build comes, nor what the build parameters were, although via the web site the app pages do give release numbers. They're hard at work on deterministic builds now, apparently, and I would guess that some of these essentially UI fixes will happen along with that. That info is in the server metadata file for the app (for example the git tag for the source that was used to build the app, and the build parameters). Probably just needs to be exposed in the UI. Thanks, John; agreed. I saw your mail just after I filed https://gitlab.com/fdroid/fdroiddata/issues/76 about this very question. By the way, I've also updated the post at https://openitp.org/circumvention-tech/app-stores-and-trustable-code.html to give F-Droid some more credit -- I think I relied too much on those UI routes existing, when that's not necessarily a reliable indicator of what F-Droid is doing on the back end. Had I talked to you or someone else at F-Droid first, though, I could have discovered just how much of the proposal was already implemented there! Sorry not to have done so. In a private conversation with Brian Behlendorf, he pointed out that there's a more general version proposal that should really be the goal. I'd like to do a second piece on his proposal, but as I'm not sure I'll get to it soon, I'm posting it here just so it has some circulation. Quoting him (inner text is his, outer text is my reaction): Karl Fogel wrote: Brian Behlendorf wrote: If we're proposing ideas for phone OS and app store folks, we should start from first principles: * End users should be able to trust that the code installed on their system came as intended by the app author and as verified by the App Store against their policies. * End users should be able to modify and recompile Open Source apps, and if they redistribute those modified works (whether direct or though app stores again), downstream recipients should be able to use the same means to verify the modified works. This suggests to me the following process: * App developer builds install image, generates a checksum, optionally signs it with a private pubkey. * App developer sends install image, source code to app store, who perform their acceptance tests, build their own copy of the install image, then validate that both install images checksum to the same number. * App developer publishes image name, version number, checksum, and signature to a well-known location on their own SSL website (the same way they did for robots.txt - call it appchecksums.txt) so that their identity can be tied to a registered domain name and SSL cert. * App store publishes the install image, checksum, and URL to their repository, making it available to all downloaders. If it's an Open Source package they also provide a clear URL to the specific revision of the code that builds the install image, as well as the OSI-approved license used. * App store client on the phone is asked to install the app. First they download the package, as well as the corresponding appchecksums.txt file from the developer's own website. If they don't match, error out or prompt for exception handling. If they do, feel free to install. * App store client on the phone provides a means to download the source code if the app developer wishes to allow it - and it points to the same bundle of code that the app store used to verify the build. This gets the app store out of the business of generating their own builds from a public tree (they still build, but only what the app developer asks them to build). It also removes the historic dependency on a public tree, just in case the project is closed or the code hosting service disappears. Thoughts? My thought is: spot-on. I had meant that the app store should host a copy (e.g., a git or hg clone) of every source tree it builds; in any case, many other people will have copies. The app store just needs to publish the snapshot checksum -- the content ID checksum -- and the distributed archive of the Internet can take it from there. So yes, the store should host a copy of the tree, and in the case of open source apps, that copy happens to match one or more other copies found out on the Net anyway. The commit ID is the main thing. But your overall idea: that the app store can still usefully prove to the *author* as well as to the public that what's being shipped matches the intended code, seems really good to me, and is a
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
Quoth Karl Fogel: It would be great if app stores built open-source apps directly from the public source tree, stating exactly which snapshot was used. And it would be even better if they did so with deterministic builds -- though even just knowing that the app store had done the build themselves (instead of the app's author doing it) would be a huge win, and deterministic builds would be gravy. The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. But to be honest I'm not sure why people who are happy to use a completely proprietary mobile computing system would care that much about this. They have already voted with their feet that freedom (and by extension security and privacy) are not important to them. Sure, there may be plenty of people who are ignorant enough of how computers actually work to not realise the sacrifices they're making, but I don't think this article is targeted for them. Nick -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
On Thu, Sep 25, 2014 at 10:00 AM, Nick liberationt...@njw.me.uk wrote: But to be honest I'm not sure why people who are happy to use a completely proprietary mobile computing system would care that much about this. There is a difference between trusting Google and the manufacturer VS trusting the hundreds of proprietary apps and how they'll use your data... The attack surface is much smaller in the former... Nick -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
Nick liberationt...@njw.me.uk writes: The wonderful F-Droid already does this, as pointed out in the article. So it doesn't seem like a proposal so much as an explanation of why it's important. F-Droid does a lot of this. I couldn't find a standard way to get the exact source snapshot a particular app's build comes, nor what the build parameters were, although via the web site the app pages do give release numbers. They're hard at work on deterministic builds now, apparently, and I would guess that some of these essentially UI fixes will happen along with that. (I don't mean to sound like a complainer: F-Droid is fantastic. I just hope they'll take it all the way :-) ). But to be honest I'm not sure why people who are happy to use a completely proprietary mobile computing system would care that much about this. They have already voted with their feet that freedom (and by extension security and privacy) are not important to them. Sure, there may be plenty of people who are ignorant enough of how computers actually work to not realise the sacrifices they're making, but I don't think this article is targeted for them. It's about reducing the number of exposure points. With most app stores, you have to trust the author for each app you have installed, *and* you have to trust the app store. If you can get that down even to just having to trust the app store, that's still a win. One can't just say security and privacy are or are not important to someone -- it's a matter of tradeoffs. Different people have different tradeoffs they want to make; app stores that offer verified open source apps give them more of a continuum along which to make that decision. Best, -K -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Proposal for more-trustable code from app stores; comments welcome.
On Wed, Sep 24, 2014 at 01:25:02PM -0500, Karl Fogel wrote: Quick summary is: Today, app stores don't even clearly *distinguish* open-source from closed-source apps, let alone do the builds themselves. It would be great if app stores built open-source apps directly from the public source tree, stating exactly which snapshot was used. And it would be even better if they did so with deterministic builds -- though even just knowing that the app store had done the build themselves (instead of the app's author doing it) would be a huge win, and deterministic builds would be gravy. Details in the article. Direct link: https://openitp.org/circumvention-tech/app-stores-and-trustable-code.html Deterministic builds really would be great, this would enable multi-party verified builds a la gitian but overall, I agree, choosing one party to trust with the build would be an improvement. It's not as if the app store proprietor is a neutral party in the transaction, they could just as well tamper the developer's (possibly untrustworthy) build. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
