The site is Malicious - that nasty warning

[moshmage]

Hey, I felt compelled to warn you guys that (for some reason) Chrome seems to think you guys are malicious. But I know you're not, you're the cool kids from the neighborhood ;D

[Zren]

Is that so?

http://www.google.com/safebrowsing/diagnostic?site=openuserjs.org

Of the 10 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2014-10-25, and suspicious content was never found on this site within the past 90 days.

Does it appear on other browsers / a clean chrome profile?

[Zren]

Oh, I bet it's probably a favicon.

[Zren]

Yep.

https://openuserjs.org/scripts/Quackmaster/Quack_Toolsammlung has a favicon from http://s1.directupload.net/images/140622/yorwktnz.png which has a red WebOfTrust rating.

We probably should be mirroring the icons so they can't be used to track users, but a simple blacklist should work. There's probably an api out there we could use to check as well.

[Zren]

Okay, both https://www.mywot.com/en/scorecard/directupload.net and https://www.mywot.com/en/scorecard/s1.directupload.net are green, so not sure where the red wheel came from.

It seems that http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=s1.directupload.net

Has this site acted as an intermediary resulting in further distribution of malware?
Over the past 90 days, directupload.net appeared to function as an intermediary for the infection of 1 site(s) including livesportstream24.blogspot.com/.

is the reason why it's blocked. Though it's not like we're embeding a webpage, we're only fetching an image.

[Martii]

There's also this at http://www.ghacks.net/2014/10/25/google-blocks-bit-ly-chrome-and-firefox-affected/

Filtering services have a tendency to overreact historically (or is that hysterically? ;).

Thanks for the reports.

See also:

• https://openuserjs.org/announcements/No-IP’s Formal Statement on Microsoft Takedown

[Martii]

so they can't be used to track users

I also find these filtering services ironically amusing... "allow google (or some other entity) to track everything you do but no one else"... that spells monopoly and unfair trade practices.

I'm smart enough to block 3rd party images locally... e.g. it's my choice... not some commercial conglomerate that has issues. :)

[Martii]

Btw here is Firefox with a clean profile... notice the mouse cursor... this is how the other child browsers should handle reported (and requested services) site images:

• 
• 

http://www.google.com/safebrowsing/diagnostic?site=s1.directupload.net

Safe Browsing
Diagnostic page for directupload.net

What is the current listing status for directupload.net?

Site is listed as suspicious - visiting this web site may harm your computer.

What happened when Google visited this site?

Of the 821 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2014-10-27, and the last time suspicious content was found on this site was on 2014-10-23.

This site was hosted on 2 network(s) including AS16265 (FIBERRING), AS16276 (OVH).

Has this site acted as an intermediary resulting in further distribution of malware?

Over the past 90 days, directupload.net appeared to function as an intermediary for the infection of 1 site(s) including livesportstream24.blogspot.com/.

Has this site hosted malware?

No, this site has not hosted malicious software over the past 90 days.

How did this happen?

In some cases, third parties can add malicious code to legitimate sites, which would cause us to show the warning message.

EDIT: 😆 blogspot is google owned... so they should have attacked themselves first. Maybe... they could have seized their own domain name. ;) eyeroll

Bringing @QuackMaster 's attention to this discussion.

[jerone]

@moshmage commented on 28 okt. 2014 09:11 CET:

Hey, I felt compelled to warn you guys that (for some reason) Chrome seems to think you guys are malicious. But I know you're not, you're the cool kids from the neighborhood ;D

@moshmage Which version of Chrome are you running?
I'm running Version 40.0.2194.2 dev-m (64-bit) and I'm not getting this error:

[moshmage]

I'm using 38.0.2125.111 m

On 28 October 2014 10:11, Jeroen van Warmerdam notifications@github.com
wrote:

@moshmage https://github.com/moshmage commented on 28 okt. 2014 09:11
CET
#399 (comment):

Hey, I felt compeled to warn you guys that (for some reason) Chrome seems
to think you guys are malicious. But I know you're not, you're the cool
kids from the neighberhood ;D

