Comment 15 for bug 1384286

"So, if I understand you correctly, you are saying that @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/* is the writable cache directory for the scope (exactly as it is now), and @{HOME}/.local/share/@{APP_PKGNAME}/* is the readable directory where the scope can read data produced by the app?"

Yes

"I take it that the readable directory would not be applicable to scopes that do *not* install together with an app in the same click package? (We would throw an exception if a scope doesn't have an associated app and tries to get the directory name.)"

If I understand the question, APP_PKGNAME is unique to the scopes and apps installed by a particular click package. A differently named click package will have a different APP_PKGNAME set, so there is isolation between clicks. This bug only allows scopes and apps within the same click to coordinate with each other.

"Now, if I have this picture correct, it implies that a scope can read from an app, but an app cannot read from a scope. Is that what we want? If so, I think I'm good with this. (I haven't implemented anything yet, so there are the usual caveats. But, off-hand, I don't see a show-stopper.)"

This is correct and I think it is what we want. I'm still holding out for the possibility of a local content scope some time down the road and allowing writes to the app dir in a local content scope would allow an app to break out of confinement via this shared dir (of course, we could just not let that scope type coordinate with an app...). Let's go with what I suggested for now, and I will document the thinking in the policy so the thinking isn't lost.