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

[marahmarie]

Not really. A post stops being available via RSS the second the security level changes to any of the non-public choices. I would think the average DW user is self-educated enough to know DW works more or less like LJ or any typical RSS-enabled blogging platform in that public posts = RSS scraped data.

Also, there is no known way to prevent RSS from allowing anyone to scrape your public posts (at least, not on DW) except to not post publicly.

[azurelunatic]

I know this is probably something you know and not what you meant in your comment, but for other people reading the discussion, I'd like to clarify that upon locking, the entry disappears from the source feed (unless you're logged in/authenticated as someone with permission to see it), but that does nothing about the remote site keeping a copy cached.

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

[ratcreature]

Also, there is no known way to prevent RSS from allowing anyone to scrape your public posts (at least, not on DW) except to not post publicly.


But there is a privacy setting to show the title only in your feed in general, or only a summary. So it is not as if users have no influence how much of their public posts may end up in feeds elsewhere. So if DW offered an official "hide this post for me in the X hours" option it is not unreasonable for users to think that DW would automatically minimize its exposure on all levels.

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

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

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

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

[ratcreature]

Yes, but making it easy encourages this practice, whereas now you have to make an effort, and it might give the impression that the "official feature" to "hide" things would take care of all your settings to make the intended effect consistent, like that checking this would also change the rss behavior for this entry or somehow include no indexing robot instructions or prevent it from appearing on the "latest" page and all that. Like an integrated thing taking care of everything when you check the box.

[montuos]

+1

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

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

[ratcreature]

But now relatively few people do this because it is extra hassle. This feature might encourage the behavior and I don't want that encouraged and made easy.

[marahmarie]

I do it all the time manually. I would not know exactly how or when to use the suggested time bomb feature (because I'm not normally all that premeditated about locking previously public posts up), but I've seen it discussed before on DW and think it would be a quite useful feature to have.

[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

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

[marahmarie]

And/or offer to auto-filter in subscribed people who will otherwise be completely locked out so the link stays alive for them? (This would not keep it alive for the public or non-access-list members but maybe still better than nothing).

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

[axiom_of_stripe]

I don't think there's any place in non-custom-themed entries where it says what the security is, though.

Most styles I've seen (definitely Transmogrified, which I'm using) have it in the headers next to the date as an icon with mouseover caption, and a few of them have it written out. I think all of the standard ones have it somewhere, don't they? (If not, they should!)

[cheyinka]

I meant "Viewing entries in ?style=site, is there any place on an entry's page that has what the security is?", not "are there styles that don't show it?", but then I looked more closely at a locked entry and spotted the lock icon. So it's not that there isn't a place, it's that I overlooked it (twice)!

Maybe the note could go right under the date? "This entry will stop being public on 2012-10-15" or the like?

[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

[montuos]

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