@moshmage https://github.com/moshmage Which version of Chrome are you
running?
I'm running Version 40.0.2194.2 dev-m (64-bit) and I'm not getting this
error:
[image: chrome]
https://cloud.githubusercontent.com/assets/55841/4806568/a09602de-5e8a-11e4-94e0-92c52938db8d.jpg

—
Reply to this email directly or view it on GitHub
#399 (comment)
.

Continuação,
Mosh Mage

[Zren]

I'm using 40 too (40.0.2194.2 dev-m), visit the actual image url to get the warning.
http://s1.directupload.net/images/140622/yorwktnz.png

I don't get it from the front page, or any OUJS urls though.

[jerone]

@Zren commented on 28 okt. 2014 11:57 CET:

I'm using 40 too (40.0.2194.2 dev-m), visit the actual image url to get the warning.
http://s1.directupload.net/images/140622/yorwktnz.png

I don't get it from the front page, or any OUJS urls though.

Same here.
Question is, is this only with version 38 or are more version affected. Could cost a lot of visitors.

[Martii]

Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 (Clean profile Moz build)

EDIT: And using the @icon in Quackmasters current source of http://s1.directupload.net/images/140711/eshmcqzu.png e.g. not Zrens posted link this round.

[sebastian-quack]

Thank you for bringing this to my attention. I apologize for causing this mess! I will change the url to my favicon in the next update.

[Martii]

That's entirely up to you @QuackMaster . I get tired of the false reports from these services and having a browser block the incorrect domain is just bad business... There are several proverbial vernaculars out there for this, albeit too early to dig them all up at this moment, but at least this comes to mind:

• "Don't kill the messenger!" * Something google hasn't mastered yet.
• "One bad apple does not spoil the whole bin." * e.g. Limit persecution of an entire domain and everyone around them imho for the alleged actions of at least one report. I'm not fond of google but that doesn't mean someone in their organization doesn't have something to contribute constructively... however there are checks and balances in some browser releases that aren't being met as a whole.

[Martii]

If @sizzlemctwizzle considers this feasible there is something like https://www.npmjs.com/package/imageurl-base64 (untried at the moment) for @icon.

Then we could alter the metadata retrieval routine and/or script controller to return a data URI instead (serialized aka stored or not aka on the fly)... we would however need to scale to the standard of 48x48 first for static storage or 48x48 and 16x16 for dynamic... I don't know exactly how much extra db space that would use or server side CPU usage but could be an option from OUJS point of view... I would prefer not storing the data personally (due to legal constraints with DMCA) e.g. just do it on the fly but depends on if the drones can handle multiple calls out... but this still doesn't cover .user-content and .user-data and it shouldn't because this is not an OUJS generated issue.

I am definitely -1 against using a allow/block list to enable someone elses list without approval of each and every person in the world... e.g. that's not going to happen... Ad Block for example gives the end-user the ability to change the list.

However those browsers that are incorrectly identifying everyone around a particular url need to correct their implementations with a patch in that particular version... that's what they call esr's in the industry.

As far as a user/visitor standpoint upgrade/change (possibly disabling the service in) your browser... although it appears that Chrome still has the issue of showing the image.

As it stands now it is an "intended behavior" label (as close as I can get to our current labeling system... technically this could be "invalid" as well but reports like these are always appreciated) because OUJS is considered a pass through provider and not responsible for someone elses tagged domain especially when it comes to images.

See also:

• http://nodejs.org/api/buffer.html#buffer_buf_tostring_encoding_start_end

[Martii]

Just a FYI it appears the google list has removed that domain. e.g. a check right this moment on http://s1.directupload.net/images/140711/eshmcqzu.png no longer issues a warning in a clean Firefox.

Also tested in:

• Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36 (Chromium)
• Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 (Chrome)
• Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36 OPR/25.0.1614.63 (Opera)

---

Open a new issue for any RFEs please... closing without additional labeling at this time.

[ssokolow]

I also find these filtering services ironically amusing... "allow google (or some other entity) to track everything you do but no one else"... that spells monopoly and unfair trade practices.

To be fair, Mozilla goes out of their way to mask what you're doing when making SafeBrowsing requests in Firefox:
http://feeding.cloud.geek.nz/posts/how-safe-browsing-works-in-firefox/