<br><br><div class="gmail_quote">On Wed, Jun 11, 2008 at 3:08 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</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">On 11.06.2008, at 03:37, Jameson Chema Quinn wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thus, there would be three kinds of activities:<br>
<br>
those with full network access, able to talk to arbitrary IP addresses (browse is inescapably in this category);<br>
<br>
those with some kind of "telepathy-only" access, which would only let them talk to IP addresses that correspond to a friend sharing the specific activity instance (Chat might fit here; certainly, Write would);<br>

<br>
and those with no network permissions.<br>
<br>
The telepathy-only, middle security level would allow the last two "good" use cases, while preventing the last two "bad" use cases. It could be implemented by sugar giving them some kind of key, valid only for that specific instance (and renewed when the instance is resumed) that they could use to "unlock" access to a given IP. I understand that the middle security level would not necessarily be perfect - a man-in-the-middle attack could well subvert any gains, and, especially in early versions, it would be hard to guarantee that any abstraction layer was 100% successful at keeping malformed requests from getting some illicit control over a lower layer - but it would drastically reduce the practicality of any large-scale snoop-net or bot-net for your average shareable activity. Assuming that the connection to friend X was compromised; an activity would still have to hope it was started with an instance that had been shared with friend X in order to leak any data.<br>

</blockquote>
<br>
<br></div>
Err, hasn't that been the plan all along? P_NETWORK is only given to activities needing full network access. It is independent of sharing. An activity wanting to share must use telepathy, period. Your "no network permissions" above case does not exist separately, it is the same as "telepathy-only".<br>
<font color="#888888">
<br>
- Bert -<br>
</font></blockquote></div><br><br>It is great to hear that this is not a new idea. Looking back at the implementation speculation, m_stone's  <a href="http://cr.yp.to/unix/disablenetwork.html" target="_blank">http://cr.yp.to/unix/disablenetwork.html</a> idea would, of course, not prevent access to a service like Telepathy which is available over DBus. Still, from my outsider perspective, it is not quite fair to say that it is "the plan all along". Here's what I've seen of the plan: (the bitfrost spec, emphasis mine):<p>
"Each program's network utilization can be constrained in the following ways:
</p>
<ul><li><b> Boolean network on/off restriction</b>
</li><li> token-bucketed bandwidth throttling with burst allowance
</li><li> connection rate limiting
</li><li><b> packet destination restrictions by host name, IP and port(s)</b>
</li><li> time-of-day restrictions on network use
</li><li> data transfer limit by hour or day
</li><li> server restriction (can bind and listen on a socket), Boolean and per-port
</li></ul>
<p>Reasonable default rate and transfer limits will be imposed on all
non-signed programs. If necessary, different policies can apply to mesh
and access point traffic. Additional restrictions might be added to
this list as we complete our evaluation of network policy requirements. "</p>Neither of the relevant points makes any reference to poking holes in this "firewall" for collaboration.<br><br>Also, there are some features in Telepathy/whatever that would be needed to give it security characteristics<br>
<br>In order for an abstraction layer to have security characteristics, it would probably need to:<br>-be in a separate process, communicating through DBus; done.<br>-Not allow an activity to do anything by itself that would be visible on the network, except for maybe announcing its (un)willingness to share. The network-visible name of the activity would be set by Glucose, sharing partners would be set from Glucose (including any search, invitations, and responses, as well as handling resuming shared instances). It is not my impressiong that Telepathy worries about this kind of security; if I am wrong, such thinking should certainly be documented.<br>
<br>...<br><br>I opened this thread to understand how people felt about this idea. If Bert is right, and this is the unstated general plan, then great! I am not just saying "you guys oughtta", I can start to look at this issue and post much more specific bugs to continue the conversation on an implementation level.<br>
<br>Jameson<br>