"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

[cheyinka]

If people do it now, manually, and know that DW couldn't have prevented indexing/caching by misbehaving search engines, or screencapping, or RSS feeds being cached, etc, why would the ability to do it automatically necessarily change that set of assumptions? I mean, I can't imagine it being called "hide this entry for me after X hours", especially since some people might use it to make an entry less-private; there might even be a note that "this will not prevent RSS feeds from grabbing the entry", just in case...

[ratcreature]

why would the ability to do it automatically necessarily change that set of assumptions?
I tend to assume an official, endorsed feature works better and more smoothly than something I juryrig tediously by hand. And if I had a feature for saying an entry is only public for a short time right from the posting, and the systems knows this, I assume it is different from an entry that the system assumes to be permanently public without any inkling that it is supposed to become private, and then change that afterwards, when the system can't do anything anymore about having featured it in RSS feeds or whatever.

[marahmarie]

I guess your point is if this idea is implemented, posts in question could be set on the server side to not be crawled/indexed/cached and/or for the public RSS feeds to be disabled before posting (no user action required, default post behavior, strictly unchangeable). And those are pretty intuitive add-on features to expect, so good point. But none of that stops screen caps, screen scrapers, or reposters from reposting, and so on. Privacy leak capability? Still huge. An access time-bombed post can *behave* like a normal access-limited post right out of the gate as far as behind-the-scenes security features go, but it cannot actually be one while its security is set to public. So even if DW did implement the idea exactly the way you might envision it, that still does nothing to ensure enhanced front-end security while the post is living its shortened public life out there for all to see.