Terms of Service/Privacy Policy/DMCA

[Martii]

For moderators and above we really need this in order to effectively manage OUJS.

Currently a few questions for administration off the top of my head:

1. Do we allow obfuscated scripts?
2. Do we allow minified scripts?
3. Do we allow auto liking scripts provided they are VERY CLEAR on their intentions on their OUJS homepage as well as in their source?
4. More questions will probably arise...

Regardless of the state of this issue this needs to be created immediately and can be worked on a piece at a time.

[sizzlemctwizzle]

My opinions:

Do we allow obfuscated scripts?

No. Going out of your way to hide what your script does is malicious behavior.

Do we allow minified scripts?

I don't see the harm as long as it doesn't obfuscate.

Do we allow auto liking scripts provided they are VERY CLEAR on their intentions on their OUJS homepage as well as in their source?

My general rules for deciding to remove a script:

1. Does it do (or at least genuinely attempt) what it claims?
2. For functionality that isn't explicitly described/mentioned, is it in the spirit of the script's advertised purpose?
3. Is the code transparent with no attempt to hide its intent?

If the answer to any of these questiond is no, I remove the script.

It's all about being honest and acting in good faith. If you wrote a script called "Cookie Monster" and advertised that it "captures the cookies of every site you visit and sends them to a third-party server to compromise all of your secure accounts", and the script actually does steal your cookies, I wouldn't remove it because description is honest. It works as advertised, with no chance of the user being surprised by the result.

On the other hand, suppose there was script that claims to auto link plaintext urls on any page, and additionally make mailto: links open in a Gmail popup. Let's say that the auto linking sort of works, but it misses some plaintext urls, and mangles some of the urls when building the hyperlinks. So far it is a crappy script but at least attempts to do what it claims. But upon examination of the source, I find that there is no code that even tries to detect mailto: links and do anything with them. I would remove this script because the description is a bold face lie. I don't care if the author was getting around to adding that feature once they got the kinks out of the auto linking. It is false advertisement and active deception. No effort was made to live up to what the author promised.

[Martii]

Sounds good...

What I was tinkering with on USO a bit before it did its most recent thing was a way to allow end-users to "self-minify" (possible node lib for OUJS) and "self-pack" installations... just to conserve space/bandwidth and minimally protect from certain kinds of detection from maleficent sites. The ultimate intent is to encourage open source for peer review and discourage code that no one can easily read on our site... all before installing... ideally this would be great if it was handled in the user.js engines as an option but that probably won't go over well with GM due to the complexity and no guarantee on adoption elsewhere.

Currently this user (and now this user too) has some obfuscations is why this needs clarification. I thought out some of the "strikes" procedures... the rating/issues of course is full peer review... wait a little while... kill the script(s)... if they make an attempt to continue it then kill the user account... of course if it's blatantly obvious that it's malicious just remove the script/user.

Keeping this open for a bit so others can pipe in if they want to... from other time zones too. :)

[sizzlemctwizzle]

A while back I removed a user who posted a scam script. It made a bold
claim and after carefully examining the code, I concluded that there was no
way it could do what was advertised and it kept linking to some website for
no clear reason. This is an example of when you should just remove a user
immediately if you're an admin.
On May 31, 2014 12:18 AM, "Marti Martz" notifications@github.com wrote:

Sounds good...

What I was tinkering with on USO a bit before it did its most recent thing
was a way to allow end-users to "self-minify" and "self-pack"
installations... just to conserve space and protect from certain kinds of
detection. The ultimate intent is to encourage open source for peer review
and discourage code that no one can read.

Currently this user https://openuserjs.org/users/demon has some
obfuscations is why this needs clarification. I thought out some of the
"strikes" procedures... the rating/issues of course is full peer review...
wait a little while... kill the script(s)... if they make an attempt to
continue it then kill the user account... of course if it's blatantly
obvious just admin the script/user.

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

[sizzlemctwizzle]

I really hate scripts with nondescript names and no description. I really
just want to ban them.
On May 31, 2014 2:36 AM, "Michael Medley" medleymind@gmail.com wrote:

A while back I removed a user who posted a scam script. It made a bold
claim and after carefully examining the code, I concluded that there was no
way it could do what was advertised and it kept linking to some website for
no clear reason. This is an example of when you should just remove a user
immediately if you're an admin.
On May 31, 2014 12:18 AM, "Marti Martz" notifications@github.com wrote:

Sounds good...

What I was tinkering with on USO a bit before it did its most recent
thing was a way to allow end-users to "self-minify" and "self-pack"
installations... just to conserve space and protect from certain kinds of
detection. The ultimate intent is to encourage open source for peer review
and discourage code that no one can read.

Currently this user https://openuserjs.org/users/demon has some
obfuscations is why this needs clarification. I thought out some of the
"strikes" procedures... the rating/issues of course is full peer review...
wait a little while... kill the script(s)... if they make an attempt to
continue it then kill the user account... of course if it's blatantly
obvious just admin the script/user.

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

[Martii]

Me too... that's why I built Count Issues... if I can catch up enough here between my testing and other duties I'll probably do something similar for OUJS but I'm "dain bread" from earlier today... need time to absorb everything learned today. :) Tiny url types are frustrating as well.

[sizzlemctwizzle]

allow end-users to "self-minify" (possible node lib for OUJS) and "self-pack" installations... just to conserve space/bandwidth

Could easily compress (deflate, gzip, etc.) them and that would make them much smaller, but since I don't really have a problem with bandwidth and I don't want to waste computational resources since those are more valuable with Nodejitsu. User scripts are very small so I don't understand why they'd care about the size on their end.

and minimally protect from certain kinds of detection from maleficent sites.

How would that work?

[Martii]

User scripts are very small so I don't understand why they'd care about the size on their end.

Not always. Consider storage capacities on cell phones for example. With all the apps that people get plus user.js, if there's a cluster size (depends on formatting), phones that have fixed memory instead of replaceable, and the list goes on.

Could easily compress (deflate, gzip, etc.) them and that would make them much smaller

See #121 (comment)

Already showing as being done.

but since I don't really have a problem with bandwidth

Notice the word "I" here in your sentence... as well as... since you have unlimited bandwidth this leads to this...

and I don't want to waste computational resources since those are more valuable with Nodejitsu

Then it could be done just once before it hits nodejitsu... and would ease up their computational resources by not having to gzip it on the fly back to the end user. ;)

Regardless of whether it could be implemented it would be encouraging open source rather than encouraging authors to minify/obfuscate. It would also keep the moderators and up from getting burnt out too quickly. I may end up doing this in my cross-stream of GM at some point but until recently my machines were slower than a snail... MITM seems to be the current route in the short term assuming I get some more time to work on that feature.

How would that work?

Think // @grant none and someone who didn't bother to use an IIFE and is forced to use JavaScript on a site. The separation between the Sandboxed scope and the Content scope is getting wider... and a few things may break with anyone who is using unsafeWindow or wrappedJSObject in the near future as Anthony pointed out recently.

[sizzlemctwizzle]

Already showing as being done.

I didn't realize Express compresses streams too. Good to know.

Regardless of whether it could be implemented it would be encouraging open source rather than encouraging authors to minify/obfuscate. It would also keep the moderators and up from getting burnt out too quickly.

This is good reason to implement minifying on the site. If we do it for them, maybe they'll let us get a look at the original source. I'd also give us good cause to ban minified scripts on the site since there would no longer be a valid reason to upload them.

[Martii]

give us good cause

Now I think we're in the same book now. ;) :) I've had a few years to think about this with installWith... just haven't had much chance to do anything server side instead of MITM and maintaining things that I didn't have raised privileges for. Plus it could definitely give OUJS more of an edge. Doesn't have to be right away but thank you for considering it. :) I have many more ideas just need the time to present/share, implement, test, and get deployed... and ease the learning curve for myself too.

[sizzlemctwizzle]

I have many more ideas

I have tons of ideas, most of which are half-baked (my imagination far exceeds my grasp). Most of my cycles go towards existing things that need to get done.

[Martii]

Just so you are aware... I've been tracking some questionable users so far and this author had a script that was questionable but now it's gone... need determination on what to do with these people. It would be highly recommended to get flagging working soon so we can track these on site rather than off site.

[Martii]

And now that author is back just within the last 17 minutes with more auto-liking... I've given official "warning" in the issues... If either one of those scripts (this and this) "disappear" again... I will consider this malicious I think.

[TriMoon]

Why not have a delayed publication system instead?
That way newly uploaded scripts will not be published on the site until mods approve it.
It will be much easier to prevent bad scripts.
From a user-side its ofcourse something that is not liked much because we will need to wait, but it's worth it IMHO to prevent the site from getting bad-name....

[TriMoon]

You could even add some kind of approved rating to script writers that write approved scripts.
Those with enough rating would not need to wait for their scripts to be published, and their rating can be adjusted if they put bad code on :)

[sizzlemctwizzle]

That way newly uploaded scripts will not be published on the site until mods approve it.

1. There just aren't enough trusted people to review and test scripts, and all their updates, to make sure they aren't malicious.
2. This is the system used by mobile app stores, and browser extension galleries. User scripts are updated far more frequently than apps and extensions, and implementing a system that has far fewer reviewers than scripts would quickly create an enormous backlog, with users waiting for vital updates that may become outdated by the time they get approved.
3. If a malicious script gets accidentally (or god forbid, intentionally) approved then we can basically be held accountable for any damage that it causes since we gave it our rubber stamp of approval. If we pretend that we can always detect a malicious script, then we are giving people a false sense of security. On the other hand, if we reject a script that is harmless, we could end up looking like morons.
4. I just don't think this goes with the philosophy of openness that the site promotes.

