I'd just like to pop in here, go on a slight tangent, and remind everyone why a blacklist method would be ineffective for this kind of thing, especially because of the way the Spammers are doing their... spamming.. I'm not saying that the other ideas aren't valid, just Blacklisting isn't an option.
Blacklists are used as a prevention method, if you know the site that the spammers will attack from, thus not allowing them to come on. However these spammers change site every-time they attack, leaving a blacklist useless.
By the time the admins are noted of the new 'attacking site' and are able to add it to the blacklist, many people would have already been 'attack'.
This renders blacklisting useless. It's better for us to maintain our grip on trust sites at the moment.
I know. I still would rather have a blacklist in conjunction with other methods that were less restrictive but also effective, especially because MCF's admins don't have access to the list themselves and must go through curse to make changes, and ESPECIALLY because Curse is taking their sweet time maintaining the whitelist.
I actually mentioned this a while ago as being the only really effective way of dealing with it. The big problem though is that you would have to do this -every- time an image is loaded. When you consider the size and popularity of the site, that is a LOT of extra HTTP requests causing additional load.
The real problem here is that this is something that takes place entirely on the client end and current clients are poorly equipped to block this kind of phishing attempt. For one thing there is no way to access the HTTP headers via Javascript requiring any such checking to be done sever side. So start sending notes to your browser makers to expose HTTP headers to javascript if you really want this fixed properly.
Wait a second... Can't javascript at least be able to get the status code of HTTP responses? If so:
Why not just make javascript attempt to load the image and then if the attempt fails for any reason (authentication) then you can just not display the image?
EDIT: A quick google shows that it can. There's the problem (hopefully) solved! Someone go tell citricsquid.
YOU SUCK! You wouldn't even be the one making the blacklist! And with the new moderators, it'll get blacklisted. FAST.
Please Blue_Flame, no need for personal insults.
And with the new moderators, it'll get blacklisted. FAST.
Not fast enough, it only takes a few seconds for the exploit to work. it would take longer for it to be reported and removed for someone to read it, and un-intentionally get scammed.
exploit will happen before forum admin get to blacklist it.
BTW, it seems to me that the only reason you are arguing in favour of the whitelist is because you have no need for it. Look at your signature! One pic, a couple of URLs. Some people can't upload their images to another site, as the site where the images are hosted is completely out of their control, run by another person. BTW, you are such a hypocrite!
Some people can't upload their images to another site, as the site where the images are hosted is completely out of their control, run by another person.
Your argument is invalid.
If person A has picture and they CAN'T upload it to Photobucket (or similar) then chances are we don't want it displayed here, since the only VALID reason for not being able to host said image on a public photo site is that the photo is either breaking copyright law, or it's pr0nz.
Some people can't upload their images to another site, as the site where the images are hosted is completely out of their control, run by another person.
Your argument is invalid.
If person A has picture and they CAN'T upload it to Photobucket (or similar) then chances are we don't want it displayed here, since the only VALID reason for not being able to host said image on a public photo site is that the photo is either breaking copyright law, or it's pr0nz.
Or maybe it's embedded on a site not on the whitelist?
As in, a part of a website, not an image created by the person.
Rollback Post to RevisionRollBack
You have just started
To read the haiku that you
Just finished reading
Some people can't upload their images to another site, as the site where the images are hosted is completely out of their control, run by another person.
Your argument is invalid.
If person A has picture and they CAN'T upload it to Photobucket (or similar) then chances are we don't want it displayed here, since the only VALID reason for not being able to host said image on a public photo site is that the photo is either breaking copyright law, or it's pr0nz.
Or maybe it's embedded on a site not on the whitelist?
As in, a part of a website, not an image created by the person.
Your argument is invalid.
imageshack.us has the ability to upload from a URL. This may also break copyright law.
Retrieving HTTP status code from loaded iframe with Javascript ... You can't get page headers by JS, but you can distinguish error from success.
Can't check headers. The problem isn't in the status codes, it's in the headers. Oh well, you tried, which means you've done 5x what Curse has done for us at this point...
I'd go with the post count setting. It's fairly easy to implement and it'd solve quite a lot of problems.
Say, people with PC < 100 will get their images displayed as Click to view image and all others will be shown directly.
Retrieving HTTP status code from loaded iframe with Javascript ... You can't get page headers by JS, but you can distinguish error from success.
Can't check headers. The problem isn't in the status codes, it's in the headers. Oh well, you tried, which means you've done 5x what Curse has done for us at this point...
No actually. No its not. The thing that tells the client to bring up a display box is the "401 Unauthorized" status code.
And yes you actually can get the headers in javascript (you're probably thinking about the headers to the page the javascript is being run on) see the bottom of this post for details.
All you have to do is make sure it doesn't have that and WE CAN GO BACK TO NORMAL! WITH NO WHITELISTS AND STUFF!! YAY!!
Now somebody go tell citricsquid about this flawless solution.
Just as an important note. The server may still send the WWW-Authenticate header which may (probably depending on your browser) still make a login box appear. BUT that doesn't stop anything. Just have the server somehow pass an image to check (dynamically generated javascript shouldn't be too hard if you are just changing one variable) to the javascript which will then use an XMLHTTPRequest object (the stuff used for AJAX) to send a head request for the image. If it decides the image is safe (after it checks the status code and headers, which you can actually do with an XMLHTTPRequest) it'll display it.
Citric does not run things here anymore AFAIK.
Send him a PM if you really think it is flawless, and he can forward the request to Curse, or you can give it to curse yourself.
Arguing about it here aint gonna do anything.
Rollback Post to RevisionRollBack
Your friendly neighborhood dragon. Don't be scared, I won't bite!
I am here for you, Don't be afraid to send me a message.
Perhaps I'll try to write a proof of concept. It would be far easier to implement in PHP though. If anyone does try to do this, make sure you spoof the user agent as IE.
Since the entire problem is that the login box appears, having it appear when the javascript requests is an equally large problem. If it does do this, then the solution won't work.
Also:
Quote from Wikipedia »
XMLHttpRequest is subject to the browser's same origin policy in that, for security reasons, requests will only succeed if they are made to the same server that served the original web page. There are alternative ways to circumvent this policy if required.
Perhaps I'll try to write a proof of concept. It would be far easier to implement in PHP though. If anyone does try to do this, make sure you spoof the user agent as IE.
Since the entire problem is that the login box appears, having it appear when the javascript requests is an equally large problem. If it does do this, then the solution won't work.
Also:
Quote from Wikipedia »
XMLHttpRequest is subject to the browser's same origin policy in that, for security reasons, requests will only succeed if they are made to the same server that served the original web page. There are alternative ways to circumvent this policy if required.
The login box shouldn't appear since the javascript is handling it (and on top of that its only a head request). Also I was able to send and recieve requests for my browser (firefox) fine through javascript, the only thing the same origin policy did was not send any cookies in the request and not set any it got from the response. It even got the request data fine as well as the header.
Also the whole pont of doing it from java script is that it will be client side so the server doesn't have to do all the work.
function UrlSafe(url) {
var http = new XMLHttpRequest();
http.open('HEAD', url, false);
http.send();
return http.status==200;
}
You could modify it so it returns true whenever anything in the 200s is returned
EDIT: not sure about other browsers, but it worked on mine. If it doesn't work it returns a status of 0 in which case the image won't be displayed so it'll be safe even if it doesn't work.
Worst comes to worst you could just make a php page or something on the server which just gets the status code of various urls, which wouldn't be that hard.
I'd go with the post count setting. It's fairly easy to implement and it'd solve quite a lot of problems.
Say, people with PC < 100 will get their images displayed as Click to view image and all others will be shown directly.
I know. I still would rather have a blacklist in conjunction with other methods that were less restrictive but also effective, especially because MCF's admins don't have access to the list themselves and must go through curse to make changes, and ESPECIALLY because Curse is taking their sweet time maintaining the whitelist.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Wait a second... Can't javascript at least be able to get the status code of HTTP responses? If so:
Why not just make javascript attempt to load the image and then if the attempt fails for any reason (authentication) then you can just not display the image?
EDIT: A quick google shows that it can. There's the problem (hopefully) solved! Someone go tell citricsquid.
BTW, it seems to me that the only reason you are arguing in favour of the whitelist is because you have no need for it. Look at your signature! One pic, a couple of URLs. Some people can't upload their images to another site, as the site where the images are hosted is completely out of their control, run by another person. BTW, you are such a hypocrite!
Your argument is invalid.
If person A has picture and they CAN'T upload it to Photobucket (or similar) then chances are we don't want it displayed here, since the only VALID reason for not being able to host said image on a public photo site is that the photo is either breaking copyright law, or it's pr0nz.
Or maybe it's embedded on a site not on the whitelist?
As in, a part of a website, not an image created by the person.
To read the haiku that you
Just finished reading
Your argument is invalid.
imageshack.us has the ability to upload from a URL. This may also break copyright law.
This is sarcasm.
Also, sites that do neat things like signature banners that track views don't work, and our signatures become boring and static.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Can't check headers. The problem isn't in the status codes, it's in the headers. Oh well, you tried, which means you've done 5x what Curse has done for us at this point...
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Say, people with PC < 100 will get their images displayed as Click to view image and all others will be shown directly.
No actually. No its not. The thing that tells the client to bring up a display box is the "401 Unauthorized" status code.
And yes you actually can get the headers in javascript (you're probably thinking about the headers to the page the javascript is being run on) see the bottom of this post for details.
Here's the official document on the HTTP protocol about it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html which I've read through numerous times (making a webserver as a project)
All you have to do is make sure it doesn't have that and WE CAN GO BACK TO NORMAL! WITH NO WHITELISTS AND STUFF!! YAY!!
Now somebody go tell citricsquid about this flawless solution.
Just as an important note. The server may still send the WWW-Authenticate header which may (probably depending on your browser) still make a login box appear. BUT that doesn't stop anything. Just have the server somehow pass an image to check (dynamically generated javascript shouldn't be too hard if you are just changing one variable) to the javascript which will then use an XMLHTTPRequest object (the stuff used for AJAX) to send a head request for the image. If it decides the image is safe (after it checks the status code and headers, which you can actually do with an XMLHTTPRequest) it'll display it.
Send him a PM if you really think it is flawless, and he can forward the request to Curse, or you can give it to curse yourself.
Arguing about it here aint gonna do anything.
I am here for you, Don't be afraid to send me a message.
Since the entire problem is that the login box appears, having it appear when the javascript requests is an equally large problem. If it does do this, then the solution won't work.
Also:
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
The login box shouldn't appear since the javascript is handling it (and on top of that its only a head request). Also I was able to send and recieve requests for my browser (firefox) fine through javascript, the only thing the same origin policy did was not send any cookies in the request and not set any it got from the response. It even got the request data fine as well as the header.
Also the whole pont of doing it from java script is that it will be client side so the server doesn't have to do all the work.
function UrlSafe(url) { var http = new XMLHttpRequest(); http.open('HEAD', url, false); http.send(); return http.status==200; }You could modify it so it returns true whenever anything in the 200s is returnedEDIT: not sure about other browsers, but it worked on mine. If it doesn't work it returns a status of 0 in which case the image won't be displayed so it'll be safe even if it doesn't work.
Worst comes to worst you could just make a php page or something on the server which just gets the status code of various urls, which wouldn't be that hard.
This. It works.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread