A possible solution

November 7, 2006 9:50 PM

A possible solution to end the "We demand inline images back!" versus "We don't really mind" MetaWars that are tearing at our very souls...[much more inside]
posted by stavrosthewonderchicken to MetaFilter-Related at 9:50 PM (80 comments total)

Matt has used the nicetitles script for a long time to give the nice mousover hovers on links. It is an option that can be turned on or off in our profile pages. There have been some better (in my opinion) scripts that have been offered since then. My favorite is Dustin Diaz's Sweet Titles, because the code is yummy, it's extensible, and it looks great.

Matt's always saying that if we have an idea, show him the code, and he'll consider it. I figured it'd be pretty easy to hack Dustin's javascript to display images (when linked) in tooltip hovers as well as just title text, and I was right. I haven't written any Real Code™ (other than html and css) in a long time, so I'm sure there'd be more elegant ways to do what I've achieved, but I wanted to get a proof of concept, quick and dirty.

Upsides:

• we retain the current tooltip hover functionality (which should make y2karl happy!)
• we don't need to switch on inline images (which makes Matt happy, from a security standpoint)
• swapping out the nicetitles code and putting in the sweet titles code is a trivial, and only adds about 1 or 2K to the page weight
• the sweet titles code is designed to be extensible
• inline images can be displayed in a magic div just by hovering over the link (so the no-inline folks are happy, and so, I hope are the inline-afficionados
• peace and harmony reign once again

Downsides: None, that I can see. Just like the current solution, it could be turned off with the toggle on your profile if you hated it.

I've tested on IE, FF and Opera on WinXP, all seems well. If Matt should decide he wants to use the idea, I'm sure those with better javascript skills than I can take what I've done and make it robuster and sexier.

So, anyway, the demo is here. Run your mouse over the links to see regular titles and special automagical inliney image things What say you?
posted by stavrosthewonderchicken at 9:52 PM on November 7, 2006

PS. Opacity is controllable. It's set at 80% at the moment.
posted by stavrosthewonderchicken at 9:54 PM on November 7, 2006

I'm diggin' it.
posted by It's Raining Florence Henderson at 10:08 PM on November 7, 2006

I think it looks cool and does seem to address the problem. Honestly, I kind of enjoyed the inline madness during the trainwreck threads.

And I think you misplaced peace and harmony in the upsides. MeFi isn't about Kumbaya and group hugs and I'd hate it if it were.
posted by fenriq at 10:08 PM on November 7, 2006

Niiiiiiiiiiiice.
posted by brain_drain at 10:08 PM on November 7, 2006

Opacity is controllable.

But my excitement is not.
That's pretty damn slick, nice work.
posted by Alvy Ampersand at 10:08 PM on November 7, 2006

And I think you misplaced peace and harmony in the upsides. MeFi isn't about Kumbaya and group hugs and I'd hate it if it were.

That, my friend, was what we here at Wonderchicken Industries™ like to call a joke.
posted by stavrosthewonderchicken at 10:10 PM on November 7, 2006

Ahh, is there a wiki page for that?
posted by fenriq at 10:11 PM on November 7, 2006

That's pretty nice, though the 80% opacity is kinda ugly on my mac (I'd make it closer to 100%). I'd be fine with swapping that code in place of the nicetitles script that is there now.
posted by mathowie (staff) at 10:15 PM on November 7, 2006

acceptable. i just want to be able to post invisible sandwich cat somehow. maybe have a little icon that indicates its got a pic attached.
posted by StrasbourgSecaucus at 10:16 PM on November 7, 2006

I haven't checked it, but suggest this: it should offer both the URL and the link title.
posted by five fresh fish at 10:16 PM on November 7, 2006

also could it work in comments?
posted by StrasbourgSecaucus at 10:19 PM on November 7, 2006

I'd be fine with swapping that code in place of the nicetitles script that is there now.

Sweet! But I suggest again that someone who actually knows their javascript take a look at Dustin's original code, and my minor changes, to see if what I did can be done better. Like I said, I'm more than a bit rusty with actual coding.

I haven't checked it, but suggest this: it should offer both the URL and the link title.

That's totally doable with the way the script is put together.

