Hide specific referer information from locked posts

[azurelunatic]

Title:
Hide specific referer information from locked posts

Area:
privacy, locked entries, driving webmasters up the wall

Summary:
Optionally redirect URLs in entries that are posted locked, to give less incidental information about locked entries to external entities.

Description:
I may be technically wrong in some of this; I beg your indulgence and crave correction of any misunderstandings.

When a person follows a link, the person's browser sends information to the linked website including the referer, or the place that the person just was. (Unless, of course, the person has instructed their browser not to give referer information.) This generally includes the URL of the page on which the link was clicked. In the case of a locked entry, this means that one's browser is cheerfully giving out the location of a locked entry that links somewhere else, to the webmaster of the destination page. Sometimes this is perfectly innocuous; sometimes, this betrays too much information and can start drama.

A quick look at the topic shows that the usual server-side way to strip a referer of private information is to send it through a redirection service, which shows the URL of the redirection service rather than the URL of the actual source. This seems a reasonable enough way it could be done -- set up a redirector on Dreamwidth in a dedicated subdomain, and have a brief explanation/link to the FAQ on that page if someone goes there without a redirection argument to see what this place is and why they're getting traffic from it.

Actually doing this could be done a couple different ways.

1, obvious: Upon detecting the magic combination of links and a locked entry, prompt and offer an actual rewrite of the links, to include the redirect. Advantage: transparent to the journal owner, the code that's entered is the code that comes out. Disadvantage: Harder for DW to deal with if things change somewhere down the line; harder for an individual user to go back and manually change URLs when security of entries changes.

2, reader-centric: A setting on the reader's end to automatically insert (probably via the HTML cleaner, when the entry is called up and displayed) a redirect on all in-entry/in-comment links from locked entries (it would be silly to have a redirect on things like the comment link, or on usernames in comment metadata). Advantages: the reader gets to set it, which means that if on something like a mobile device, it could be unset if it causes delays; since the reader sets it, the reader won't be surprised by it; if things on DW's end change, it's changing it in one place; if entries change security, there's no need to edit the entry. Disadvantage: that puts some more of the journal owner's privacy in the reader's hands, less transparent.

3, owner-centric: The journal owner sets whether a redirect will appear for any locked entries. Advantages: the journal owner is in control, and again, if things change in the way DW wants to handle it, it's just working with the HTML cleaner, not risking breaking links in entries permanently; if entries change security, there's no need to edit the entry. Disadvantages: potentially bad for readers with slow devices, perhaps confusing to readers who don't know about the feature.

[Edited to add: 4, global: Done for all locked entries, will-they-nil-they.]

Advantages to all: more privacy.
Disadvantages to all: less information to the owner of the remote website (which would include other Dreamwidth-hosted journals); link redirection is not what DW particularly wants to specialize in; the redirector could possibly get abused by people who don't have DW journals but are always glad to see an unguarded redirection service.

Poll #3893 Hide specific referer information from locked posts

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
10 (23.3%)

Should be implemented with changes. (please comment)
7 (16.3%)

Shouldn't be implemented.
5 (11.6%)

(I have no opinion)
21 (48.8%)

(Other: please comment)
0 (0.0%)