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

[ratcreature]

I've never mass edited for privacy, but most desktop clients can do that, no? So free users can set up the automation on their end rather than DW's.

[noracharles]

Definitely. As far as I know there are no supported and recommended desktop clients for the job, but programs which can do it do exist.

[arethinn]

That there is no desktop client for DW as far as I am aware. (Semagic could not do this on LJ, though, if that's what you're thinking; it required a separate program.)

[denise]

Most, if not all, of the LJ clients can be adapted to work on DW just by changing the server location. Not all the features work, because we've made some changes to the protocol, but regular entry editing does.

[iamsosmart]

Does regular entry editing include mass privacy changes or is that still an entry by entry process?

[denise]

That's always an entry by entry process -- there's no protocol support for mass privacy changes, again because of the server load involved in doing it automatically and quickly like that. Some clients will automate the process on their end, I believe, but I don't use desktop clients at all, so I'm not sure which.

[iamsosmart]

Huh. I'd been operating under the assumption that privacy was its own separate field in the database and that you could just tell SQL to overwrite the field for all related rows, but come to think of it I never found out if the journals even have their own separate databases. If there's lots of key referencing between tables and the like, yeah, that would take a lot to process. Shoot.

[arethinn]

Yes, I used Semagic for a while, but quickly got frustrated with how many DW-specific features did not work (biggies, being able to manage one's friendslist in the client and crossposting in the magic way that DW does it) and eventually gave up and started using the web form. I don't recall there being a way to mass-edit post security with it. IIRC LJ-Sec got confused when I tried to point it at DW, though, so if I'm just misremembering and you can do that with Semagic, I'd expect similar (failed) results.

[cesy]

See the list of compatible clients for Dreamwidth. There are several.

[arethinn]

Let me rephrase, then - there's no good (Windows) desktop client for DW, one which DW itself might recommend use of. (For the record, this always frustrated me about LJ as well, that they didn't have an official client meant to work with the site, although I used and liked Semagic.) I don't mean to sound mean here, but I've tried several things on that page and they've either been too complicated to install and use, offer too few features, or both.

[iamsosmart]

That's been my experience as well, which is why I didn't seriously consider clients as an option - I have enough difficulty with the LJ ones, using them for DW tends to outright break them. If there was a more dedicated client it could be a different story, but...

[matgb]

LJ Sec has been used succesfully to do exactly what the OP suggests by at least one person Iknow:
Configuration Management

You need to change some of those settings, but that should be easy.

Also, with the work fu is currently doing as we type on the client protocols, more clients will become available, as support for ATOM is a stumbling block for many.

[iamsosmart]

So it allows mass privacy editing as opposed to entry-by-entry?

And ha, that's awesome. I've been shying away from desktop clients up until now, but it looks like I'll have to cave.

[arethinn]

OK, well, LJ-sec has failed for me before when I tried to point it at DW, so I figured there was something "corrupt" (from the program's perspective - differently formatted) about the data DW was feeding it and it wouldn't work sans an update from the developer. Maybe there was something more esoteric about config that I wasn't aware of.