I'd make it closer to 100%

Yeah, me too. I was just so excited (and surprised) that I got it working that I wanted to post it as is.
posted by stavrosthewonderchicken at 10:20 PM on November 7, 2006

Damn, that the dog's balls! Most excellent work!

Request for Opera: disable Opera's own pop-up tag (it shows the URL), or position the box a little differently so as to avoid having the one tag overwrite the other.

I think I could become a convert to the AJAXy side. You've made UI that does the natural right thing.
posted by five fresh fish at 10:20 PM on November 7, 2006

also could it work in comments?

The code (just like nicetitles) just iterates through the page, grabbing all <a href>s. If there's a title attribute already, it shows it. If not, it shows the URL. If it's an image (I just hacked in recognition for .gif, .jpg and .png), it displays that image in the tooltip. It's all automagical from there.
posted by stavrosthewonderchicken at 10:22 PM on November 7, 2006

I thought images were disabled because of a legitimate security threat, and not because they were appearing inline.

I think that Matt should make images.metafilter.com, which would be a photo hosting site for mefi users. This would do a couple things.

First, he would only allow inline img links that point to images.metafilter.com, which would remove the CSRF threat that img links pose.

Second, since images are hosted on mefi itself, you wouldn't get a bunch of broken image links when reading old threads.

Unfortunately, the option to upload to images.metafilter.com would cost you $20/year, but hey, that's cheaper than flickr.
posted by rajbot at 10:23 PM on November 7, 2006

This is cooler than images.metafilter.com
posted by TwelveTwo at 10:26 PM on November 7, 2006

Most excellent! And a U2 lyric for extra credit.
posted by The Deej at 10:29 PM on November 7, 2006

I think that's a fine idea, rajbot, and maybe Matt'll do it, but I wanted to offer a quick solution that would make everyone happy in the meantime, and that wouldn't create any more than about 5 minutes work for Matt. Thus, this.

I thought images were disabled because of a legitimate security threat, and not because they were appearing inline.

Inline images were exactly the security threat. In other words, an inline image like:

<img sRc="http://somerandomwebite.com/hahahaiamthefunny.gif">

has been disallowed.

Linking to images is still fine, ie:

<a href="http://somerandomwebite.com/hahahaiamthefunny.gif" />

My hack of Dustin's code takes that second, kosher link to an image and makes it automagically pop up when you mouseover, just as link titles currently pop (a function which is preserved, of course).

And a U2 lyric for extra credit.

They got it from a Charles Bukowski poem. That's a picture of Buk.
posted by stavrosthewonderchicken at 10:30 PM on November 7, 2006

I really like this, stav. Thanks!
posted by jonson at 10:37 PM on November 7, 2006

Actually, thinking about it, this method might just reintroduce the same vulnerability...

Someone who knows more about this might want to weigh in on that. I just don't know.
posted by stavrosthewonderchicken at 10:37 PM on November 7, 2006

I guess I stayed up late for a reason. Nice job, mr wonderchicken!
posted by deborah at 10:39 PM on November 7, 2006

Pretty damn cool.
posted by Shutter at 10:42 PM on November 7, 2006

If it works and is secure, I like it. It'll solve the massive load times of image-heavy threads, it makes them slightly less in-your-face while still retaining an element of surprise and immediacy.

It's still not the same as scrolling down and suddenly seeing some bug-eyed kitty floating in mid-air riding an invisible bike, but it's damn close.
posted by loquacious at 10:44 PM on November 7, 2006

My hack of Dustin's code takes that second, kosher link to an image and makes it automagically pop up when you mouseover, just as link titles currently pop (a function which is preserved, of course).

By doing so, you enable the same CSRF threat that caused Matt to turn off images in the first place.
posted by rajbot at 10:46 PM on November 7, 2006

I really really don't want to be the elephant pissing in the circus parade, but since this places the picture on the page relative to where you mouseover the link, I found that sometimes the image runs over the edge of the page. Knowing some of the LARGE images that have been posted in the past, is that a bug or a feature?
posted by wendell at 10:46 PM on November 7, 2006

This could also have been a FF plugin or Greasemonkey script, of course. That was my first idea, but I have no idea how to make them, and I'm too lazy and flu-ridden at the moment to learn.
posted by stavrosthewonderchicken at 10:48 PM on November 7, 2006

Someone like mock would have to test it out to see if a fake image in a js popup could execute anything gnarly, but at worst I could turn it off and not have to worry about compromising my account.

And it's not exactly a replacement for inline images in silly threads, but more of a useful tool for previewing image links anywhere, which I like. It's actually a time saver when used for linked images that are actually helpful and not just going for a cheap laugh.
posted by mathowie (staff) at 10:49 PM on November 7, 2006

Knowing some of the LARGE images that have been posted in the past, is that a bug or a feature?

This was quick and dirty, but it would be relatively simple to constrain image proportions in the css or script for big 'uns, and make the offset from the mousepointer consistent and sensible for images.
posted by stavrosthewonderchicken at 10:50 PM on November 7, 2006

By doing so, you enable the same CSRF threat that caused Matt to turn off images in the first place.

I had that thought already. You may be right.
posted by stavrosthewonderchicken at 10:51 PM on November 7, 2006

Yup, it's just the same vulnerability that doesn't get triggered until you mouse-over a link (and you can't check if a link is safe by mouse-overing because by then you've already loaded the image).

The solution is for matt to detect the browsers that run javascript in image tags and display a big "your browser is horribly broken and people can steal your account" warning.

And if we're not going to go for that admittedly hard-handed approach, images need to be stripped from old threads as well, as people could easily replace those with scripts too, they'd just get fewer hits.
posted by fvw at 10:52 PM on November 7, 2006

A beer and a block of cheese the size of a car battery for the chicken. Good show!
posted by peacay at 10:53 PM on November 7, 2006

Yup, it's just the same vulnerability that doesn't get triggered until you mouse-over a link (and you can't check if a link is safe by mouse-overing because by then you've already loaded the image).

For sure? Bummer. Ah well, I tried.
posted by stavrosthewonderchicken at 10:53 PM on November 7, 2006

I don't think this would work on my PDA (no javascript or ajaxy crap on it, sadly), so I'm going to vote no. I reiterate my support for a MetaChat-style opt-in "Turn Images On" button. Matt can put a disclaimer on it if he's set on being a nanny about it.
posted by Eideteker at 10:55 PM on November 7, 2006

I still vote for images back the way they used to be. If that's possible.
posted by knave at 11:04 PM on November 7, 2006

Only Firefox gets images, and the rest of you loser browsers with vulnerabilities get bubkes.
posted by caddis at 11:10 PM on November 7, 2006

First, I'm very, very impressed. If only all pony requests came with a proof-of-concept demo. Very nice.

My only complaint is that it's just not "inline." It saves the user a click if he wants to see an image, but it requires identifying the link as a link to an image, and hovering over it. At that point, actually pressing the mouse button is a small incremental effort.

Honestly, I kind of enjoyed the inline madness during the trainwreck threads.

Yep. Same here. Wouldn't be the same.
posted by scarabic at 11:14 PM on November 7, 2006

Sure, but the question is, I think: if inline images didn't come back at all, would this be an acceptable (if not as good as 'the real thing') fallback for those who like them?

Anyway, it's probably moot, pending confirmation that this exposes the same vulnerability that disallowing inline images was meant to protect against.
posted by stavrosthewonderchicken at 11:18 PM on November 7, 2006

it requires identifying the link as a link to an image

Just in case this ends up flying, there are various css-y methods out there to automatically style links to images differently, so that you could know without mousing over which links were ones to images. That might be an option, too.
posted by stavrosthewonderchicken at 11:21 PM on November 7, 2006

It won't solve the img hacks handwringing. Matt is unlikely to unclench.
posted by blasdelf at 11:25 PM on November 7, 2006

What about all the forum sites in the world that allow inline images (through bbcode, or just html)? Are they all vulnerable to hacking?
posted by knave at 12:13 AM on November 8, 2006

Yes, they are.

There are two different security issues that I think are getting confused here. Issue #1 is that IE is fucking retarded and will exectute javascript pretty much anywhere (img tag just being the most egregious of these). This is mostly IE's fault, and the solution for people who don't want bad things to happen to their account is to either browse with a sane browser or turn off javascript.

