dw_suggestions | Make links in Private Messages clickable.

Entry tags:

Make links in Private Messages clickable.

Title:
Make links in Private Messages clickable.

Area:
Private messaging system

Summary:
Upon sending a private message to a Dreamwidth user the other night I looked upon the link I included in said message and realized it was unclickable. I thought to myself, what if mobility or other issues kept me from cutting and pasting the link into the browser; what if I were a user who simply needs to be able to click on that link with no other action required? So I'm proposing making all links clickable in private messages.

Description:
Upon reviewing a private message I sent to a Dreamwidth user the other night and realizing the link I included in it was unclickable, I began wondering why links in private messages are unclickable and how much trouble it might be to make them clickable in the future. Currently any links you include in Private Messages are shown in plain text with no way to click through on them to the linked content. I figure this is an accessibility issue for anyone with health issues that prevents them from using the mouse or keyboard fully or who simply experiences pain and over-exertion of already strained joints and tendons upon not being able to click on any links presented to them. So I'm proposing making all links clickable in private messages.

Making links clickable in PMs benefits all users by adding ease of use, speed and simplicity to the PM system; the only downside is that a straight clickthrough could lead a user to say, a malware-infested website. Spammers who sign up for Dreamwidth accounts and then use the PM system simply to spam, and existing users who turn against each other in nefarious ways could use the straight clickthrough function to make it easier for a user to visit a website full of spam and/or malware. But the capability for that sort of abuse is there now; the only difference is it takes a user two more steps (cut, paste, then press enter on your browser's address bar) to get to the website in question. Forcing a user to look at the link by disabling it and requiring extra steps to make it work might be a good idea from a security stand point but it comes at the cost of accessibility and ease of use for all Dreamwidth users.

Poll #12196 Make links in Private Messages clickable.

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
33 (53.2%)

Should be implemented with changes. (please comment)
14 (22.6%)

Shouldn't be implemented.
7 (11.3%)

(I have no opinion)
7 (11.3%)

(Other: please comment)
1 (1.6%)

Flat | Top-Level Comments Only

My wife is typing this.

I have Ehlers-Danlos Syndrome and there are times when I can only use one finger or just a thumb to navigate. Making links clickable would make my life a lot easier.

As a stopgap or in case this suggestion gets shot down, you might want to look into installing Linkification if your browser supports user scripts.

Awesome, thanks! Hands are a lot better today than they were last night (I'm doing my own typing and everything), but there's going to be another bad time when that's going to be useful.

Even if clickable links were only active for people who've been granted access, that would help. I send PMs to friends all the time with links, and having to play the copy-paste games is annoying.

Allowing DW-tags and HTML (I seem to recall those also not working) would also help; it'd be great to be able to send friends links that say "Go check out [username]'s post on [the most awesome news ever]."

That sounds like a beautiful (and yet another) user-side display option.

Though granted-access sounds like an excellent universal thing to make clickable.

(I so want a Quasi-Official DW Userscript Library, full of all the lovely DW-page-involved userscripts that various people across the site have built to make their lives easier. Is there a comm for that?)

dw_nifty, perhaps?

Ooo, that is a good place for it.

+1 for 'active for people who've been granted access.' Also for DW-tags and HTML.

Yes, that would be awesome.

For reference, the reason links are not clickable, all HTML is escaped, etc, in PMs is actually a security measure that has nothing to do with spam prevention or trying to prevent people from being sent to sites that have malware or whatever: it's because the contents of the inbox display on the www subdomain (www.dreamwidth.org). Any content that originates from users has to be considered "tainted": no matter how often it's been cleaned, it has the potential to contain malicious content. Because the www subdomain has access to your account's master cookie -- the authentication item that "signs" all your actions on the site -- we have to subject tainted content to more scrutiny when it's served through the www subdomain: any malicious cookie-stealing code that managed to slip through would compromise someone's entire account. (Conversely, any malicious cookie-stealing code that managed to get into, say, an entry is limited in the amount of damage that can be done, since entries display nearly exclusively on the account's subdomain, and malicious code viewed on a subdomain can only compromise the cookie for that subdomain: if you managed to put cookie stealing code into a dw-suggestions entry, and I viewed it there and you got my cookie, you'd only be able to act in dw-suggestions as me.)

This is why the contents of comments are subject to certain kinds of limitations, such as limiting the use of embeds and disallowing some kinds of HTML and CSS: there are more cases where comments display on www. And it's part of the reason why, for instance, we've moved icons from www.dreamwidth.org/allpics.bml?user=username to username.dreamwidth.org/icons.

Now, we do a lot of things to "clean" tainted data to prevent that kind of attack (and it's why we aren't ridiculously over-paranoid about where tainted data can be displayed, just justifiably cautious), but "make links in the inbox clickable" or "enable HTML in the inbox" or "enable DW specific tags" isn't just a case of flipping a switch in the code: it would mean, essentially, needing to do a full security audit on everywhere that data can possibly be displayed, determine what level of cleaning needs to be done, and hook into those bits of the cleaner. It's much, much easier to escape everything instead.

This is not saying that the suggestion is impossible (or I wouldn't have let it through), just that it is much, much more involved than people think.

I would be totally behind moving the inbox to a nice sandboxed subdomain.

Yup, I think that's what I said last time this came up... can't it be http://skud.dreamwidth.org/inbox ? Fully understand the complexity of it, but I still think we should do it.

Yes, agree. And/or making links clickable only from people you've given access/subscribed to.

Edited 2012-11-30 14:53 (UTC)

+1, either or both of these modifications sound helpful.

That still doesn't do anything to affect the security issue involved. Anything other than complete 100% escaping of all content in PMs will trigger the need for a security audit. Anything.

Hi, Denise. Sorry, I'm a bit lost again. Hehe...

I thought ciaan said he/she (sorry, couldn't find your gender in your profiles) agreed with azurelunatic to move to a subdomain, but he/she wanted an extra option to make the links clickable only to those accounts he/she has given access or subscribed to. (right?)

Then you replied him/her saying that it "doesn't do anything to affect the security issue involved".

What do you mean? Are you saying that the security issue is still there even if the inbox is moved to a subdomain?

As you can tell by now, I'm going circles with the thread logic again. Hehe... X-)

I believe the issue is that it is unsafe to not strip the hell out of all messages, regardless of access given to sender, as long as the inbox is in www.

If/when it is moved out of www, it would be a much more acceptable risk.

I was forgetting the heightened security considerations for the www subdomain at the time of my initial comment.

Yeah, I was wondering if moving it to username.dreamwidth.org/inbox, as other people suggested, would help. I don't know enough about the DW architecture to tell if that's possible or useful. If there's no way to allow clickable links in the inbox no matter where it is, I dunno why we're discussing this suggestion at all. But if possible, it's a feature that would be useful to many people, especially with accessibility issues or on mobile devices. But cutting it down to only circle members (if moved to subdomain and implemented) would also help with spam.

How does the circle/subscription list idea work exactly? So if I was PMing you and you were not in my circle, I would not be able to include a clickable link but if you were in my circle, I would be able to?

I'm thinking it would be like the other settings where you can allow only people you've added to PM you, or only people you've added to comment on your posts. So the issue of you PMing me has nothing to with whether you've added me, and all to do with whether I, as the recipient, have added you.

Allowing links to be clickable would be easier than allowing HTML, though. In this case, it's a case of adding HTML rather than filtering it. It simply means changing something like:

http://www.google.com/

into:

<a href="http://www.google.com/">http://www.google.com/</a>

The Support board does this already, and it's served on the www subdomain. The code could be copied over from that.

The Support board does this already

This I did not know before. So how exactly is the code sandboxed on that board to prevent triggering security audits when links are used?

After reading Denise's explanation of how implementation would best work (probably by sandboxing everyone's inboxes to their respective subdomains, from all I'm gathering) I'm actually in favor, without more information to speak to it being safe to do it any other way, of just sandoxing everyone's inbox to pull this off. (Not that changing things around to work like that would be easy, either, but it's a one-time cost in terms of programming, coding, etc. as opposed to perpetual security auditing).

Edited (more info/word tenses) 2012-12-04 03:53 (UTC)

I believe that what Denise is saying is referring to what would need to be done if we were to allow any form of HTML or DW tags on the site - ie, if we were to *filter* HTML rather than just escaping it all. That's necessary because HTML can also do things like JavaScript scripting via the <script> tag, and that can do some nasty stuff in the wrong hands. Escaping HTML means that all HTML would simply be turned into harmless "entities" - for example, "<script>" turns into "<script>", and the entities are then simply displayed by the browser.

The task of making URLs clickable, on the other hand, is much simpler. URLs by themselves are harmless, so after escaping, you can simply wrap the URL in an <a href="..."> tag. It doesn't actually need sandboxing, as long as the code on the backend is good. The Support board works in exactly the fashion being described here - it escapes all HTML (so HTML can't be used in support requests or answers) but automatically wraps URLs in an <a href="..."> tag to allow them to be clicked.

That said, Denise's solution is possibly better; for security, filtering HTML (rather than just escaping it all) isn't an option on the "www" subdomain, so if we wanted to allow even a filtered subset of HTML - which looks like the direction this conversation is headed - we'd need to have it on a per-journal subdomain anyway.

Does that help?

Yeah, that helps a lot, especially this part: The task of making URLs clickable, on the other hand, is much simpler. URLs by themselves are harmless, so after escaping, you can simply wrap the URL in an [URL] tag. It doesn't actually need sandboxing, as long as the code on the backend is good. The Support board works in exactly the fashion being described here.

And that's all my suggestion originally was about: to simply make links clickable in PMs.

It's an idea that, after reading your explanation of how inclusion of clickable links on the Support board works, I think can be pulled off rather easily without sandboxing inboxes to user subdomains, so I guess what Denise is more hesitant about implementing are the suggestions other users are adding on to my original suggestion, like using HTML in PMs (apart from links), using DW-specific tags, etc.

I guess?

Edited (typo and some unescaped HTML, hee-hee) 2012-12-05 03:34 (UTC)

+1 as the long-term solution, yeah.

Yes, that sounds like it could be a way of limiting the impact. Web security is hard, yo.

That's a great idea, and it might make this suggestion feasible, which it evidently isn't at the moment.

I would +1 this comment to death if I could. When I read Denise's explanation just now my heart sank to my ankles, like for real, but just sandbox the Inbox and voila! (Not that it's "just" anything to do that, but yeah, probably still easier than the full security audit and so on).

I answered "shouldn't be implemented" (at least, the suggestion as set forth) because of all this, which I was pretty sure I remembered seeing given before as the reason this wasn't the way it already was.

I think I agree with people below in the comment thread that having inbox be part of the user subdomain might be a Good Thing.

This would also be great for mobile browsing - while I haven't encountered this in messages specifically, I do find that I basically can't click on links in any anon comments because they're impossible to highlight on my ipad. (In theory I should be able to. And indeed sometimes I can! More often than not though I just end up giving up in frustration.) I imagine messages would have the same issue though, so if it's possible to implement something like this it would make DW more mobile-friendly too.

VERY good point.

Very important point. Making the site work on mobile means making the site work for a growing number of users.

Yeah, this would be awfully handy for mobile!

A better solution for this problem would be to allow HTML in private messages, so the sender could make a link clickable if s/he wants to.

If that solution is for some reason infeasable, making links clickable might be better than nothing, if and only if the algorithm for deciding what's a link is well done.It isn't helpful at all for things not meant to be links to be turned into them (e.g. linking to visit done.it because I left out a space.)

A better solution for this problem would be to allow HTML in private messages, so the sender could make a link clickable if s/he wants to.

Would that actually get around the security issues?

It's a wash. Right now, an evil person can PM e.g.:

Go to www.theworldisperfect.com and all your dreams will come true!

Recepient copies and pastes the link and whatever bad things happen... If HTML were enabled, the message could read:

Go to and all your dreams will come true!

Clicking the link goes to the same bad place. There's no difference really. It's easier to do, but it's not more enticing.

If DW really wanted to, they could do the thing where they trap outgoing clicks with a warning that ooh the internet is so dangerous. Personally I hope DW wouldn't do that, but they could with clickable links; they couldn't offer that sort of warning with the current copy-paste method.

Again, the issue is not "someone can put a link leading to a malicious site in a PM and entice someone to click it". The issue is that anything other than full escaping opens vectors for people to inject malicious code that runs in the browser as soon as the message is viewed with no user action.

Ah... I wasn't thinking of that at all. You needn't allow all HTML to allow linking, but if you can't allow linking without allowing that sort of attack as well, I'd agree it's best to not allow linking.

Let me rephrase: does your proposed solution get around the automatic security audit that would have to happen for the original proposal, as Denise mentioned above (Denise seems to have answered this question with "no")?

1) It sounds like allowing HTML at the discretion of the sender would still trigger a security audit, so it wouldn't be easier to implement from DW's end. It's not safer from malicious code, as Denise says below.

2) IF malicious code weren't an issue, I still don't see any reason it's an improvement over automatically making all links in PMs clickable, as it requires the sender to deliberately make a clickable link. Not everyone would know or remember to do that, resulting in an accessible link less than 100% of the time.

It is because of the prevalence of linkify/linkification/clickable link text scripts and browser add-ons that I am voting against this suggestion. I don't think the effort involved to implement it without compromising site security justifies it when it is relatively easy for users to work around it.

Note: relatively easy for computer users to work around it. Mobile and tablet users, not so much.

Good point; also my reply below, which basically says 1) why should a DW user need to have a certain browser installed that accepts certain add-ons in order to work around this and 2) why should a user have to install an add-on they don't already have when the downfalls of using the add-on (browser slowness, mainly) could outweigh the actual benefit?

Based on discussion of security concerns, my with-changes is: sandbox the inbox into subdomains and then make the links clickable. Possibly in addition distinguish between messages from users with access and messages from untrusted sources. PM spam is starting to be a thing, even if spam isn't the biggest consideration here.

Flat | Top-Level Comments Only

Make links in Private Messages clickable.

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Yes!

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject