![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
azurelunatic) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
dw_suggestions2010-07-20 10:50 am
Hide specific referer information from locked posts
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.
This suggestion:
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%)
no subject
no subject
no subject
no subject
Also, perhaps FB's implementation could provide some hints.
no subject
no subject
This wouldn't work for single entry view, but what if for the read page DW were to do what Tumblr or Posterous does, and instead of it being username.dreamwidth.org/read, it was www.dreamwidth.org/read? That way there would be less information.
(Also, selfishly I would like this changed because when it comes to my google analytics page, it becomes clogged with refers from people's read pages, when what I really want to know is whether entries are linking me. I have a rant about how I find Google analytics annoying that I never do finish)
no subject
And do tell us all more about the annoying!
no subject
Heh, ok.
no subject
no subject
Not sure if there's any feature that would make it useful to redirect links leading into the DW domain from elsewhere within it, either, so could maybe avoid extra steps on those if there's not a reason to need it.
no subject
no subject
no subject
There are services, like anonym.to, that you can use, but I don't want that hardcoded on my page, and it wouldn't stop sidebar links &c.
So yes, I approve this idea, but it'd need to parse the whole page, not just the entry. And I have no clue how to do it.
no subject
no subject
no subject
no subject
no subject
ETA: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html gives the spec for the HTTP referer [sic] header. It gives a URL, and nothing else. A quick google for "http referer title" doesn't suggest that the title is passed.
no subject
I don't know why I had convinced myself it was true, but was sure that my old stats package (statcounter) told me referral titles. Appears I was wrong and conflating that with pages viewed.
It's been a long time since I used it (took multiple attempts to find the password because while it was one of my standard mid-secure passwords, it was a 5 year old one).
Thanks for correcting me.
no subject
no subject
no subject
bit.ly and such redirectors no pass on the referer so the target page will get the SEO credit for it in search results. Which means it's not good enough for our purposes.
1, 3, or 4 works for me
no subject
no subject
All the suggestions have disadvantages, but #3 is the least objectionable. A simple way of doing it is to write links like this: linkIdontwantreferedataon.com (copy and paste), but it's not as accessible and I can see why journal owners might not want to inconvenience their readers like that. On the other hand, I find it annoying when I'm redirected when I click a link.
So, opt-in :-)
no subject
ETA: well, okay, privacy hole, not security. But still, good privacy protection is one of our things, and this would add to it.
no subject
On the other hand, I may link to something on my special access filter for writing about a private issue and want there to be referer information, because the site I'm an affiliate of isn't going to act awkward around me because I have [rare disease], or the writer of the [controversial kink] fic I just recced won't think less of me for having that kink, or the friend who's already on that access filter would feel better knowing that all that traffic to her entry is coming from me and not from someone mocking her.
So no to global hiding of referer information on locked entries.
no subject
But those are indeed good use cases for when the referer information would be wanted from a locked entry: when the destination site is known and trusted, or known to not care about anything that touches on your specific privacy.
no subject
no subject
* Person A makes secure post, including link α.
* Dreamwidth servers do something to transform α into β.
* Person B reads secure post, clicks on link β.
* Link β is to a redirection engine on Dreamwidth, which then goes to the original link α with different HTML headers, the effect is to not disclose information about A's entry, including that it's from A.
* The owner of α is aware that they're getting traffic from Dreamwidth, but nothing more specific. They will also be aware that they're getting a visit from B.
From a privacy point of view, this is good. To deal with the last point, I don't see that there's a possible way to stop the owner of α from finding out some information about B's visit, short of Dreamwidth providing a browsing proxy, and *that* is outside the scope of this suggestion.
If such a plan were to be implemented, it would only alter disclosure about A's journal. I would therefore counsel that A is the only person who can set (and potentially unset) this redirection. This may also save in computational power, as Dreamwidth need only perform the translation once per entry, and store the post containing transformed links. Option 2 would require each post to be changed on the fly, which is much more expensive.
Dreamwidth is going to have to keep fuel for the redirection engine, the translation between α and β will have to be stored somewhere. This requires additional computation power, and provides an additional point of failure and point of compromise. I don't see it as a significantly greater problem than keeping data on Dreamwidth in the first place. If the translation table is leaked, all that will be available is a list of URLs and their Dreamwidth codes.
In principle, the redirection could be done on a link-by-link basis, but it may be easier to require authors to use the feature on a post-by-post basis. Such a setting would also enable the server to determine whether to use the real or translated URLs of page furniture links. It would not be an appropriate to have this option available for public posts, as they're already public.
Use of this setting must be under the control of the individual poster, I've no firm opinion about the default setting.
no subject
Though the translation between α and β may not require a table if α is passed to the redirection engine as an argument.
no subject
Well, they're aware that they're getting a visit from someone, but the only information they'd get from that which would be potentially useful in identifying the person is the IP address (and maybe the browser used, if the browser is sufficiently rare, with extra domain knowledge, to tie to a single person).
The username wouldn't be given.
no subject