Opened 12 years ago
Closed 10 years ago
#138 closed defect (wontfix)
ostatus breaks permissions and vice versa
|Reported by:||Caleb Davis||Owned by:|
Description (last modified by )
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 , 12 years ago
comment:2 by , 12 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 <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 , 12 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 , 12 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 <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 , 12 years ago
|Status:||New → In 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 , 12 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/ <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 , 12 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 <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 by , 11 years ago
The original url for this bug was http://bugs.foocorp.net/issues/428 .
comment:9 by , 10 years ago
|Status:||assigned → closed|
We're moving to the pump API and this is irrelevant in that future.
Note: See TracTickets for help on using tickets.