![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
RFC: Multiple Account Model
So, one of the things we want to do -- and it's a project that has gotten some developer interest lately -- is make it so that you can associate/link accounts together, so (for instance) you can switch to commenting or posting as your alternate/secondary/fic/RP/whatever journal more easily than logging out and logging back in. We've done some work to spec the problem, but I figured it would be time to toss it out to you guys here and see what other things we've forgotten to think of and what use cases we don't know about yet!
More discussion on the problem can be found at Bug 76. Here are two of the documents that have been written to try to "spec out" the project. Please read them over if you have a chance, and give your feedback.
Draft spec, written by cesy
From one of the manage settings pages, have "manage secondary accounts"
On new manage secondary accounts page, have:
Create a new secondary account - standard flow, but is automatically already connected, and gets created with all the same settings as your primary account
Link an existing account to this one (requires password to the other account)
Unlink one of the secondary accounts from the primary account (has a large and obvious "Are you sure about that?" message)
An option to show/hide links between accounts - can display list of secondary accounts on primary profile, and link to primary profile on secondary profiles
An option to select which account is the primary journal - the primary journal will be default on things like the update page and when commenting
Other pages that will need updating:
Shop - as well as "buy paid time for me" and "buy paid time for another user", need "buy paid time for my secondary account(s)" (which might be discounted)
Edit profile drop-down should list all secondary accounts, as should customize style, manage filters, edit userpics, etc.
Update.bml needs both "post to journal" drop-down (includes all comms and all accounts) and "post as" drop-down (which is disabled if the secondary account can't post to that comm, and defaults to match the journal selected). "Post as" doesn't display unless you have secondary journals.
All comment boxes would need a drop-down to choose who to work as. Ideally this would show normally, not require clicking the "Other"/"More options" button. This should also not display for people who don't have secondary journals.
On options/settings pages, at the bottom, instead of just "Save", have "Save for this journal" and "Save for all journals" (but only if the user has a secondary journal, otherwise leave it as just "Save".)
Other notes:
If someone has given access to any one of your accounts, and you go to their journal, you see the locked entries.
If someone has given access to only one of your accounts, and you subscribe to them from another account, what happens when you look at the reading page of that account? Do you see the locked entries or not?
If you click to subscribe, unsubscribe, grant or remove access or join or leave a community and you get the usual confirmation page, that should include a "Do this as which account?" thing.
The pop-up hover menus should behave as usual for the main account, and ignore secondary accounts.
Can secondary accounts have different email addresses?
Creating a secondary account should require an invite code?
Have a careful think about transferring a secondary account from one primary account to another.
Further considerations, written by tyggerjai
Goal: To streamline management of multiple journals and journal features for a single user account. Mostly involving addition of “Manage accounts” interface, but with implications for ban settings, reading pages, and access lists.
Background:
[A note on terminology: Part of the current issue is that there is a conflation of a “journal” with an “account”. An “account” represents a human being, but it has become obvious that many DW users want and have multiple journals. This entire project stems from the fact that accounts and journals, while historically identical, are de facto different things. Discussion of which things are “account” based (login, killfiles, subscription, access to someone else's journal) and which things are “journal” based (tags, entries, access to read one of my journals) are probably beyond scope for this bug (although see “Potential problems” at the end). I shall use the term “journal” in this document unless I wish to make a point about the distinction, because at the moment, journal is the paradigm we have to work with.]
Annabel has a Dreamwidth journal – dw_annabel – which she started when she first found Dreamwidth. It has mostly personal updates about her life, but she doesn't talk about her work. Mostly because her mother reads the dw_annabel journal, and rather than maintain access lists, or risk having her mother find out what she actually does for a living, Annabel maintains another journal for her work stories – work_annabel. Recently, Annabel has discovered the joy of writing speculative fiction, so she has started another journal, fic_annabel, for working on a novel. She's co-writing it with her friend Boris, so Boris also has the password for that journal. Annabel is growing increasingly weary of constantly logging in and out to post on various journals, and she would like the following:
1)When she is logged in as “dw_annabel”, which she considers her “primary” account, she'd like to be able to manage all her journals from the management interface. Everything she can do to dw_annabel (style, circle management, privacy management, etc), she wants to do from one central screen as dw_annabel. It'd even be nice if she could choose to apply to things like screenings to all her journals at once, although she'd need to be able to change settings per-journal as well.
2)She'd like to be able to subscribe to some other journals via her personal journal, and some via her work journal (so that her mother never knows about them!). But she'd like to read them on the same page – one central reading page. She'd still like to be able to filter, though – for her fiction, sometimes she just wants to read fic_annabel's reading page.
3)Similarly, when she's reading as dw_annabel, she would like to read any post that has given access to her work_annabel or fic_annabel journals.
4)She'd like a link to the fic_annabel journal to show up on the profile for dw_annabel, and vice versa, as being her journals. But under no circumstances should her mother be able to discover a connection between dw_annabel and work_annabel!
5)Recently, she had someone making unpleasant comments in fic_annabel, and has banned them. She'd like that ban to be applied across all her journals – fic_annabel, dw_annabel and work_annabel. Just in case. But she'd also like to be able to revoke that ban just on fic_annabel, in case it turns out she's banned Boris.
6)When she goes to make a post she definitely needs to be able to choose which journal to post to. When she goes to leave a comment in she needs to be able to choose whether it shows up as a post from dw_annabel, fic_annabel, or annabel_work. She doesn't want to “log in” as fic_annabel – fic_annabel isn't a person, and she can do everything she needs to do to manage the fic_annabel journal as dw_annabel.
7)She can see a day, possibly soon, when she will grow weary of the fic_annabel story. She'd like to know that when the time comes, she can hand it off to Boris and untangle herself from it.
8)When she does that, she'll probably want to start another journal for her own fiction. She should be able to do that as dw_annabel, give it a new name, and start using it, without ever having to log in, log out, or otherwise manually tell the DW system that she owns it.
That's about all Annabel wants to do, really....
Skillsets: Everything and then some. This is backend, frontend, graphical, UX, business, scalability, and some things I haven't thought of yet.
Requirements:
[Another note on terminology. “Link” is somewhat overloaded here, since it can refer either to a managerial connection between to accounts, or a visible “a href=” on a profile page. I'll reserve “link” for the visible connection, and use “associate” for the higher level managerial connection.]
1)The project MUST provide a method of associating journals, with a single signon to edit and maintain them. Whether we call it “primary/secondary”, or “one account, many journals”, the heart of this project is the ability to log in as dw_annabel and modify fic_annabel and work_annabel. That has two components:
a) Migration of existing journals. It MUST be possible for a user with multiple journals to declare one of them a “primary” journal, and associate other existing journals with it.
b) Creation of future journals. It SHOULD be possible, once this project is implemented, to create journals with automatic association to an existing primary. (NB. This is a should because migration is a must, and if we have that, users can create and then migrate. Realistically, though, it's a “really should”.)
2)The project MUST provide a method for managing linked journals from a single central interface. This interface MUST replicate the current management functionality for each associated journal without requiring log out/log in for that journal account, if the user is logged in with their primary account credentials. This interface SHOULD provide the ability to apply changes to multiple journals at once, but if it does so, it MUST retain the ability to override settings on a per-journal basis.
3)The project SHOULD provide a single central reading page for the primary account, which will incorporate all journals to which all associated journals are subscribed. Such an interface SHOULD include locked posts to which any associated journal has access. However, if such an interface is present, it MUST be possible to filter that reading page on a per journal basis (i.e., if a user should be able to remove a given journals subscriptions from that central page). The project MUST maintain individual journal reading lists [that's more for backwards compatibility and privacy – I can currently go to work_annabel and see that reading list. It shouldn't suddenly show me dw_annabel's reading list.]
4)The project SHOULD allow a user to declare associations between journals as “Public” or “Private”. For “Public” associations, links SHOULD be shown on the profile pages of associated journals. Whether this is implemented or not, the project MUST NOT allow other users to see evidence of association between journals UNLESS the owner has explicitly declared the association public.
5)The project SHOULD allow a user to implement bans that apply to all associated journals. If implemented, this feature MUST allow a user to then rescind any given ban on any individual journal.
6)The project SHOULD implement the ability to easily select a journal to post TO when updating. The project SHOULD implement the ability to easily choose a journal to past AS when commenting on a journal. [Note: These are only shoulds because we will almost certainly retain the account/journal conflation, and therefore in theory it's possible to log out and in again. I think the focus of this bug is really the management, and this posting interface is gravy, but it's important gravy]. If implemented, the commenting interface SHOULD restrict the choice to journal identities with commenting privileges, and MUST NOT allow journal identities to comment when they are not privileged to do so. That is, if journal annabels_friend has restricted commenting access, and allows comments only from dw_annabel, the interface MUST NOT allow annabel to comment as fic_annabel or work_annabel.
7)The project SHOULD implement a mechanism for removing an associated journal. Once removed, a journal will behave like any other non-associated journal.
8)The project MAY implement the ability to “sub-associate” journals with other users. That is, while ultimate control of the account rests with the creator, they can grant other users the ability to post to the journal, or post as the journal identity, change settings, etc, without giving the other user password access. The other user MUST NOT inherit access to posts that the journal identity has been granted. (i.e., Annabel gives Boris post and edit privs to fic_annabel. Boris's reading list still does not contain items from fic_annabel's subscriptions, nor can he see items to which fic_annabel has been granted. He can, however, post as fic_annabel ). See “Potential problems” :)
Potential Problems: Where do I start? On the bright side, I think most of our problems are social rather than technical.
1)Migrating accounts. I included the shared account with Boris for a reason. Let's say we're as restrictive as possible, and the following is required to migrate an account:
a) You must have access to both email addresses, to reply to “confirm” emails. You must know the password for both accounts.
Ok. But Boris has the password, and the email address for that account is a shared one. So even once Annabel has migrated, Boris can just remigrate it. This is a problem with the existing paradigm – because journals and accounts are the same, passwords are the only control mechanism. There's no way of knowing Annabel created the account. I think that for the moment we put this in the “too hard” basket, and say “Social problem, sort it out yourselves”. We lock it down so you can only migrate an account if you have both passwords, and can respond to emails sent to both accounts. There's really not much else we can do. ( as an aside, this is the classic example of why the “single account, multiple journals” is a better long-term paradigm, but this is almost a de facto implementation of that). After a journal has been migrated, do we have a complaints resolution process for Boris to say “Hey, she stole my journal”? I don't know that we need one – what's our current procedure for people sharing passwords and then one of them changing it to lock someone else out?
2)To be honest, everything else just looks like hard work. We really, really have to make sure that the commenting interface enforces identity restriction. If you have a locked post that tyggerjai can comment on, we DO NOT let tyggerdev comment on it, even though they're the same “person”. That's the ultimate UX nono, as far as I can see.
3)Oh. Sub-association. That's down the end as a “may” because although it's a huge, huge advantage that the “Association” paradigm has over the password paradigm, it's the biggest can of worms. It's almost a whole other specification on its own. But the main points, I think, are there. Give Boris edit/post access, but restrict privacy inheritance to the original owner. There's one massive thing preventing the implementation of subassociation, though, and that's what happens if Annabel then removes her association with fic_annabel. Does Boris then inherit the access as the new owner? Does dw_annabel keep the access, and if so, with which journal do we associate it? None of this is worse than our existing paradigm with passwords – in fact, it's a lot better, because if we do need to, we can suspend fic_annabel's access to everything, send emails out to people who have given fic_annabel access saying “This journal is changing owner! If you know the new owner and you're cool with it, click here to retain their access rights. If you don't know the new owner, click here to send an email to the old owner, so they can get in touch with you to arrange new access. Or, if this is freaking you out, click here to revoke the journal's access to your journal for good.”. But this is exactly the kind of thing that makes users nervous, and that we have to have a plan for. So at the moment, it's an itty bitty “may”, and if users want to hand a journal over to someone else, they can disassociate, give the new owner the email, and move on from there. But I think we may still need to handle the access notification in that case, simply because by implementing association, we give the impression that we're moving from “Anyone could have the password to this journal so be careful” to “No, your friend owns this journal, it's fine! “
4)Actually, all of that, again, regardless of subassociation: by implementing association, we give the impression that we're moving from “Anyone could have the password to this journal so be careful” to “No, your friend owns this journal, it's fine!”. Which, of course, we're not – journals will still have passwords, and other people may still know them. We could go all the way, and break the map between journals and accounts once and for all, so journals don't have passwords, but that's a much bigger project, I think.
5)Preselecting identities to comment as based on a post's access rules is going to suck. Just saying :)
Anyway. This section should probably be much longer, but I've left it as an Exercise For The Reader, since you know your community better than I do at the moment. I think the biggest problems are social – that associating journals with users sets up an interesting disconnect – if I give tyggerdev access because I've read it and I'm interested in the dev stuff, then if the owner of tyggerdev decides he's sick of coding, but gives the journal to someone else, I don't really care. I had no investment in the person. On the other hand, maybe I did – maybe I gave tyggerdev access to my journal because I know the owner. So then when he gives it away, I'm shattered! I don't know this person! What's going on!? Again, it's no worse than the existing password-sharing shenanigans in terms of actual security, only in terms of perception. And it's only a problem ever if we let people give journals away.
So! What thoughts does this inspire in you?
More discussion on the problem can be found at Bug 76. Here are two of the documents that have been written to try to "spec out" the project. Please read them over if you have a chance, and give your feedback.
Draft spec, written by cesy
From one of the manage settings pages, have "manage secondary accounts"
On new manage secondary accounts page, have:
Create a new secondary account - standard flow, but is automatically already connected, and gets created with all the same settings as your primary account
Link an existing account to this one (requires password to the other account)
Unlink one of the secondary accounts from the primary account (has a large and obvious "Are you sure about that?" message)
An option to show/hide links between accounts - can display list of secondary accounts on primary profile, and link to primary profile on secondary profiles
An option to select which account is the primary journal - the primary journal will be default on things like the update page and when commenting
Other pages that will need updating:
Shop - as well as "buy paid time for me" and "buy paid time for another user", need "buy paid time for my secondary account(s)" (which might be discounted)
Edit profile drop-down should list all secondary accounts, as should customize style, manage filters, edit userpics, etc.
Update.bml needs both "post to journal" drop-down (includes all comms and all accounts) and "post as" drop-down (which is disabled if the secondary account can't post to that comm, and defaults to match the journal selected). "Post as" doesn't display unless you have secondary journals.
All comment boxes would need a drop-down to choose who to work as. Ideally this would show normally, not require clicking the "Other"/"More options" button. This should also not display for people who don't have secondary journals.
On options/settings pages, at the bottom, instead of just "Save", have "Save for this journal" and "Save for all journals" (but only if the user has a secondary journal, otherwise leave it as just "Save".)
Other notes:
If someone has given access to any one of your accounts, and you go to their journal, you see the locked entries.
If someone has given access to only one of your accounts, and you subscribe to them from another account, what happens when you look at the reading page of that account? Do you see the locked entries or not?
If you click to subscribe, unsubscribe, grant or remove access or join or leave a community and you get the usual confirmation page, that should include a "Do this as which account?" thing.
The pop-up hover menus should behave as usual for the main account, and ignore secondary accounts.
Can secondary accounts have different email addresses?
Creating a secondary account should require an invite code?
Have a careful think about transferring a secondary account from one primary account to another.
Further considerations, written by tyggerjai
Goal: To streamline management of multiple journals and journal features for a single user account. Mostly involving addition of “Manage accounts” interface, but with implications for ban settings, reading pages, and access lists.
Background:
[A note on terminology: Part of the current issue is that there is a conflation of a “journal” with an “account”. An “account” represents a human being, but it has become obvious that many DW users want and have multiple journals. This entire project stems from the fact that accounts and journals, while historically identical, are de facto different things. Discussion of which things are “account” based (login, killfiles, subscription, access to someone else's journal) and which things are “journal” based (tags, entries, access to read one of my journals) are probably beyond scope for this bug (although see “Potential problems” at the end). I shall use the term “journal” in this document unless I wish to make a point about the distinction, because at the moment, journal is the paradigm we have to work with.]
Annabel has a Dreamwidth journal – dw_annabel – which she started when she first found Dreamwidth. It has mostly personal updates about her life, but she doesn't talk about her work. Mostly because her mother reads the dw_annabel journal, and rather than maintain access lists, or risk having her mother find out what she actually does for a living, Annabel maintains another journal for her work stories – work_annabel. Recently, Annabel has discovered the joy of writing speculative fiction, so she has started another journal, fic_annabel, for working on a novel. She's co-writing it with her friend Boris, so Boris also has the password for that journal. Annabel is growing increasingly weary of constantly logging in and out to post on various journals, and she would like the following:
1)When she is logged in as “dw_annabel”, which she considers her “primary” account, she'd like to be able to manage all her journals from the management interface. Everything she can do to dw_annabel (style, circle management, privacy management, etc), she wants to do from one central screen as dw_annabel. It'd even be nice if she could choose to apply to things like screenings to all her journals at once, although she'd need to be able to change settings per-journal as well.
2)She'd like to be able to subscribe to some other journals via her personal journal, and some via her work journal (so that her mother never knows about them!). But she'd like to read them on the same page – one central reading page. She'd still like to be able to filter, though – for her fiction, sometimes she just wants to read fic_annabel's reading page.
3)Similarly, when she's reading as dw_annabel, she would like to read any post that has given access to her work_annabel or fic_annabel journals.
4)She'd like a link to the fic_annabel journal to show up on the profile for dw_annabel, and vice versa, as being her journals. But under no circumstances should her mother be able to discover a connection between dw_annabel and work_annabel!
5)Recently, she had someone making unpleasant comments in fic_annabel, and has banned them. She'd like that ban to be applied across all her journals – fic_annabel, dw_annabel and work_annabel. Just in case. But she'd also like to be able to revoke that ban just on fic_annabel, in case it turns out she's banned Boris.
6)When she goes to make a post she definitely needs to be able to choose which journal to post to. When she goes to leave a comment in she needs to be able to choose whether it shows up as a post from dw_annabel, fic_annabel, or annabel_work. She doesn't want to “log in” as fic_annabel – fic_annabel isn't a person, and she can do everything she needs to do to manage the fic_annabel journal as dw_annabel.
7)She can see a day, possibly soon, when she will grow weary of the fic_annabel story. She'd like to know that when the time comes, she can hand it off to Boris and untangle herself from it.
8)When she does that, she'll probably want to start another journal for her own fiction. She should be able to do that as dw_annabel, give it a new name, and start using it, without ever having to log in, log out, or otherwise manually tell the DW system that she owns it.
That's about all Annabel wants to do, really....
Skillsets: Everything and then some. This is backend, frontend, graphical, UX, business, scalability, and some things I haven't thought of yet.
Requirements:
[Another note on terminology. “Link” is somewhat overloaded here, since it can refer either to a managerial connection between to accounts, or a visible “a href=” on a profile page. I'll reserve “link” for the visible connection, and use “associate” for the higher level managerial connection.]
1)The project MUST provide a method of associating journals, with a single signon to edit and maintain them. Whether we call it “primary/secondary”, or “one account, many journals”, the heart of this project is the ability to log in as dw_annabel and modify fic_annabel and work_annabel. That has two components:
a) Migration of existing journals. It MUST be possible for a user with multiple journals to declare one of them a “primary” journal, and associate other existing journals with it.
b) Creation of future journals. It SHOULD be possible, once this project is implemented, to create journals with automatic association to an existing primary. (NB. This is a should because migration is a must, and if we have that, users can create and then migrate. Realistically, though, it's a “really should”.)
2)The project MUST provide a method for managing linked journals from a single central interface. This interface MUST replicate the current management functionality for each associated journal without requiring log out/log in for that journal account, if the user is logged in with their primary account credentials. This interface SHOULD provide the ability to apply changes to multiple journals at once, but if it does so, it MUST retain the ability to override settings on a per-journal basis.
3)The project SHOULD provide a single central reading page for the primary account, which will incorporate all journals to which all associated journals are subscribed. Such an interface SHOULD include locked posts to which any associated journal has access. However, if such an interface is present, it MUST be possible to filter that reading page on a per journal basis (i.e., if a user should be able to remove a given journals subscriptions from that central page). The project MUST maintain individual journal reading lists [that's more for backwards compatibility and privacy – I can currently go to work_annabel and see that reading list. It shouldn't suddenly show me dw_annabel's reading list.]
4)The project SHOULD allow a user to declare associations between journals as “Public” or “Private”. For “Public” associations, links SHOULD be shown on the profile pages of associated journals. Whether this is implemented or not, the project MUST NOT allow other users to see evidence of association between journals UNLESS the owner has explicitly declared the association public.
5)The project SHOULD allow a user to implement bans that apply to all associated journals. If implemented, this feature MUST allow a user to then rescind any given ban on any individual journal.
6)The project SHOULD implement the ability to easily select a journal to post TO when updating. The project SHOULD implement the ability to easily choose a journal to past AS when commenting on a journal. [Note: These are only shoulds because we will almost certainly retain the account/journal conflation, and therefore in theory it's possible to log out and in again. I think the focus of this bug is really the management, and this posting interface is gravy, but it's important gravy]. If implemented, the commenting interface SHOULD restrict the choice to journal identities with commenting privileges, and MUST NOT allow journal identities to comment when they are not privileged to do so. That is, if journal annabels_friend has restricted commenting access, and allows comments only from dw_annabel, the interface MUST NOT allow annabel to comment as fic_annabel or work_annabel.
7)The project SHOULD implement a mechanism for removing an associated journal. Once removed, a journal will behave like any other non-associated journal.
8)The project MAY implement the ability to “sub-associate” journals with other users. That is, while ultimate control of the account rests with the creator, they can grant other users the ability to post to the journal, or post as the journal identity, change settings, etc, without giving the other user password access. The other user MUST NOT inherit access to posts that the journal identity has been granted. (i.e., Annabel gives Boris post and edit privs to fic_annabel. Boris's reading list still does not contain items from fic_annabel's subscriptions, nor can he see items to which fic_annabel has been granted. He can, however, post as fic_annabel ). See “Potential problems” :)
Potential Problems: Where do I start? On the bright side, I think most of our problems are social rather than technical.
1)Migrating accounts. I included the shared account with Boris for a reason. Let's say we're as restrictive as possible, and the following is required to migrate an account:
a) You must have access to both email addresses, to reply to “confirm” emails. You must know the password for both accounts.
Ok. But Boris has the password, and the email address for that account is a shared one. So even once Annabel has migrated, Boris can just remigrate it. This is a problem with the existing paradigm – because journals and accounts are the same, passwords are the only control mechanism. There's no way of knowing Annabel created the account. I think that for the moment we put this in the “too hard” basket, and say “Social problem, sort it out yourselves”. We lock it down so you can only migrate an account if you have both passwords, and can respond to emails sent to both accounts. There's really not much else we can do. ( as an aside, this is the classic example of why the “single account, multiple journals” is a better long-term paradigm, but this is almost a de facto implementation of that). After a journal has been migrated, do we have a complaints resolution process for Boris to say “Hey, she stole my journal”? I don't know that we need one – what's our current procedure for people sharing passwords and then one of them changing it to lock someone else out?
2)To be honest, everything else just looks like hard work. We really, really have to make sure that the commenting interface enforces identity restriction. If you have a locked post that tyggerjai can comment on, we DO NOT let tyggerdev comment on it, even though they're the same “person”. That's the ultimate UX nono, as far as I can see.
3)Oh. Sub-association. That's down the end as a “may” because although it's a huge, huge advantage that the “Association” paradigm has over the password paradigm, it's the biggest can of worms. It's almost a whole other specification on its own. But the main points, I think, are there. Give Boris edit/post access, but restrict privacy inheritance to the original owner. There's one massive thing preventing the implementation of subassociation, though, and that's what happens if Annabel then removes her association with fic_annabel. Does Boris then inherit the access as the new owner? Does dw_annabel keep the access, and if so, with which journal do we associate it? None of this is worse than our existing paradigm with passwords – in fact, it's a lot better, because if we do need to, we can suspend fic_annabel's access to everything, send emails out to people who have given fic_annabel access saying “This journal is changing owner! If you know the new owner and you're cool with it, click here to retain their access rights. If you don't know the new owner, click here to send an email to the old owner, so they can get in touch with you to arrange new access. Or, if this is freaking you out, click here to revoke the journal's access to your journal for good.”. But this is exactly the kind of thing that makes users nervous, and that we have to have a plan for. So at the moment, it's an itty bitty “may”, and if users want to hand a journal over to someone else, they can disassociate, give the new owner the email, and move on from there. But I think we may still need to handle the access notification in that case, simply because by implementing association, we give the impression that we're moving from “Anyone could have the password to this journal so be careful” to “No, your friend owns this journal, it's fine! “
4)Actually, all of that, again, regardless of subassociation: by implementing association, we give the impression that we're moving from “Anyone could have the password to this journal so be careful” to “No, your friend owns this journal, it's fine!”. Which, of course, we're not – journals will still have passwords, and other people may still know them. We could go all the way, and break the map between journals and accounts once and for all, so journals don't have passwords, but that's a much bigger project, I think.
5)Preselecting identities to comment as based on a post's access rules is going to suck. Just saying :)
Anyway. This section should probably be much longer, but I've left it as an Exercise For The Reader, since you know your community better than I do at the moment. I think the biggest problems are social – that associating journals with users sets up an interesting disconnect – if I give tyggerdev access because I've read it and I'm interested in the dev stuff, then if the owner of tyggerdev decides he's sick of coding, but gives the journal to someone else, I don't really care. I had no investment in the person. On the other hand, maybe I did – maybe I gave tyggerdev access to my journal because I know the owner. So then when he gives it away, I'm shattered! I don't know this person! What's going on!? Again, it's no worse than the existing password-sharing shenanigans in terms of actual security, only in terms of perception. And it's only a problem ever if we let people give journals away.
So! What thoughts does this inspire in you?
no subject
Shared access = massive security hole
mybestfriend has access to every filter I use. She co-mods notmyfandom_kinkmeme with somebodyIdon'tknow, somebodyelse, somethirdperson, and myworstenemy, using notmyfandom_kinkmeme_mod.
For administrative reasons, notmyfandom_kinkmeme_mod is associated as a secondary journal with mybestfriend as the primary journal, and because it's important for that mod journal to be anonymous, it does not show which journal is its primary journal on the userinfo page, nor does mybestfriend list it on her userinfo page. And because it's not my fandom, or because she is the kind of mod who really doesn't talk about the fact that she co-mods the comm, or because she doesn't want to start drama by explaining that she co-mods a comm with myworstenemy, I do not know who the rest of the mods that can log in as that account are. And I certainly don't know that myworstenemy can log in as that account.
But if all accounts listed as secondary to a primary account have all the same reading access permissions that the primary account does, notmyfandom_kinkmeme_mod now has access to everything I have ever written, and there's no way for me to know that notmyfandom_kinkmeme_mod even has access to my journal. And because notmyfandom_kinkmeme_mod now has access to everything I have ever written, myworstenemy has access to everything I have ever written.
So do somebodyIdon'tknow, somebodyelse, and somethirdperson, for that matter. In short, a number of people I have not explicitly granted access to can now access my journal anyway, and most importantly, I have no way of finding out who they are or how many of them they are.
This is absolutely huge, and would pretty much make me dump almost everyone I currently have on my access lists right off my access lists, and I'd probably end up going back to InsaneJournal to post sensitive stuff, because honestly, some of my best friends do share mod journals with people I don't know (I mean, not actually myworstenemy, but I would just as soon not talk about $super_private_thing with someoneIdon'tknow, you know?). And this is not the end result I think Dreamwidth is looking for.
Re: Shared access = massive security hole
Access inherits the other way. If you grant access to notmyfandom_kinkmeme_mod, then anyone who is a primary of notmyfandom_kinkmeme_mod would be able to see those posts. Because they could just log in as notmyfandom_kinkmeme_mod anyway.
But if you grant access specifically to mybestfriend, then notmyfandom_kinkmeme_mod has *no* idea about that.
Secondary journals do not inherit the access privileges of other secondary journals or their primary. The primary journal reading list, if aggregated, shows all posts to which secondary accounts have access, because "you" have access to them anyway, just by logging out and in again.
Anyone with "privileges" on notmykink_meme_mod can see posts to which notmykink_meme_mod has specifically been given access, plus whatever access their own accounts have. Or at least that's how I envisage it :)
It's why the "shared journal" thing is a big can can of worms, though. I might draw up a chart of the inheritances as I see them, because certainly the scenario as you describe it would be horrible.
Re: Shared access = massive security hole
To be honest, shared journals are probably not going to make the cut for version 1, for this and other reasons.
Re: Shared access = massive security hole
Re: Shared access = massive security hole
I'm way open to ideas. What I'm trying to avoid here is making a user jump through hoops to get at data they have already "authenticated" for. If you're logged in as dw_annabel, and fic_annabel is associated with that, then by definition you can read posts to which fic_annabel has access. Because by definition you had to have full privileges on fic_annabel to associate them. So why does the system make you log out and in, or even switch identities, when it knows "you" have access rights?
Re: Shared access = massive security hole
It makes sense from that end! And with a bunch of people granting access to a journal which I state in my userinfo I don't read from, and don't subscribe to anyone, I know a lot of people grant access to obviously not-being-used-as-a-personal-journal journals, and there's nothing to be done about that (in other words, someone who grants access to $really_personal_filter to some_mod_journal should be rethinking their access policy, not the policy of who can read what where).
On the other hand, I do wonder a bit about the promotion of and passing around of secondary accounts. Thinking about it some...
I start off with MY_JOURNAL, to which I post fiction, code, meta, personal stuff, and other things. But I decide I'm just going to use MY_JOURNAL for fiction, and I start MY_PERSONAL for personal stuff, and I make MY_PERSONAL my primary with MY_JOURNAL as my secondary. People may or may not revoke access on MY_JOURNAL (they should! but they probably don't!). Now MY_PERSONAL has access to anything that MY_JOURNAL still has access to.
A while later, I begin a cowriting relationship with someone who wishes to remain anonymous, and I end up sharing access to MY_JOURNAL with ANON_USER. Because he wishes to remain anonymous, I don't list it on the profile. If I'm a nice person, I might say "heads up -- I'm now going to share this journal with someone else, but I can't tell you who, because he wishes to remain anonymous." Hopefully everyone revokes access to that journal at that point! Hopefully! But probably not. And I might just not say anything at all (okay, I would say something, but many people wouldn't think it was necessary). Either way, now all those legacy people who granted access to MY_JOURNAL have also managed to grant access to ANON_USER, without knowing who he is or that he has access to those posts of theirs.
On one hand, I kind of feel like this is the sort of thing that people should be looking after themselves -- if you grant someone access, you should probably keep an eye on them to make sure they haven't changed the purpose of their journal, that they didn't make it a secondary journal, and so on. On the other hand, there's no reason in the world that people would ever know that the circumstances under which they granted access are now different (I assume that if a journal becomes a secondary, it doesn't send a message to all the accounts that grant it access that it is now a secondary, and if it becomes shared, it probably doesn't send a message to all the accounts that grant it access that it is now shared -- I mean, thank God my accounts don't tell everyone to whom I've granted access when I change my email address, because I would've spammed 70-odd people four times in one week at one point *g*), and that just plain still seems risky to me.
I'm not sure it's a risk DW needs to help mediate (unlike the leak where if PRIMARY1 has access to USER, then SECONDARY1 has access to USER, and if SECONDARY1 is shared with PRIMARY2, then PRIMARY2 has access to USER, which was a terrifying thought and one I'm glad isn't in the works!), but it's definitely a concern for me.
Ultimately, I think it is a good idea to make people explicitly change identities in order to access things that only one identity has access to, really, because it prevents DW from being in the very unfortunate position of automatically transferring access between accounts without alerting the access-granter that the transfer is occurring. DW may know that "you" are "you", but I'm just terribly uneasy with the notion that DW would be, behind the scenes, transferring a grant of access to journals that were not themselves explicitly granted access. (Yes, you'd be able to get them anyway -- and the hoop of an extra click to switch accounts is not a very big one -- but I really, really like the idea of a distinction between DW allowing you to change identies and DW transferring access around.)
But we'll see how this shakes down! I may be fixating on this because I have a security-oriented brain. ;)
Re: Shared access = massive security hole
"None of this is worse than our existing paradigm with passwords – in fact, it's a lot better, because if we do need to, we can suspend fic_annabel's access to everything, send emails out to people who have given fic_annabel access saying “This journal is changing owner! If you know the new owner and you're cool with it, click here to retain their access rights. If you don't know the new owner, click here to send an email to the old owner, so they can get in touch with you to arrange new access. Or, if this is freaking you out, click here to revoke the journal's access to your journal for good.”. But this is exactly the kind of thing that makes users nervous, and that we have to have a plan for. So at the moment, it's an itty bitty “may”, and if users want to hand a journal over to someone else, they can disassociate, give the new owner the email, and move on from there. But I think we may still need to handle the access notification in that case, simply because by implementing association, we give the impression that we're moving from “Anyone could have the password to this journal so be careful” to “No, your friend owns this journal, it's fine! “"
So with your example, we could totally temporarily suspend MY_JOURNAL's access to everything - we'd let you know about it before you share the journal, have a workflow that gives you a big popup saying "Once you do this, you will still be able to post to this journal, and read the journal reading list, but locked posts to which this journal used to have access will no longer be displayed. Are you ok with that!?". And then we could send out emails to people who've given it access, and work it out from there, preserving as much anonymity as people want. So that's actually a benefit from the new system that we just don't have at the moment.
Re: Shared access = massive security hole
Re: Shared access = massive security hole
Re: Shared access = massive security hole
Maybe it shouldn't be an option to hide on your profile which associated journals you have then? And the people you have access to should also know that your associated journals have access to them.
Re: Shared access = massive security hole
Which is why I think shared journals absolutely must show on the profile that they're shared.
Unfortunately, I can't see any possible way this could be implemented. If multiple people have the password, multiple people can log in. There's just no way of stopping it. (If I leave myself logged in, my husband can always sit down at my computer! There's just no way to guard against all the possibilities here, nor would most people really like the results we'd get if we asked for more draconian security measures. :) )
Maybe it shouldn't be an option to hide on your profile which associated journals you have then? And the people you have access to should also know that your associated journals have access to them.
Well, I wouldn't go that far, because that would remove a whole awful lot of the utility of this service. Also, fixing borked privacy by borking more privacy just doesn't seem like the right response. *g* The right response, IMO, is to ensure that DW does not transfer granted access from one account to another, regardless of whether the owners of those accounts are the same person. In other words, if you are logged in as MY_JOURNAL, you will only see posts to which MY_JOURNAL has been granted access.
If you are viewing posts as MY_SECONDARY, you should only see posts to which MY_SECONDARY has been granted access, and not ones that MY_JOURNAL was granted access to.
If you are viewing posts as MY_SHARED, you should only see posts to which MY_SHARED has been granted access, and not ones that MY_JOURNAL or MY_SECONDARY or SECOND_JOURNAL or SECOND_SECONDARY or THIRD_JOURNAL (where SECOND and THIRD are separate users with SECOND_SECONDARY as a secondary for SECOND_JOURNAL) has access to.
The tricky part is for people who want to be able to read all posts that MY_JOURNAL and MY_SECONDARY and MY_SHARED all have access to at the same time, even though there may be totally different permissions for all three of those journals. That seems needlessly complicated to me and I would never ever use it, personally, but apparently there is some call for it.
But what bothers me isn't the fact that a person could log out as MY_JOURNAL and log in as MY_SECONDARY, and then have access to all of MY_SECONDARY's stuff, or even that a person could log out as MY_JOURNAL and log in as MY_SHARED, and then have access to all of MY_SHARED's stuff -- my concern is that, what this amounts to, behind the scenes, is DW transferring access between accounts, without alerting the access-granter. I'm much more okay with a system that has a dropdown menu that says "View as: [MY_JOURNAL] [MY_SECONDARY] [MY_SHARED]", because then the user is saying "I want to view this account of mine," and DW is pretty much functioning as normal.
We'll see how it shakes out! Sharing journals is a really complicated use-case, but I'm super-glad they brought it up in the first place, because guarding against stuff by saying "well, people shouldn't do that" just plain doesn't work in any situation. :)
Re: Shared access = massive security hole