Monetization disclosure

JasonBarnabe commented 5 years ago

Currently scripts must say in their descriptions if they have monetization methods like miners or ads. This is easily missed by users. Instead, have the authors specify what they do and present this to users when they install.

After a grace period, if scripts have undisclosed monetization, then mods can delete them.

KOLANICH commented 4 years ago

https://f-droid.org/wiki/page/Antifeatures

jixunmoe commented 4 years ago

How about make the install button to be "yellow" instead of green?

KOLANICH commented 4 years ago

An additional confirmation dialog with a captcha I guess (This script contains following antifeatures: .... . If you are sure you want to install this script please type `I wanna install this script despite of its antifeatures!`. The check should be implemented in pure html + css using valid trick.

Enforcement:

it's script authors must mark the scripts as containing antifeatures. On detection of a script with any not marked as such with special fields in a metadata block (@antifeature <name> <justification>, justification is mandatory (because I don't respect users of my scripts is accepted, it is here is to just make a bit less comfortable to insert antifeatures) and may not contain links), accounts published them should be immediately suspended, their scripts audited, the ones with antifeatures should be disallowed to be downloaded in GUI untill the all the antifeatures are cleaned (either hy an author or by a third party). Probably it should modify the EULA to allow the users to upload scripts under free open source licenses only.

JasonBarnabe commented 3 years ago

@antifeature <name> <justification> seems like a good format to me. I would also add the possibility of localization, so you could do

@antifeature:en ads A small ad in the corner to pay my bills.
@antifeature:es ads Uno pequito no hablo espanol.

I think that this would be presented in short form as part of the stats block of the script - definitely on an individual script's page, possibly in listings/search results as well. When the user presses the install button, a confirmation dialog would come up, saying something like:

This script inserts ads on the sites you browse. The script author provides this description:

"A small ad in the corner to pay my bills."

[ Continue with installation ] [Cancel ]

The justification would be optional - if not provided then that part would be omitted.

Possible <name>s based on what is currently allowed on the site: ads, tracking, miner. Any other <name> would be disallowed.

KOLANICH commented 3 years ago

The justification would be optional - if not provided then that part would be omitted.

Or maybe use a default one Because this script maintainer is an asshole.

KOLANICH commented 3 years ago

Not miner, but resource_abuse. They can be abused not only for mining. I.e. DDOS (this really can happen, one of the largest social networks was caught on it), distributed computation, redundant storage without cryptocurrency (i.e. hardcoding a blob and using WebRTC to form a p2p net, so one can fetch the blob later from one of the users of a script) ...

Also unwanted_functionality, like doing destructive actions when some conditions are met.

Also escalation, when a script exploits a vulnr in a script manager (i.e. some script managers allow (because of lack of filtration) to send messages to other extensions and use some webext API which usually must not be exposed to userscripts), not necessarily doing anything malicious, maybe useful, but a vulnr is a vulnr and it may and must disappear in future.

JasonBarnabe commented 3 years ago

The idea is to enumerate things that would actually be allowed to be posted to Greasy Fork.

KOLANICH commented 3 years ago

I don't think they should be really disallowed and censored. But the ones publishing this code that is likely acting against its users' best-interests should explicitly say that their code has these antifeatures. If they are ashame to inform everyone they have embedded them, then they probably should not embed them. If they are not ashame, they should explicitly say "I'm that asshole who has embedded them, it's my right to write any code I want, and it's your right to dig into the code and remove the things you don't like, but I won't do that for you.".

JasonBarnabe commented 3 years ago

The basic implementation is in. Here's a test script.

jixunmoe commented 3 years ago

Has this version been deployed? What do I expect to see? I can't see anything different...

Edit: I see, the message only pop up when you click install. I think it would be easier to have it displayed without attempting install as well.

JasonBarnabe commented 3 years ago

Yeah I've only done the install confirmation so far. The stats area will get the info in brief as well.

JasonBarnabe commented 3 years ago

Now showing antifeature (pretty subtly) in the stats area as well.

erosman commented 3 years ago

@antifeature seems like a good format to me. I would also add the possibility of localization, so you could do

Should @antifeature be a single or multiple entry in metadata block?

@antifeature    multiple    A small ad in the corner to pay my bills + a miner + GA

... or ...

@antifeature    ads         A small ad in the corner to pay my bills.
@antifeature    miner       a miner
@antifeature    GA          Google Analytics

TBH, the multiple lines plus multiple localization for each may bloat the metadata block. Furthermore, userscript developers may not elect to emphasise such behaviour anyway.

Therefore, if a single string is adapted, the <name> tag will also become less relevant and a max 2 part entry would be sufficient. e.g. @antifeature <detail>

Entry without disclosed detail (i.e. true/false)

@antifeature

Entry with disclosed detail

@antifeature    A small ad in the corner to pay my bills + a miner + GA

:thinking:

KOLANICH commented 3 years ago

IMHO eliminating the classes of antifeatures defeats the purpose of their introduction.
IMHO localization is not needed. Instead the lingua-franca in the region of the audience of the targeted website should be used.

JasonBarnabe commented 3 years ago

Should @antifeature be a single or multiple entry in metadata block?

Multiple, one per combination of locale and type.

TBH, the multiple lines plus multiple localization for each may bloat the metadata block.

IMHO localization is not needed. Instead the lingua-franca in the region of the audience of the targeted website should be used.

If it's a single-language script, you don't need to specify a locale. It's the same as @name and @description - most scripts do not need the localization feature, so they can ignore it and just use non-localized keys.. For those scripts that do want to offer multiple language, they can use things like @name:fr, @description:fr, and @antifeature:fr.

erosman commented 3 years ago

Question is, who will be adding the @antifeature?

Is it something that GreasyFork should add to warn users? Then the localization and multiple entries will not be as relevant.
Is it something that userscript developers should add? Then why would antifeature developers add something that would limit & reduce the exposure of their userscript? Would scammers put a warning label on their source of scam/income and in multiple languages? Anti-Features is a label bestowed by independent 3rd parties and not the developer of the spam/scam.

KOLANICH commented 3 years ago

Question is, who will be adding the @antifeature?

I guess, script authors.

Then why would antifeature developers add something that would limit & reduce the exposure of their userscript?

I guess otherwise they will just get banned. For malware spreaders it inevitable (without 100% premoderation, which is infeasible for this project) be after the script is shown to real users, but these tags are for the ones who obey the rules and do not try to spread malware covertly. I.e. in F-Droid there are antifeatures "this app promotes non-free services" or "this app depends on a non-free library". Not necessarily malicious, such apps are beneficial for everyone, but in long term they are harmful everyone except the parties controlling them.

Anti-Features is a label bestowed by independent 3rd parties and not the developer of the spam/scam.

It is expected to be set by the person publishing the app in F-Droid. It can be an author/maintainer of an app, and quite often it is he. GreasyFork also can be not a primary source of a script, one can publish third-party scripts there too.

JasonBarnabe commented 3 years ago

This feature is complete as far as I'm concerned.

If script managers implement the same kind of warning then I can make Greasy Fork skip showing the warning too, assuming I can tell which script manager is being used.

I've updated the rules to say that antifeatures must be specified with this key, rather than just in the script's description. I'm going to give a grace period for people to update their scripts, as well as make an announcement.

erosman commented 3 years ago

If script managers implement the same kind of warning then I can make Greasy Fork skip showing the warning too

I think it is good to have both.

PS. Is there a good icon for @antifeature :thinking:

KOLANICH commented 3 years ago

Is there a good icon for @antifeature

☠️

greasyfork-org / greasyfork

Monetization disclosure #604