Issue #2 is CSRF. CSRF works even if javascript isn't turned on, and works in every browser. Mostly CSRF is a problem with session data (cookie or basic auth) being sent along with the GET request used to retrieve the image from the IMG tag. It used to be believed that by building your site to only use POST for damaging or changing operation you could avoid that, but recently that has been shown not to be true. Fundamentally the issue with CSRF is that http is a stateless protocol, and that various ways of making it stateful are essentially hacks.

So this new javascript component is still vulnerable to CSRF, because GET requests are being made. On the other hand, it is less vulnerable, because people like Matt (and anyone who cares about their account's security) can just browse with javascript off.

If I were to make it more safe, I'd allow the user to specify a series of domains in a cookie, which would be checked against before the image was loaded. It could still be an all javascript solution, you just need to add an additional bit of js in the user's profile to allow them to add and remove a list of domains from a cookie (something like "imageurl=http://foobar.com,http://flickr.com,http://etc.com")
You'd also need to change the js slightly to make it check the list of valid domains in their cookie.

Anyway, for what it's worth, I say add it.
posted by mock at 1:02 AM on November 8, 2006

So to clarify . . . hovering over one of the (awesome) Sweet Tiles'd images is just as dangerous as just having an image in the thread?
posted by joshuaconner at 1:31 AM on November 8, 2006

Yup, but at least you can turn if off with the noscript plugin.
posted by mock at 1:46 AM on November 8, 2006

stop passing passwords in cookies. use cookie ONLY to determine membership (ie do i see ads or not). add password field to all posting and state changing operations.
posted by quonsar at 4:11 AM on November 8, 2006

Damn. In other words, it didn't work. In any case, thumbs up wonderchicken, the thing looks awesome and the effort is commendable. Thx for trying.
posted by micayetoca at 4:17 AM on November 8, 2006

There are a few ways around that as well, mostly involving either javascript or flash (actionscript is probably the worst thing for website security ever). For the most part it does solve the problem, but it's a real bitch to retrofit.

Also you shouldn't be using password fields, you should be using a randomly generated session key which allows you to retrieve from the database.
posted by mock at 4:19 AM on November 8, 2006

I'd just like to point out, that stavrosthewonderchicken does have the right idea. It is more secure than having img tags, and for those who desire security, it can be made just as secure (by disabling the javascript) as not having the img tags. I think that with the addition of an allowed image domains cookie it is about as secure as reasonably can be expected.

I should probably spend some time and hack the allowed image domain thing.
posted by mock at 4:27 AM on November 8, 2006

quonsar opines "stop passing passwords in cookies. use cookie ONLY to determine membership (ie do i see ads or not). add password field to all posting and state changing operations."

That's a good idea, actually.
posted by clevershark at 4:38 AM on November 8, 2006

Agh, that's a terrible idea! At least the cookie is slightly encrypted. If we have to put in our passwords at every important prompt, then plain-text passwords are flinging around every time we want to say something idiotic. I'm not prepared for that.
posted by Plutor at 5:01 AM on November 8, 2006

So you'd have to type in your password (or have your browser do it for you) every time you post a comment, flag a post or mark a favourite? No thank you.

Once you've accepted that browsers that execute javascript from IMG tags are fundamentally broken, it's easy enough to protect by XSS by including a credentials-derived token in all the pages that have forms on them. I'll grant whoever said that somewhere way up in this thread that it's essentially a hack working around a weakness of HTTP/HTML, but it's not a flaw that can be fixed or mitigated by anything short of a fundamental change to HTML, and not one that's going to happen (for good reasons), so we might as well live with it.
posted by fvw at 5:03 AM on November 8, 2006

(And it's only a matter of hours until someone accidentally posts their password in a comment, and the lack of password-changeability means that would be a big problem.)
doodyface3
posted by Plutor at 5:03 AM on November 8, 2006

There are two different security issues that I think are getting confused here. Issue #1 is that IE is fucking retarded and will exectute javascript pretty much anywhere.

Am I missing something, or isn't this very easy to filter?

It used to be believed that by building your site to only use POST for damaging or changing operation you could avoid that, but recently that has been shown not to be true.

Example/link please.
posted by cillit bang at 6:17 AM on November 8, 2006

I like this. I hope it can be made to work.
posted by languagehat at 6:34 AM on November 8, 2006

OMG. Very hot. Please come and fix the appearance of the eight bajillion web pages in my on-demand web application.
posted by GuyZero at 6:38 AM on November 8, 2006

Good show, chicken. You should be some sort of diplomat or negotiator.
posted by Kwine at 6:57 AM on November 8, 2006

yup, that's a winner. agree on the 100% opacity.
posted by lester's sock puppet at 6:59 AM on November 8, 2006

This has the exact same problem inline images do. They're both vulnerable to CSRF. Remember the magical auto-favoriting comment?

I do like it better than inline images from a site design perspective, though.
posted by Khalad at 7:27 AM on November 8, 2006

Kudos to WonderChicken Enterprises for being such a clever and constructive member of the community.
posted by popechunk at 7:30 AM on November 8, 2006

wendell writes "Knowing some of the LARGE images that have been posted in the past, is that a bug or a feature?"

Feature.

scarabic writes "My only complaint is that it's just not 'inline.' It saves the user a click if he wants to see an image, but it requires identifying the link as a link to an image, and hovering over it. At that point, actually pressing the mouse button is a small incremental effort."

That extra click steals focus either when a new tab/page opens up or when you navigate to the image. It can be tough to keep track of what is what when you have a few dozen tabs open.
posted by Mitheral at 7:56 AM on November 8, 2006

Why not replace the whole front page of Metafilter with a series of dots and hide ALL of the content in mouseovers for those who are using browsers that show them in the intended way?

If the security implications are really as dire as people say, then images must go; I would welcome a safe return for inline images, but hiding content in mouseovers is just annoying. Perhaps as a compromise, images could be hidden in mouseovers, but text comments hidden with noscript tags? That way everybody gets something.
posted by nowonmai at 8:04 AM on November 8, 2006

Wonderlicking good, sir.
posted by cortex at 8:12 AM on November 8, 2006

Issue #1 is that IE is fucking retarded and will exectute javascript pretty much anywhere (img tag just being the most egregious of these).

Y'know what? MSIE is such a monstrous piece of shit that we would be doing everyone a favour by simply not supporting it, period.

Which is to say if you want to use it, fine. Just don't expect the entire world to bust its nutsack trying to accomodate it's every security flaw.
posted by five fresh fish at 8:41 AM on November 8, 2006

Issue #1 is that IE is fucking retarded and will exectute javascript pretty much anywhere (img tag just being the most egregious of these).

Is the image tag thing bullshit still present in IE7? If it's not, why not just target FF/Safari/IE7 as the three modern browsers?

Especially since IE7 has been released as a forced upgrade.
posted by Tacos Are Pretty Great at 8:53 AM on November 8, 2006

IE7 won't be supported by many organizations at least until Vista ships maybe longer.
posted by Mitheral at 9:19 AM on November 8, 2006

Well, I like it, stav and thank you for your clever attempt to solve the img tag issue. I even liked it at 80% opacity.

Stavrosthewonderchicken for president!

I ♥ stav!
posted by Lynsey at 9:55 AM on November 8, 2006

Yeah, we've blocked the IE7 upgrade where I work.
posted by boo_radley at 9:56 AM on November 8, 2006

OK, so there are two problems here, right?

There's the random-js IE idiocy and the CSRF stuff.

We can work around the IE idocy by just checking for that IE version in javascript and not doing the actual IMG stuff.

As for the CSRF stuff, has there been any discussion on using nonces? Switching from links -> POSTed forms and having a hidden form nonce would solve inside-mefi exploits. Poorly-designed sites aren't really mefi's problem, so ignore them.

Someone suggested using some clever js to write a button and then replace it with a js-enabled form.submit() link if the browser supports javascript. That sounds like it would work fine to me. I'll see if I can hack up a quick'n'dirty demo like stavros did.
posted by Skorgu at 12:09 PM on November 8, 2006

We can work around the IE idocy by just checking for that IE version in javascript and not doing the actual IMG stuff.

It's not just IE that does this, other non Gecko/Konqueror core browsers also behave this way.

For the browsers I have to hand thats IE, Opera, iCab, my mobile phone (Netfront?), My Nintendo DS (also Opera).
posted by Olli at 2:11 PM on November 8, 2006

1) Yes IE really is that retarded, and no it isn't easy to filter out. Check the XSS cheat sheet and count the number of ways to evade filters that work with IE vs the number that work with FireFox. Now stop and think about how hard it would be to properly filter all of that. If you figure out a way, please post it, the rest of the world would be excited to know.

2) GET to POST is doable with actionscript. It is possibly also doable with another technique that isn't public yet that I've been working on.

