"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

[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.

[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.

[green_knight]

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

[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.

[alexbayleaf]

+1

[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.

[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]

Um, that's exactly what I meant. A post stops being available via RSS the second the security level changes to any of the non-public choices and upon locking, the entry disappears from the source feed (unless you're logged in/authenticated as someone with permission to see it) are roughly equal statements.

Also, there is no known way to prevent RSS from allowing anyone [should have also said "any spider/any search engine"] to scrape your public posts (at least, not on DW) except to not post publicly is again roughly equivalent to that does nothing about the remote site keeping a copy cached.

If you post publicly, and if your DW is set to be spidered by search engines, the post can and likely will be cached. Changing security status on said post will remove DW's public RSS feed for it immediately but will not have any effect on third party actions already taken (screen shots, screen scrapes, search engine caches, manual re-postings; all stay in place anywhere from some time afterward to indefinitely).

So yeah, I could've/probably should've been a little more precise, but it seems we're pretty much on the same page.

[marahmarie]

You have to use admin console to cut the feed to summary or do title only, right? Even I forget about that and I'm, like, close to a DW power user. So no, I don't think it would be the automatic general presumption of most DW users.

[denise]

Nope!

[yvi]

The edit mass security tool already does it automatically - I just visit the page every few weeks and tell t to lock entries that were posted before a certain date

[marahmarie]

Whoopsies, seems I either forgot all about that or else have never seen it before (in which case I was surely harkening back in my reply to how I cut my RSS feeds on LJ, which was most def through admin console, which was the only way to get it done over there through 2009ish or so). What is the default setting? If someone could tell me then I could know if I've seen it before or not (right now, it's set to obey cut-tags).

Thanks for the heads-up, Denise. :)

ETA: never mind, just googled the FAQ, and judging by my setting, it seems I've probably never seen that before.

[denise]

Cut-tag is the default setting, yeah. (With how long posts on DW can be we thought that would be the best default.)

[marahmarie]

I like that setting, now that I think about it, actually. I used to show summaries on LJ, but respecting the lj-cut is much better (and much more natural, imo).

[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.

[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.

[zing_och]

+1

[montuos]

+1

[montuos]

+1

[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.

[triadruid]

Consolidating all of those 'extra security' things into one page might not be a bad idea, actually.

[metawidget]

+1! Disappearing entries are frustrating for readers, why make it easier?

[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.