Scratch

http://scratch.mit.edu/forums/viewtopic.php?id=93386

I have to agree with you though, it's not very well thought out in terms of only allowing imageshack. I can see why you might allow sites such as http://imgclean.com/ but guess what? They're blocked as well!

Sorry guys - all I can say is we're busy.   
We thought we had a patch ready that would allow us to re-enable images last week, but it needs some more work and the dev who wrote it was out of town. Probably I should've reverted the whole thing, but I didn't anticipate anyone trying to use bbcode img tags cuz, well, images are off.

In any case, I hope to have the fix online soon. Imageshack won't be the only host we'll allow. Currently, the regex is as follows:
$imageHosts = '/http:\/\/.*(\.imgur|\.tinypic|\.imageshack|\.photobucket|\.modshare|scratch).*\/.*/';

Any recommendations on alternatives? Also, if imageshack is blocked sometimes, perhaps we should make a different recommendation in the error message. Unfortunately, imgclean won't allow you to embed images, so they aren't a good option after all.

Sparks - here's is the changeset:
http://www.assembla.com/code/scratchforums/subversion/changesets/89

From the problem you describe, we may have to avoid diving in to check bbcode if it's wrapped in code tags. If you'd like to submit a patch, by all means, do! Otherwise, I'll add this to the list.

Last edited by Lightnin (2012-04-02 21:27:54)

Lightnin wrote:

Sorry guys - all I can say is we're busy.   
We thought we had a patch ready that would allow us to re-enable images last week, but it needs some more work and the dev who wrote it was out of town. Probably I should've reverted the whole thing, but I didn't anticipate anyone trying to use bbcode img tags cuz, well, images are off.

In any case, I hope to have the fix online soon. Imageshack won't be the only host we'll allow. Currently, the regex is as follows:
$imageHosts = '/http:\/\/.*(\.imgur|\.tinypic|\.imageshack|\.photobucket|\.modshare|scratch).*\/.*/';

Any recommendations on alternatives? Also, if imageshack is blocked sometimes, perhaps we should make a different recommendation in the error message. Unfortunately, imgclean won't allow you to embed images, so they aren't a good option after all.

Sparks - here's is the changeset:
http://www.assembla.com/code/scratchforums/subversion/changesets/89

From the problem you describe, we may have to avoid diving in to check bbcode if it's wrapped in code tags. If you'd like to submit a patch, by all means, do! Otherwise, I'll add this to the list.

Looks absolutely smashing.

Lightnin wrote:

Sorry guys - all I can say is we're busy.   
We thought we had a patch ready that would allow us to re-enable images last week, but it needs some more work and the dev who wrote it was out of town. Probably I should've reverted the whole thing, but I didn't anticipate anyone trying to use bbcode img tags cuz, well, images are off.

In any case, I hope to have the fix online soon. Imageshack won't be the only host we'll allow. Currently, the regex is as follows:
$imageHosts = '/http:\/\/.*(\.imgur|\.tinypic|\.imageshack|\.photobucket|\.modshare|scratch).*\/.*/';

Any recommendations on alternatives? Also, if imageshack is blocked sometimes, perhaps we should make a different recommendation in the error message. Unfortunately, imgclean won't allow you to embed images, so they aren't a good option after all.

Sparks - here's is the changeset:
http://www.assembla.com/code/scratchforums/subversion/changesets/89

From the problem you describe, we may have to avoid diving in to check bbcode if it's wrapped in code tags. If you'd like to submit a patch, by all means, do! Otherwise, I'll add this to the list.

why don't you add the block library website where images are stored and somehow include any website on the approved member created websites list.

sparks wrote:

Hey cool! Thanks for explaining    I would suggest adding blocks.scratchr.org and resources.scratchr.org to the list, as well as the imgclean site suggested above as a safe host.

I actually corresponded with the imgclean founders, and was planning on using them exclusively for a while. But then they said they weren't going to allow direct embedding in forums (can't just use [img]theirUrl[/img]  - have to link to the page on their site). Unless they've changed that, they don't seem like a good option.

sparks wrote:

I might have a look at making a patch, but I don't think it's likely I'll have something out this week, I have a coursework deadline tomorrow :S

I suppose there are too many legal issues and moderation issues with Scratch having a file hosting service for use with forum images...

Alas, yes.

sparks wrote:

I think it's great though, that you're looking for a safe solution to allow image use in the forums, thank you very much    (Though with antidote it hasn't affected me much 

Cool - we might have to ask that people stop using it once we make normal image posting work again. For mods, it's a pain to have to have to use multiple views based on plugins to see how the same page looks depending on what someone is viewing it with. It would be possible to host a bad image that we couldn't quickly and easily see....

sparks wrote:

...OH NO. This means that the block library is going to need a huge amount of its images rehosted! They're all over the place! Private hosts, weebly, dropbox... We actually phased out all of our imageshack ones cos some people couldnt see them    I suppose we could move them all to blocks.scratchr.org if it's whitelisted 

Actually, no - one advantage of this approach is that it only checks at post / edit time. If the image was posted before the change, it's fine (as long as you don't edit it).

sparks wrote:

EDIT: I'm reading through the changeset at the moment and I'm wondering if stopping the img inside code scanning is actually a good idea. Are you guys wanting people to be unable to LINK to images using URL tags and just pasting the image as well as unable to display them, or is it out of your hands if someone follows one of those?

Hmm... not sure I totally get what you are saying. Mainly, it's stuff between [img] tags that we want to be careful of.

sparks wrote:

EDIT2: Ooh! I notice you've stopped the Scratch image redirect trick 

Yeah, but again - only for new posts, or edits of old posts.

sparks wrote:

Yeah, I worked out from the code it's only during-edit or submission that the images are parsed, but the block library's posts are edited a lot to encorporate new blocks, in which case as soon as say, the sounds category for Panther blocks is edited, the entire post would have to have its images converted before the change can be made. However, I think that it's worth doing that anyway, since a single host is a good idea.

lightnin wrote:

Hmm... not sure I totally get what you are saying. Mainly, it's stuff between [url]tags that we want to be careful of.

I mean something like someone posting

shadyGuy wrote:

Hey everyone, check out this amazing drawing I did: http://badImagesAreUs.com/Images/totallyNotASuspiciosURLButYouGetTheIdea.png

I suppose that's less intrusive and directly dangerous than a plugged-in image though.

You mentioned a new reporting system, will that have a checkbox system for "bad images" which hides the posts' images until a mod can look at them?

Yes, links happen.  This really isn't about making us bullet proof - that's not possible. And there will always be trolls of various sorts.  It's more to make it a bit harder to post links to bad stuff, without, hopefully, making normal image posting too much of a pain.

The new reporting system will just temporarily hide a post that's had >4 reports (sort of like what happens with projects). It'll also temp. block the account. >4 reports on a post for normal stuff (move / edit topic, etc.) happens very rarely, so we hope this won't have many negative side effects. Of course, there's potential for abuse, but that'll result in a block (as it does on the main site).  Oh yeah, only Scratcher reports count towards the 4.

It'd make sense that ScratchR.org would be allowed....

I had a look through the various change-sets and I can't say that you did a bad job. The code looks good to me and fit for tackling this image problem.

Would it be too much to whitelist Dropbox image URLs, however? If you're worried about the site's policies being to lenient, I had a look at the Terms and Acceptable use pages and return triumphant!
Here are a couple excerpts.

You, not Dropbox, will be fully responsible and liable for what you copy, share, upload, download or otherwise use while using the Services. You must not upload spyware or any other malicious software to the Service.
...
you must not:
- plant malware or otherwise use the Services to distribute malware;
- send unsolicited communications, promotions or advertisements, or spam
- publish anything that is fraudulent, misleading, or infringes another's rights
- publish or share materials that are unlawfully pornographic or indecent, or that advocate bigotry, religious, racial or ethnic hatred
- violate the law in any way, or to violate the privacy of others, or to defame others.

You may fine these pages at /terms and /acceptable_use of the Dropbox website.

roijac wrote:

what about that?
$imageHosts = '(/http:\/\/)?.*(\.imgur|\.tinypic|\.imageshack|\.photobucket|\.modshare|scratch).*\/.*/';

http:// for the beginning, but special characters (like slash) need to be escaped by preceding backslashes.

Lightnin wrote:

LS97 wrote:

I had a look through the various change-sets and I can't say that you did a bad job. The code looks good to me and fit for tackling this image problem.

Would it be too much to whitelist Dropbox image URLs, however? If you're worried about the site's policies being to lenient, I had a look at the Terms and Acceptable use pages and return triumphant!
Here are a couple excerpts.

You, not Dropbox, will be fully responsible and liable for what you copy, share, upload, download or otherwise use while using the Services. You must not upload spyware or any other malicious software to the Service.
...
you must not:
- plant malware or otherwise use the Services to distribute malware;
- send unsolicited communications, promotions or advertisements, or spam
- publish anything that is fraudulent, misleading, or infringes another's rights
- publish or share materials that are unlawfully pornographic or indecent, or that advocate bigotry, religious, racial or ethnic hatred
- violate the law in any way, or to violate the privacy of others, or to defame others.

You may fine these pages at /terms and /acceptable_use of the Dropbox website.

Maybe. Thing is, there's no way to flag content on Dropbox. The other hosts are either curated, or have ways that people can report stuff - which is a little better. If someone uses one of them to post bad stuff, we'd like for them to get blocked from here and get blocked from there, if possible.

Nothin's perfect, but there could be value in tying in with other services' security models.

I see your point. It would be a pity if you didn't allow Dropbox as a host, however, because so many people use it for Forum images due to its simplicity and glitch-less system.

Lightnin wrote:

sparks wrote:

Yeah, I worked out from the code it's only during-edit or submission that the images are parsed, but the block library's posts are edited a lot to encorporate new blocks, in which case as soon as say, the sounds category for Panther blocks is edited, the entire post would have to have its images converted before the change can be made. However, I think that it's worth doing that anyway, since a single host is a good idea.

lightnin wrote:

Hmm... not sure I totally get what you are saying. Mainly, it's stuff between [url]tags that we want to be careful of.

I mean something like someone posting

shadyGuy wrote:

Hey everyone, check out this amazing drawing I did: http://badImagesAreUs.com/Images/totallyNotASuspiciosURLButYouGetTheIdea.png

I suppose that's less intrusive and directly dangerous than a plugged-in image though.

You mentioned a new reporting system, will that have a checkbox system for "bad images" which hides the posts' images until a mod can look at them?

Yes, links happen.  This really isn't about making us bullet proof - that's not possible. And there will always be trolls of various sorts.  It's more to make it a bit harder to post links to bad stuff, without, hopefully, making normal image posting too much of a pain.

The new reporting system will just temporarily hide a post that's had >4 reports (sort of like what happens with projects). It'll also temp. block the account. >4 reports on a post for normal stuff (move / edit topic, etc.) happens very rarely, so we hope this won't have many negative side effects. Of course, there's potential for abuse, but that'll result in a block (as it does on the main site).  Oh yeah, only Scratcher reports count towards the 4.

Here's an idea:
Black lists!
For example, if bad images came from www.badsite.com, you could set your php to turn all links to www.badsite.com into This site is blocked by the scratch team.
The whitelist thing annoys me because it blocks my sites.  For example, if I want to have a vote counter, I can't because the whitelisted sites don't support redirects or php images.