3) stavrosthewonderchicken's idea can be made reasonably safe by simply giving it a default list of safe domains to get image links from and allowing the user to add/delete domains as required.
posted by mock at 4:35 PM on November 8, 2006

This is really really cool.

It is a Firefox/Greasemonkey script that lets you click on a link to an image, it pops up on top of the page you are currently viewing, you click again and it goes away. No navigating away. It doesn't let you see pictures in the thread, but it is somewhat sorta kinda almost a bit related. And it's just nifty besides all of that. Yes.
posted by weretable and the undead chairs at 6:30 PM on November 8, 2006

I think we very well might be able to get by with only Flickr images. I don't know, though.
posted by koeselitz at 6:41 PM on November 8, 2006

The trick is to not worry about people evading filters.

Just don't support MSIE. If it works, greatamundo. But if your compliant, sensible code happens to not work on MSIE, oh well: the user can decide to get smart and use a real browser, or can suffer the glitches.

Or in other words, quit letting Microsoft hold you hostage to their idiocy.
posted by five fresh fish at 7:21 PM on November 8, 2006

[this is good excellent fucking awesome absolutely incredible making me come like a steam train].

Not as good as in-line, but an acceptable alternative if it solves the security thing to an acceptable level, keeping in mind that nothing at all is completely secure in these troubled times.
posted by dg at 7:30 PM on November 8, 2006

