"This post will self-destruct shortly...": automated security changes

[kaberett]

Title:
"This post will self-destruct shortly...": automated security changes

Area:
privacy, filters

Summary:
People commonly make public posts which they do not wish to remain public indefinitely. An additional field at posting ("Change security [...] to [...] when [...] (has/have) elapsed") would remove the need to remember to make the manual change at a later date.

Description:
I repeatedly come across cases where people make a post with the specific intention of subsequently changing its visibility, for example:

(1) person with username A changes it to B. They want to flag this up to their subscribers, without creating a permanent trivially-findable public record. They make a public posting, intending to manually restrict access to said post after a week. Memory proves to be a tricksy beast, however.

(2) person wants their "current" entries to be public - on a rolling basis. That is, they *don't* want their entire journal to be public, but *do* want their initially-set-as-public posts over the last N weeks to be generally visible.

(3) person is making a links round-up (LRU); realises they've left out a link; edits the original post to include it. In order to flag this up to people who've already read the LRU and won't read closely again, they make a follow-up post to appear on people's dwrolls, highlighting that they've added a new link, with the intention of deleting the follow-up post after a few hours (at which point it is obsolete, because people who're only just catching up with their reading lists won't have seen the pre-edit LRU anyway!)


In each of these cases, it would be helpful if there were the option tree at point of posting:

Change security at later date? Y/N
Change security to? [pre-defined set of access filters, etc!]
Change security when? [hours, days, weeks...]

... such that in case:

(1) person, at time of posting, can say "make this post access-locked after a week"
(2) user can set a default behaviour of "increase privacy of all posts to [LEVEL] after a month" (where custom filters, etc obviously don't have their privacy level *reduced*!)
(3) user can make the post automatically set itself private e.g. 6 hours after initially posting


In IRC we briefly discussed the possibility of actual self-destruct - i.e. automatic deletion after a set time frame - but consensus there was that auto-deletion is an undesirable behaviour, because (a) deletion is irreversible, and (b) setting posts to private has the same effect on the reader as deleting them.

In terms of downsides, the only one that springs out at me is that - at least for my level of familiarity with the code-base - this would be an absolute *swine* to implement. However, I am very open to hearing other criticisms :-)

Poll #11815 "This post will self-destruct shortly...": automated security changes

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
26 (40.0%)

Should be implemented with changes. (please comment)
10 (15.4%)

Shouldn't be implemented.
13 (20.0%)

(I have no opinion)
15 (23.1%)

(Other: please comment)
1 (1.5%)

Comments

[rebelsheart]

I'd really want to see some sort of notification (default: enabled) for when this happens, so forgetful users don't start opening requests wondering why their posts are changing their own security levels.

[kaberett]

+1

[marahmarie]

...so forgetful users don't start opening requests wondering why their posts are changing their own security levels.

*snorts, chokes on tea*

Probably the funniest thing DW ever might become capable of doing. :)

[ratcreature]

I realize that people do this, but to make it a feature wouldn't be good, IMO. I think this creates a false impression of control. I mean, if people who do this, don't also prevent their RSS feed from being scrapable and select their journal to be not indexed and all that, their public-for-a-time entry will be public elsewhere still. Also it is inconvenient for readers, who think they are linking to a public entry and then it vanishes.

[kaberett]

Hmm, good point.

[cheyinka]

But both of those are still true for people who manually change security; if the journal's been indexed and cached (or if someone's taken screencaps) even completely deleting the entry won't help, after all. I can also see this being useful if someone wants to make an entry less-private as well as more-private.

[kerravonsen]

Also it is inconvenient for readers, who think they are linking to a public entry and then it vanishes.

Yes, but that would happen anyway if the original poster did it manually, so it's not really relevant to the issue.

[swaldman]

I do see the concern, but IMHO this is a matter of user education rather than a reason not to have the feature... for many of the use cases given (e.g. "I've just corrected my last post; I'll get rid of this message in a few hours"), it's not a concern.

Re breaking other peoples' links - good point. I suggest that if a post is set to "auto-destruct" then it should warn the reader, perhaps through a footer.

[msilverstar]

+1

[swaldman]

How are use cases 1 & 3 different? I'm probably misunderstanding something, because they seem like the same thing...

I think this would be useful. Just to add an implementation note: remember that custom access filters could change after the future change was set. In this case things would need to fail to a more, not less, restricted level. E.g. if I set all posts to be limited to filter "A" after a month, and then I remove filter "A", they should end up being set private instead, not left as they are. Ideally with an error or warning sent as an email to the journal owner.

