search

OpenUserJS / OpenUserJS.org

The home of FOSS user scripts.
https://openuserjs.org/
GNU General Public License v3.0
833 stars 300 forks source link

Terms of Service/Privacy Policy/DMCA #116

Closed Martii closed 10 years ago

Martii commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/issues/116#issuecomment-44718383 .

sizzlemctwizzle commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/issues/116#issuecomment-44718383 .

Martii commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/pull/121#issuecomment-44744575

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

TOS.md still needs Licensing header filled out.

This includes:

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

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

sizzlemctwizzle commented 10 years ago

Statistics gathered, if any

I can at least answer this one right now: none at all. However, if/when we add advertisement I assume the adsense (or whoever) will gather statistics.

Martii commented 10 years ago

Implied MIT License (Expat) when @license (and alternate spelling) is absent in a published work and has been determined by sizzle due to lack of chatter and I concur... flexible enough to use with just about any license. :) This license type is OSI approved... if someone wants a different @license they will be able to define it in their code. :)

sizzlemctwizzle commented 10 years ago

due to lack of chatter

@OpenUserJs/admin @OpenUserJs/backend @OpenUserJs/frontend

Martii commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/issues/116#issuecomment-48397226 .

Martii commented 10 years ago

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 commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/issues/116#issuecomment-48409635 .

Martii commented 10 years ago

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 commented 10 years ago

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 https://github.com/OpenUserJs/OpenUserJS.org/issues/116#issuecomment-48413020 .

Martii commented 10 years ago

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 commented 10 years ago

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!