@dugcampbell I’m more bullish on the first question (integrating auth into the app UI), although that might be because I haven’t given it much thought yet 
- so mainly intuitive optimism.
You are more bullish on the second (stopping apps leaking private data). The first is a nice to have though, while the second is crucial so I want to explore that.
Let’s say I’m using an app to publish some initially unpublished data. For example, an unpublished draft blog post being published to the public blog. The app has permission to read my private data (not just draft blog posts), and when I publish a blog post I authorise it to create a public immutable file (the new public post) and modify other published files that link this into the website of the biog.
At this point the app can gather other data, from everything it has access to (a lot if we are not doing access control) so it is important that it can’t now leak that data for nefarious purposes.
I’m thinking it can create the blog post immutable data file and one or more other files we don’t know about. Maybe we can do that by requiring permission on creating every public immutable file? But what does this UX look like when publish means an app creates more than one file, or many files - we can’t ask the user for every file in such a case. So one question is: can we prevent an app that is requesting auth to create public immutable data from using this auth to leak data it has access to, under cover of publishing something else?
If we can’t, then the question becomes: can we prevent an app from leaking the locations of public immutable data that it has secretly used to store copies of our private data?
I’ve not thought much about this question but it seems like a tricky thing to achieve. For example, I think an app can easily embed a small piece of hidden data in some legitimately published Web page, image, document file etc, in order to leak the address of something else (ie an illegitimate published immutable data containing private information).
I think we need a solid solution to at least one of these questions in order to prevent ‘auth to publish’ from being abused. The first seems the least difficult, so maybe we should explore ways to prevent auth being abused to publish files that the user is not aware of.
[Above I’m thinking in terms of the existing data types, so maybe the new datatypes address some of these concerns?]