I think we need to be careful about wording that is not quoted from the technical specification in the gaia docs. We are promising that there will be a validation of data writes per the gaia auth scheme.
This is an interesting point that Gaia itself doesn’t guarantee encryption – that appears to take place in blockstack.js and the mobile SDKs, correct?
I’m not sure whether the user needs to know exactly where encryption is handled in the stack, but it does feel when taking your point and @jude’s into consideration that we may risk over-promising if we mention encryption here at all (and especially by saying "all apps…will store your data 100% encrypted). At the very least, it seems we’d want to soften this to “apps can store your data encrypted…” so we’re not promising either that all or even some apps will encrypt data for a particular user, which may not be the case.
That said, I think it’s cleanest to remove the reference to encryption entirely for this release and think through more how we can provide better education and transparency surrounding encryption for end users in general. Ideally, when authenticating an application, users would know just what kinds of data will be stored for them and how (encrypted or public). But I’m not sure how we can communicate that effectively when apps evolve over time (post-authentication for previously registered users) and store different data in different ways for different users.
Perhaps this is another browser problem for @larry to help solve since the client itself could monitor Gaia activity and report the data being transacted, showing encryption status, etc…like an advanced evolution of browsers’ HTTPs status indicators perhaps. Perhaps the browser could even itself broker permissions e.g. prompt the user to approve storing images publicly into Gaia before allowing the app to do so.