Discussions » Greasy Fork Feedback

"Popup Blocker Script" sends all user data to a shady company; why is this okay? what can be done?

§
Posted: 2018-04-23

"Popup Blocker Script" sends all user data to a shady company; why is this okay? what can be done?

Hi. I was surprised recently to see that one of the most popular scripts on Greasy Fork not only tracks people, but has no obvious warning. Its bad behavior is not mentioned at all in the Greasy Fork description, but there is a link at the bottom to two 768x3200 pixel PNG images of a lot of legalese. How many of the thousands of people who installed the script actually clicked on the links, much less read and understood them? I think if it had been clearly explained, very few of them would have agreed to the bargain.

I thought it was pretty obvious the script did not belong on Greasy Fork, but when I reported it I was corrected and told that this is considered acceptable behavior for this community.

So my questions are:

why is this allowed? It doesn't seem to benefit the community. It's not even something people can legally learn from and fork as the legalese claims the code is a proprietary work.

And, ② what can be done to make it more obvious to people that the tradeoff of using this script is that they are agreeing that everything they do in their browser, even incognito and encrypted, can be sent to some shell corporation?

I suggest a new feature: clearly mark scripts that send information to a third party. There should be a big red warning label at the top for known tracking scripts so people know what bargain they are making and with whom. Perhaps there are some people who are okay with having their communications with, for example, their bank sent to an unknown third party, but I think even they would want Greasy Fork to have given some warning ahead of time.

§
Posted: 2018-04-24

Why is it allowed? Because there is no rule against it.

The site does not restrict what scripts do, as long as they are correctly identified as doing such. So you have scripts that container miners or ads or are not open source, as long as they state so. The user can choose whether any of these is a deal-breaker and not install.

The problem here seems to be that these potential deal-breakers may not be immediately obvious, as they can be for example buried in a lengthy description.

So the questions I have would be: a) What kind of behaviours other than those already mentioned merit some sort of indicator? b) What form should that indicator take? c) Is it perhaps more suitable for the script manager to warn rather than this site?

§
Posted: 2018-04-25

@JasonBarnabe said: b) What form should that indicator take? c) Is it perhaps more suitable for the script manager to warn rather than this site? I think this should be a dialogue box that offers 3 choices:
refuse / accept once/ agreed forever

§
Posted: 2018-04-29

ⓐ Other behaviours to flag? There are plenty of other behaviours that merit some indicator, but I think that discussion should be split off. This script is being installed by a lot of people right now and something needs to be done quickly to stop the damage.

ⓑ Form of indicators See my following posts.

ⓒ Whose responsibility? Script manager's? While it would be wonderful if the script manager also gave warnings — I'd love to see when a script phones home — I don't think that's actually its job. It could never manage to catch every tricky thing that Javascript allows.

How safe a script is is something that each user must decide for themselves. They can do that either by reading the script or by trusting the repository to represent it accurately. As can be seen from the example at hand, it's easy for authors to prevent the former: BZO Technologies Group has not only made their script too long for any normal human to read, they have made it illegal to do so in the Terms of Service. They have managed to obfuscate the script without minifying it.

So, the only real option is for a trustworthy repository.

§
Posted: 2018-04-29
Edited: 2018-04-29

Greasy Fork is the best place for userscripts because it has a clear rule that Users Must Know What a Script Does Before They Install It. I'm not alone in loving Greasy Fork for its rules that put the users first.

A simpler solution: clarify the rules

Greasy Fork is being abused by a bad actor that is actively working against the spirit of Greasy Fork's rules. BZO Technologies clearly does not want people to know what the script does before they install it.

An indicator will help the situation, but it's not ideal. It's more words on a page, which can lead to information overload. It's more work for the Greasy Fork volunteers to research, implement, revise, debug, and maintain. Also, it does nothing about future script writers who may do devious things the user ought to know about that we haven't thought of.

One word

I still think the correct solution is to forbid bad behaviour in the first place. The simplest way would be to add one word to the first rule:

Scripts must include a description here of what they do and may not do things unreasonably outside of this description. Users must know what a script will do before installing it. Scripts that include tracking or ads must disclose this in their descriptions.

The word "here" disallows problems like this where a script does something unreasonably outside the description that users see on Greasy Fork.

One word and a sentence

While one word would suffice for this situation, given BZO Technolgies's habit of obfuscation by hiding salient information amongst an ocean of irrelevant details, I'd suggest also adding a sentence that'd prevent them from doing the same on Greasy Fork:

Scripts must include a description here of what they do and may not do things unreasonably outside of this description. Users must know what a script will do before installing it. Descriptions must be easily understood. Scripts that include tracking or ads must disclose this in their descriptions.

This requires authors to post the description on Greasy Fork in plain language. This might seem to already be implied by the rule that "Users must know what a script will do before installing it", but apparently not. Greasy Fork allowed BZO Technologies's description of their Pop-up Blocker, even though the true behaviour of the script was thrice obfuscated: behind a link, written in legalese, and buried in length.




: A question for English linguists: I'm not sure how to succinctly describe hiding facts not by omitting them but by including too many irrelevant details in an attempt to overwhelm. "SNR", the engineering term for signal-to-noise ratio is what I mean, but few people would get it. What's a commonly understood English word or phrase for this tactic of verbal camouflage? It seems like there ought to be one as I've seen many politicians practicing it recently...

§
Posted: 2018-04-29
Edited: 2018-04-29

As I said, I'd prefer if the rules can be updated, but if not, we'll need an indicator.

ⓑ What form should that indicator take?

It should have these characteristics:

  • Prominent so users see it before the INSTALL button is hit. Perhaps located both at the top of the description and right before the INSTALL button.
  • Just a badge. Maybe an image, but could just be text +CSS. Not necessary for it to be a dialogue box that asks you questions nor a pop-up that needs to be dismissed
  • Visually an important warning. For example, a big, red stop sign or a large, yellow ⚠ warning symbol.
  • Contains short text describing the deal-breaker Examples:
    • SHOWS ADVERTISEMENTS
    • SENDS DATA TO A THIRD PARTY
    • PROPRIETARY LICENSE
    • SOURCE CODE UNUSUALLY LONG
    • CONTRACT TAKES EXCESSIVE RIGHTS

It would be nice if the indicator had these characteristics:

  • Mouse over gives more information E.g., _CONTRACT TAKES EXCESSIVE RIGHTS: Using this program grants the author permissions and rights beyond what is needed for this userscript to function.
  • A link for specific information about this user script Please click here to go to the forum topic on this userscript.
  • A link to userscripts other Greasy Fork users have offered up as replacements for this one that do not have the same dealbreaker.
§
Posted: 2018-04-29

@hackerb9 said: I still think the correct solution is to forbid bad behaviour in the first place. The simplest way would be to add one word to the first rule:

Scripts must include a description here of what they do and may not do things unreasonably outside of this description. Users must know what a script will do before installing it. Scripts that include tracking or ads must disclose this in their descriptions.

This is a reasonable and easy step and is what I originally meant by the rule. I'm not convinced of the exact word "here", but I will think about it and revise the wording.

Note though that the script in question has already had its description updated.

§
Posted: 2018-04-30

This is a reasonable and easy step and is what I originally meant by the rule. I'm not convinced of the exact word "here", but I will think about it and revise the wording.

That's great! Thank you.

Note though that the script in question has already had its description updated.

That's also good news. I'll check it out.

Post reply

Sign in to post a reply.