<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
</div></div>I don't think this discussion is fruitful without looking at the<br>
actual threat model.</blockquote><div><br>I agree absolutely. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The threat that was discussed is that a malicious activity could<br>
launch other activities on its own, resulting in DOS. The dialog (or<br>
any required user interaction) to me seems adequate to prevent this<br>
attack. Do you disagree?</blockquote><div><br>This is precisely what the dialog is for in my mind, and it is the one case where a dialog is justified.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you see other threats in this scenario that are not otherwise<br>
addressed by Bitfrost then please be specific about them, and we'll<br>
have a separate discussion.</blockquote><div><br>I mentioned another threat which is involved with cross-activity launching, though is not directly part of the "seamless lessons" use case. This is the idea that an activity with P_MIC_CAM could automatically launch or pass data to an activity with P_NETWORK. Nobody has yet given any comment on this threat or my proposed solution:<br>
<br><b>Data from a P_MIC_CAM activity is marked so that it simply cannot be opened by a P_NETWORK activity.</b> Specifically, there is a "Private" metadata attribute for all journal contents. There are two new bitfrost privileges, P_CREATE_NONPRIVATE and P_READ_PRIVATE. All activities have the ability to create and read its own private journal entries and to read nonprivate journal entries it did not create. The new privileges are needed to, respectively: create nonprivate entries; and read private entries created by other activities. P_CREATE_NONPRIVATE is similar to (or, possibly, implemented as synonymous with) P_NETWORK in that it is not granted along with P_MIC_CAM without user intervention. In the same way, P_READ_PRIVATE is similar to (or, possibly, implemented as synonymous with) P_NETWORK in that it is not granted along with P_MIC_CAM without user intervention.<br>
</div></div><br>