In conclusion, I believe a review-based approval system for deciding which scripts and updates should be published to the site would hurt it far worse than it could ever help. The best solution is putting in place proactive measures to warn moderators and users of potentially malicious scripts, and letting users and moderators work to together to remove malicious scripts. Punishing everyone (the most active script authors will be the most inconvenienced, and they are our greatest draw) for the actions of a tiny minority is a terrible idea. It might make users feel safe, but it will push script authors elsewhere (I know I'd leave) and users will eventually follow them once they realize all the best scripts are being published somewhere else.

[Martii]

TOS.md still needs Licensing header filled out.

This includes:

• Default licensing if not specified for published works including snippets... copyright is always implied when posting and is different than licensing.
• What types of licensing we support (OSI I presume at the very least)
• Agreement that OUJS has the implied right to publish, distribute and terminate access to an account holders published works
• Since we allow forking this needs clarification

---

Now for PRIVACY.md we need to at least describe:

• Cookie usage
• JavaScript requirements... seems that bootstrap needs it for the menus when the viewport is tiny. Same with cloudflare and showing some images.
• Account usage, if any
• Statistics gathered, if any
• Third party usage and a brief summary of their terms or noting they have some too and which ones and where (usually part of OAuth agreements). Since I'm not familiar with cloudflare until recently I will need some help with this in the comments or the doc itself. themes.googleusercontent.com also needs to be explained for downloadable font(s).

---

Legal stuff sucks I know... but a necessary evil for full transparency. :)

[Martii]

What types of licensing we support (OSI I presume at the very least)

If we include public domain I just read this implies no copyright rights from OSI... do we still want to include this type and related unlicensing?

---

Found discussion on #56

[Martii]

Do we care about porn linked images for the TOS? e.g. since it's not hosted here and we aren't the culprit?

[cletusc]

I'd say remove them unless we want to come up with an "18+" option for script pages. I know there are plenty of scripts out there for 18+ sites, but whether they would need to link porn images... I'm leaning towards not.

[sizzlemctwizzle]

As long as it's legal in USA (where the site is hosted), I don't care.
On Jul 8, 2014 3:45 PM, "Marti Martz" notifications@github.com wrote:

Do we care about porn linked images for the TOS? e.g. since it's not
hosted here we aren't the culprit?

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

[Martii]

The only thing I can think of is bad parental controls blacklisting our domain without it... if it's a good software then it will prevent the image from being shown.

[sizzlemctwizzle]

What portion of internet users actually have parental controls enabled? I'd
rather lean on the side of free speech at the risk being blocked by crappy
software.
On Jul 8, 2014 5:52 PM, "Marti Martz" notifications@github.com wrote:

The only thing I can think of is bad parental controls blacklisting our
domain without it... if it's a good software then it will prevent the image
from being shown.

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

[Martii]

Well pixelated images I wouldn't care about... seeing actual porn at 800ish rez I might. I too am for free speech but I'd rather not see us turn into adult user.js... although that may have a certain appeal to the younger scripters and users visiting. ;) Let's take this portion on a case to case basis for the moment... e.g. leave it undefined and see what kind of results we get. So far I haven't seen any on OUJS yet... but that doesn't mean they aren't lurking about.

[sizzlemctwizzle]

I agree with you. We should deal with it on a case by case basis for now and see how it goes.
On Jul 8, 2014 6:35 PM, "Marti Martz" notifications@github.com wrote:

Well pixelated images I wouldn't care about... seeing actual porn at
800ish rez I might. I too am for free speech but I'd rather not see us turn
into adult user.js... although that may have a certain appeal to the
younger scripters and users visiting. ;) Let's take this portion on a case
to case basis for the moment... e.g. leave it undefined and see what kind
of results we get. So far I haven't seen any on OUJS yet... but that
doesn't mean they aren't lurking about.

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

[Martii]

I'm going to to attempt to finish this off tonight... I believe that I've got a current grasp on the PRIVACY now... only remaining thing I need to know is if we do or don't support non-OSI licensing... I can go off of #56 for public domain and the other weirder licenses if I need to if no one comments here. It's already clear that no derivative licenses are expressly prohibited... so that will also get in there for TOS.

[joeytwiddle]

If you ban or flag malicious users, they can always just create a fresh account and start over.

Given that, a positive reputation system might work better. Something like StackOverflow's. Give each user a score (or give each script a score), and let it increase as people review and vote on scripts.

Note sure exactly how it would work, but it's something to consider.

In fact I think the web needs a cross-site positive reputation system. So I don't have to fill out three Captcha's a day. The web should know by now I'm not an SEO spammer!