Privacy & safety concern: Mark all old entries as private should be free?

[iamsosmart]

Title:
Privacy & safety concern: Mark all old entries as private should be free?

Area:
Entry privacy

Summary:
Instead of requiring a paid account to set all past or newly imported entries to private, Dreamwidth should offer it as a free option to help protect the privacy and online safety of users. (Caveats below.)

Description:
Currently Dreamwidth only offers free users the ability to set the privacy of all NEW entries to "access list only" or "just me (private)". It is also impossible to set a single privacy level for imported entries as they're being brought in; by default they retain their privacy settings from the original source journal.

This can be a problem, particularly with older journals (imported or otherwise) where, in the past, the user wasn't as careful with the sharing of personal information as they should have been. It can also be an issue if a user suddenly has someone harassing them (online or offline) over the content of their journal and they wish to hide it, or if they wish to privatize their content for any other reason (such as worrying that a new employer may be Googling them, or being found by a family member).

In cases like these, the only option for the user in question is to delete their journal, or to go back and manually change the privacy of each and every public journal entry. For established journals, or journal compiled from a number of imported journals, this just isn't feasible, which isn't really fair or reasonable considering that the user in question may already be very anxious and the situation may be urgent.

Users should have the right to be able to privatize all of their entries quickly. On the other hand, I realize that there are processing and data concerns, and that Dreamwidth has costs to manage.

So my proposal is this: offer free users the option to set all of their past entries to private, once.

However this may, potentially, present problems for users who set their privacy and then later import a journal with entries they also wish to lock. In light of that, offering tokens for mass entry locks, offering the option of setting a single privacy setting for imported entries, or imposing a frequency restriction for mass entry locks (such as one request per three months) might be acceptable. denise has kindly pointed out to me that this can be done - setting a minimum journal privacy before importing automatically makes all newly imported entries match that privacy setting. That leaves only the issue of locking existing entries.

If there are logistical problems to implementing this, I would be curious to know them. I'm a programmer myself and may be able to offer assistance or insight. :)

Poll #5605 Privacy & safety concern: Mark all old entries as private should be free?

Open to: Registered Users, detailed results viewable to: All, participants: 60

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (36.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
22 (36.7%)

(I have no opinion)
16 (26.7%)

(Other: please comment)
0 (0.0%)

Comments

[denise]

Honestly, I am sympathetic like hell to internet privacy, but there comes a point where no matter how privacy-conscious, privacy-aware, and privacy-protective a site wants to be and/or is, the individual user has to take a certain amount of responsibility for what they've chosen to put online. In the event of a true emergency of the sort you've been postulating, even the site's mass privacy tool wouldn't necessarily help; depending on database load and site activity it can take a long time to run (up to a day). The only way to guarantee that a journal (or the contents of a journal) won't be visible to the public immediately is to delete it. (And even then, things like Google might still have a cached copy.)

This wasn't all that clear on the Edit Privacy page, so I just edited the site copy to reflect that the process isn't immediate.

[iamsosmart]

Ah. I suppose in that case moving the journal somewhere else would be the best move, though that still wouldn't fix the privacy settings. Unless you could import a DW journal to another DW journal, but that isn't an option for pretty obvious reasons. (Speaking of, does importing use the same process that you use for the mass privacy edit? If not, it seems like treating it as an import process using a min. privacy setting would be more server efficient...)

Should it also be put in the public sections on Privacy? It seems like something that should be stated, as a warning if nothing else.

[cesy]

Importing is adding new entries, whereas privacy edit is finding and then changing existing entries, so you couldn't use the process for one to do the other.

You can import a Dreamwidth journal to a DW clone site, then import from a DW clone site to Dreamwidth. I don't know whether that workaround is any use in this case, though.

[iamsosmart]

Hm, yeah. Theoretically you could enter them as new entries and then nuke the old ones, but there's a lot of complications there.

It could. I wasn't aware that there were other clone sites that offered importing. Given the DW applies minimum privacy settings to imported entries, that could actually solve the problem.

[matgb]

The only way to guarantee that a journal (or the contents of a journal) won't be visible to the public immediately is to delete it

A different idea.

If a journal is suspended, it's not visible to anyone, but the user can still go in and edit stuff (I believe, you can be requested to do so I think?).

If so, possible alt solution would be to allow someone in this sort of trouble to suspend their journal, and then go through and edit the problematic entries themselves? Either with or without a client depending on whether there is one.

Suspension would solve the immediate problem proposed by the OP, while still allowing removal of problematic entries. I'd suggest making sure ability to do this is strictly limited, possibly via support request only--is there an 'urgent' flag that can be set for certain types of request?

[denise]

No. Suspension is not for "this journal needs to be invisible". Suspension is for "this journal has violated the Terms of Service". Mixing things up like that is very very bad.

[azurelunatic]

This may be rehashing ground that's already been debated out on another suggestion, but since suspension itself is unsuitable and unavailable for situations like this, I wonder if it would be at all feasible to make a user-triggered mode that uses roughly the same or a similar mechanism to suspension. I might even go so far as to wonder whether the journal-deletion workflow could/should be changed (potentially dangerous, I think) to allow editing of existing entries in the first ... 72 hours? day? week? two weeks? (Basically, I don't want someone to delete their journal for the purpose of editing it, then forget it is deleted, and wake up the next day to find it gone.)

A journal using a user-initiated method of journal hiding using a mechanism similar to suspension would not be able to comment, should not be able to create new entries anywhere, but should be able to view and delete existing entries, *possibly* even edit existing entries in their own journal only. (Editing community entries sounds like a problem for the administrators.) If it existed, it ought to display a hiatus message like the deletion messages. Looking to the future, it would not be a good thing to have a gazillion hiatused journals sticking around getting in indices and taking up disk space, and taking up namespace. So if this happens, it might be sensible to have it be a "long delete" acknowledged from the start, so no one is surprised except that fraction of people who manage to be surprised no matter how well something is labeled and explained. Using the inevitable Christine Scenario -- suppose someone went off into the Peace Corps or something for 23+ months (this comes up with regularity in LJ feature discussions involving abandoned journals, because there is a much-beloved old-school LJ volunteer who did just that) -- as a model, with long-term absences in mind -- maybe hold in hiatus for 4 years and 11 months, have it go to deletion in the 12th month of the 4th year?

[matgb]

make a user-triggered mode that uses roughly the same or a similar mechanism to suspension

This is sort of what I was thinking along the lines of, but didn't know enough about it to really figure out a spec.

Sometimes, people feel the need to shut down their journal, or to very quickly remove stuff from display; friend of mine had to do this this very week (on LJ, but same principle). They don't want to delete the journal, and sometimes can't be paid.

Some sort of "oh gods, I need to hide everything then sort out all entries referring to X" might be a very useful function. And there's a big part of me that wants it to be available to all users--my friend has cash flow problems and had to ask someone to pay for her account, she knew she could and people would. Said problems will be over very very soon, which is part of the reason for her urgent need to cut stuff written when she was 16/17...

[kellzilla]

Just an FYI, if a person can't use that feature, they can't see any text on that page. It says only:
"Your account can't use this feature."
It doesn't say why, and it doesn't link to anything. Linking to the FAQ would be a good idea. Like "Find out more here." or something.

[azurelunatic]

Thank you for pointing this out. Since this is the sort of improvement that does not require a lot of discussion to determine that it's a good idea, I've taken the liberty of filing a bug to improve the page for free users (and OpenID users, who can't post entries to start with, so would have no need of it).