weretable, there are a whole bunch of lightbox solutions out there. The prettiest is probably this one, I think. The problem is, they need to be clicked, so why bother in this case? You could just click on the image link itself. Pretty yes, but as a solution to the problem I was trying to address, unnecessary chrome. Also, the scripts are generally heavy -- 20K up to about 80K or more of extra page weight.
posted by stavrosthewonderchicken at 7:38 PM on November 8, 2006

Yeah, that's why I said it was "almost related" to the discussion. I just thought it was neat. I like it because people are always inserting a link to an image (not just here, but in forums in general) and I hate having to open a new window or tab just to look. Wasn't trying to suggest it as an alternative to your idea, although I could have been clearer.

I had never heard of lightbox before today. I can't keep up with anything.
posted by weretable and the undead chairs at 9:21 PM on November 8, 2006

Some very snazzy javascript/css stuff showing up these days. I love gadgets, too.
posted by stavrosthewonderchicken at 9:51 PM on November 8, 2006

I just thought it was neat. I like it because people are always inserting a link to an image (not just here, but in forums in general) and I hate having to open a new window or tab just to look. Wasn't trying to suggest it as an alternative to your idea, although I could have been clearer.

The Text to Image Firefox extension does function as an alternative.

The only problem is that until a new version is released you'll need to use the Nightly Tester Tools to force it to install on Firefox 2 (seems to work fine though.
posted by Olli at 1:21 AM on November 9, 2006

Woah, cool, Olli. That's the extension that I was going to write, until I figured out that I had no idea where to start with extensions. A works-now solution for current FF users, at least, that. I'll be giving it a try when I get home later.
posted by stavrosthewonderchicken at 1:27 AM on November 9, 2006

koeselitz writes "I think we very well might be able to get by with only Flickr images."

Flickr is far from the only (or even the best) image hosting around. People like it cause it's simple and there is the group vibe thing happening but for those of us with our own hosting and motivation it has some serious drawbacks.
posted by Mitheral at 1:23 PM on November 9, 2006