ostatus breaks permissions and vice versa

[Caleb Davis]

In the quest for ostatus federation + privacy we will come across
conflicts of interest between ease of communication and
permissions. These will manifest themselves as mutually exclusive
design constraints. Now that we have a first draft of the privacy
design we can list these conflicts in this issue as we come across
them in the wild.

We could close this ticket after all ostatus protocols are
evaluated thoroughly for incompatibility with privacy. In the
meantime, please try to establish whether your finding is either
green - no conflict, yellow - possible/unsure, or red - clear
conflict.

[Caleb Davis]

**webfinger**
Either your account is discoverable or not. If my instance is
hosted at mediagoblin.cfdv.zzz, member dev\_user's URI is something
like
`dev\_user@mediagoblin.cfdv.zzz <mailto:dev_user@mediagoblin.cfdv.zzz>`_.
A query on the URI given a template
(`http://mediagoblin.cfdv.zzz/?uri=[uri] <http://mediagoblin.cfdv.zzz/?uri=[uri]>`_)
provides the appropriate links to dev\_user's feeds.

GREEN - webfinger is as private as any email address.
`http://code.google.com/p/webfinger/wiki/WebFingerProtocol <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>`_

[Caleb Davis]

**pubsubhubbub (push)**
The publisher and the subscriber each have a push server that may
or may not be co-located with the users' account hosts. The
publisher server is told by the publisher when a new update is
available. Subscribers register themselves on the publisher's
server for access to individual publisher feeds. Those subscribers
to the publisher's feed receive notifications of the update via the
subscriber's server. The subscriber's server is handling the user's
subscriptions across the web.

`http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html <http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html>`_

GREEN - sections 1-8
YELLOW - section 9:

*9. Update publication*

*The publisher server uses PubSubHubbub [push] to notify subscribers of new updates.*

*If multiple subscribers using the same subscriber server subscribe to the same publisher, the subscriber server SHOULD use the one PubSubHubbub subscription for all of them.*

**two users on the same subscriber server 'following' the same publisher account SHOULD receive the same content, regardless of publisher's wishes.**
The keyword SHOULD means we can ignore the rule as long as we
understand the consequences. Not sure what those would be yet.

[Elrond]

The wiki is ready!

I think, the content in here should be migrated there?

Under what page? "Devel/OStatus\_vs\_Permissions"?

[Christopher Allan Webber]

We can move conversation there. Although it looks like the OStatus
people will be addressing this directly very soon:
`https://groups.google.com/group/ostatus-discuss/browse\_thread/thread/7f15df316d6c14d3 <https://groups.google.com/group/ostatus-discuss/browse_thread/thread/7f15df316d6c14d3>`_

Maybe we don't need to do too much personal research now as they
will be doing this already, or we can focus our research on working
with them directly?

[Elrond]

I think, the wiki is better for documenting the results, not for
actual discussions/converstations. For example the result, that
webfinger is no problem and could be implemented right away without
any issues.

The bug/issue seems fine for discussions though.

[Caleb Davis]

The Federated Social Web 2011 conference was last month in Germany,
and I did not go. :\`(

But, all is not lost! I'm watching some of the presentations
tonight, and I was very happy to see this privacy federation
workshop -
`http://d-cent.org/fsw2011/w3c-workshop-33-privacy-on-the-federated-social-web/ <http://d-cent.org/fsw2011/w3c-workshop-33-privacy-on-the-federated-social-web/>`_.
There is a speaker addressing OStatus privacy from 26:00 - 30:40.

EDIT: the next speaker (~31:00-39:00) provides the distinction
between proactive and reactive privacy controls. He's calling for
systems to monitor the flow of personal data through a federated
social network, so that, not only can you decide who gets to see
your stuff, but you also get to see where your stuff went
afterwards. EDIT: AKA DRM for social data

EDIT: at (1:14:24) I stopped for now.

[Caleb Davis]

julia anaya's post today on the pubsubhubbub list draws attention
to a white paper relevant to private push.

thread -
`http://groups.google.com/group/pubsubhubbub/browse\_thread/thread/27a2eaae99f2c584 <http://groups.google.com/group/pubsubhubbub/browse_thread/thread/27a2eaae99f2c584>`_
white paper -
`http://www.google.com/url?sa=D&q=http://d-cent.org/fsw2011/wp-content/uploads/fsw2011-SMOB-The-best-of-both-worlds.pdf <http://www.google.com/url?sa=D&q=http://d-cent.org/fsw2011/wp-content/uploads/fsw2011-SMOB-The-best-of-both-worlds.pdf>`_

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/428 .

[Christopher Allan Webber]

We're moving to the pump API and this is irrelevant in that future.