Opened 12 years ago

Closed 10 years ago

#138 closed defect (wontfix)

ostatus breaks permissions and vice versa

Reported by: Caleb Davis Owned by:
Priority: minor Milestone:
Component: programming Keywords:
Cc: Parent Tickets:

Description (last modified by Christopher Allan Webber)

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.



Subtickets

Change History (9)

comment:1 Changed 12 years ago by 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>`_



comment:2 Changed 12 years ago by 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.



comment:3 Changed 12 years ago by Elrond

The wiki is ready!

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

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



comment:4 Changed 12 years ago by 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?



comment:5 Changed 12 years ago by Elrond

Status: NewIn Progress
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.



comment:6 Changed 12 years ago by 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.



comment:7 Changed 11 years ago by 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>`_



comment:8 Changed 11 years ago by Will Kahn-Greene

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

comment:9 Changed 10 years ago by Christopher Allan Webber

Component: programming
Description: modified (diff)
Resolution: wontfix
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.