[kaberett]

Sorry, yes, they are - they started out different because I was intending case (3) to maybe ACTUALLY have an auto-delete/self-destruct setting, but then we discussed it a bit more in IRC and decided that auto-delete was something we probably didn't actually want but the changes didn't propagate! :-)

[stardreamer]

I like this idea, but can certainly continue to live without it if implementation is going to be a Sisyphean task.

[axiom_of_stripe]

I'd like to see some automatic indication on the post that its security level has been set to change: maybe a "temporary" indicator next to the current security indicator? Definitely something visible to the author of the post, and I personally would like it showing by default to everyone who can see the post -- thoughts?

[cheyinka]

Yeah, that's a good idea. Where it should go, I don't know - I don't think there's any place in non-custom-themed entries where it says what the security is, though.

[azurelunatic]

If someone is doing this to lock down their life better, I can see a use case where it would not make sense to give any warning it was going to go away, so fewest hostile folks would have the chance to screencap.

I feel strongly that if this exists, the choice to say whether it's in use should fall with the poster.

[marahmarie]

(b) setting posts to private has the same effect on the reader as deleting them.

Nope, it doesn't. (And I've voted in favor of your suggestion, so just trying to make a point here.) But the former results in a "You do not have permission to view this" message while the latter simply 404s. It's a small distinction, but if your stalker wants to know where that now missing post from last week that's all about him is, and he sees "You do not have permission" on it he thinks to himself, "Aha! it's still there! I just can't see it anymore, but maybe this person's friends still can." This could, as an example, lead to him being able to start some sort of action against you with DW or even with the courts. On the other hand, if he visits the page and gets a 404, then it's gone, so there's nothing for him to get frothy over (or at least not as much for him to get frothy over, though I'd imagine he could still bitch about any search engine caches that are still available on it or whatever).

[azurelunatic]

I could actually see this working in reverse: perhaps there's an entry that needs to be posted before it goes public. The immediate example that came to mind was a roleplaying entry or something, where comments are an integral part of the finished product and the entry needs to be posted to collect them (which wouldn't be covered by the future draft entry feature) but then should be revealed, and as long as everybody's done before the deadline, the journal owner/entry poster in community doesn't actually need to be there if it can unlock on schedule.

[velocitygrass]

Personally, I hate vanishing posts (i.e. mainly case two), but at least along with this functionality a note about "Beware, this post will be locked on xxx" could be added to the entry automatically so that readers are aware of what will happen. They then know not to link to the post and/or to save it for later use.

[green_knight]

+1 - that's my 'with changes'.

[alexbayleaf]

+1

[zing_och]

+1

[kate_nepveu]

I know I've seen this discussed before . . .

Ah. http://dw-suggestions.dreamwidth.org/605967.html -- would have been a journal-wide setting a la use case #2, deferred.

I still would like to know this as a reader ("This post is scheduled to become non-public / to become public / to have its access requirements change on date" -- not sure the best way to handle changes involving filters), which is my with-changes.

[ciaan]

Anything locked that is auto-scheduled to become public should absolutely inform the reader/commenter. What I will say in comments on a locked post vs. a public one varies. And of course the poster can always unlock a post, but I tend to assume they won't, and if I know for sure they've already set it do unlock, that could affect my response.

[green_knight]

This sounds like a good premium paid feature, by the way. I like this - it's not something I'd ever have considered, but I can see the utility.

[liv]

This seems like a really great feature. I do appreciate ratcreature's concern about the false sense of security, with everything being slurped by RSS readers the minute it appears. But I think it's still worth it on balance. It would also have some anti-spam benefits, too, as many spambots target old posts.

[thomasneo]

My concern is with the privacy leak of compromised accounts.

If users can easily make their posts "disappear", then hackers can easily make their posts "reappear" as well. Many, many months later, when it's impossible to trace/track them down.

[azurelunatic]

It would make sense to me if an entry edit triggered by an automated time-based privacy change would generate a notification (which is turned on by default).

However, I am not sure how a journal with a lot of private entries that were made that way by an automatic time-based privacy change, is any more vulnerable to account compromise and security change than an account that has a lot of private entries that were either posted private initially, or made private with the security change tool.

It is in fact possible for someone to sort through their entries by security; http://username.dreamwidth.org/security/public is possibly faster than logging out.