Opened 15 years ago

Closed 13 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.

Change History (9)

comment:1 by Caleb Davis, 15 years ago

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. A query on the URI given a template (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

comment:2 by Caleb Davis, 15 years ago

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

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 by Elrond, 15 years ago

The wiki is ready!

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

Under what page? "Devel/OStatus_vs_Permissions"?

comment:4 by Christopher Allan Webber, 15 years ago

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

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 by Elrond, 15 years ago

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 by Caleb Davis, 15 years ago

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/. 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 by Caleb Davis, 15 years ago

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 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

comment:8 by Will Kahn-Greene, 14 years ago

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

comment:9 by Christopher Allan Webber, 13 years ago

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.