<br><br><div class="gmail_quote">On Fri, Apr 11, 2008 at 2:16 PM, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Eben Eliason wrote:<br>
</div><div class="Ih2E3d">| In fact, this exploit could happen even without a launcher service.<br>
| Any activity that wants to could write the users private data to the<br>
| disk in a URL format, as an object, and give it a fun preview image.<br>
| When the later discovers and becomes curious about it, she'll open it<br>
| and send out her private data to whatever site the other activity<br>
| wanted. Is there something in place to prevent this that I'm unaware<br>
| of?<br>
<br>
</div>I would argue that there is no way around this, and that it should not be<br>
seen as an exploit. Users must understand that any object produced by an<br>
activity instance can potentially contain any information available to<br>
that instance at that time.<br>
<br>
The best we can do is to show the user which instances have written data<br>
in each object, and which objects those instances had access to. That<br>
list is the list of all private data that could potentially be enclosed in<br>
each object. This is relevant not only to HTTP access but also to Sharing.<br>
<div class="Ih2E3d"></div></blockquote><br>What you are describing is a clear position, but it does not sound like bitfrost to me. The bitfrost paradigm is that security is maintained without any "users must understand" requirements. This could be maintained if:<br>
<br>1. There is a "private" attribute of journal objects.<br><br>2. Journal objects which are "private" are encrypted at some time before being backed up (possibly before being written to fs).<br><br>3. Journal objects which are "private" will not open with any P_NETWORK activity except the same one which created them (or will open with a special P_NETWORK-crippled, zero-configuration instance of that activity). (Yes, "the same activity which created them" needs better definition, I would accept "bundles signed by the same key" personally but that is another discussion)<br>
<br>4. All objects created by non-P_NETWORK activities are "private" by default.<br><br>5. There is of course some way in the journal for a user to remove the "private" flag from an object.<br></div><br>
At that point, "the way to open another activity is to send the user to an instance in the journal to click it open" is perfectly compatible with security.<br><br>Jameson