I'm inclined to wontfix this and accept the risk on it

I agree, particularly since the ability to view other users' JS is what led to the Gadgets extension.

Users are more likely to expose personal information on their user pages, IMO.

The complete solution to this would be to force all client Javascript components to be gadgets, and instead only allow users to enable gadgets rather than have custom arbitrary code. (There's also the related discussion on code review of gadgets and global JS.)

However, I'm sure we all know how well that would go over with the community. I agree that the risk is not really significant. Maybe if we just emphasize in the red warning on JS pages that anybody else can see the code? That should be enough IMO.

I agree, the code does not need to be hidden. If users are assuming it is private, we should fix that instead.

It has always been clear that the content of user pages or subpages were publicly visible, including their custom javascript, which is essential for many Wikimedian users.

They also share these scripts (users can choose themselves whever or not to include them or copy them for their own user page, and even the same user may want to load the custom javascript from other wikis, possibly with several identities, i.e. multiple user accounts such as the normal user, a bot user, a WMF user, a special identity for specific tasks or roles).

So this is really not a serious issue. (Adding a warning banner at top of the javascript page, saying that this code is publicly visible, may be userful).

But if users really want to have private javascript, may be a special tag in the user javascript subpage may inform MediaWiki that its content will not be publicly visible

In my opinion it would be simpler to have this private javascript stored using a name within a standard subpage like "User:XXXX/private/custom.js", because it will not require processing the content of the subpage, but only its name! Or otherwise use a special namespace prefix such as "User private:XXX/custom.js" (this special namespace will not be a subject namespace, it will not have any associated talk page, or its associated talk page displayed by default at top of pages will be the standard user talk page, but I think this is not needed as this link to the user's own talk page is present in the user's navbar displayed at top of all pages).

This is also applicable with custom private CSS that would then be allowed to contain javascript using functions defined in the custom private javascript. In other words, load first the private javascript before the public javascript, and load the private CSS (which can include javascript properties defined in the private javascript) before the public CSS (which cannot include any javascript properties, but may still "@import CSS" from another wiki using a plain URL; you may also want to restrict this URL, or support a safer wikilink syntax for this public CSS such as "@import [[wikilink]]", which would be expanded to the standard API query URL to load it in "raw" mode with the standard "text/javascript" mediatype).

In T85856#1237331, @Verdy_p wrote:

So this is really not a serious issue. (Adding a warning banner at top of the javascript page, saying that this code is publicly visible, may be userful).

Right, pending a little UX input, I think that will be the final result.

But if users really want to have private javascript, may be a special tag in the user javascript subpage may inform MediaWiki that its content will not be publicly visible

I don't believe this is requested, and would add a layer of complexity to MediaWiki that I would very much oppose.

Indeed. In the current form MediaWiki does not currently officially support content security at the page level. Only at the level of an entire wiki. There are too many ways revision'ed content can be exposed.

The only feasible option would be to use the user preferences system, in which case there is no versioning. However if a user wants private customisations, there are browser extensions available that will allow them to never even have to submit it in the first place.

Your remarkj about user preferences is pertinent, because it requires a server-side store.
However in Wikimedia, we have lots of wikis and SUL that complicates things a lot.

If we want to support a real single-signon system, those multiple server-side stores will have to be converted into a single store for the whole farm of wikis working with the same user authentication and their associated preferences. But this is not the case (and we also have different user rights per wiki, independantly of the single user identity : all happens in fact if a single user authentication is used in fact to manage a group of identities (that users don't really manage themselves as they are created automatically and msot often the user does not know when this happens).

This has consequences ! users suddently start receiving emails even if they have initially create their account to forbid it on thei initial wiki (and there's not even any global setting to set a global restriction against this, except on specific wikis where this has been allowed).

The situtation is even more complex because the signon process occurs in fact in a different server which is not really a wiki (the loginwiki), but they now have another default user page which is not the same: Metawiki ! Multiple stores on distinct servers for the same default identity...

Potentially this opens various security holes because it is possible to bypass a restriction just by selecting another wiki to perform the same action in order to target a user. This has to be rethought. We need a manageable central store for global authentification and global preferences, on an common central wiki, fully internationalized: Wikipedia editions are not suitable Commons is too much specialized, MetaWiki is OK and the LoginWiki should be deprecated and moved to MetaWiki... But MetaWiki has its own local restrictions too.

So effectively people don't really know where their preferences are mamanged, and they always need to check their preferences on each wiki (but there are hundreds wikis... this is impossible to do in practice, and in fact difficult becuase user preferences on many wikis are unreadable: users have to first guess where is the correct link to it, only to be able to select their UI language preference first and then check these preferences, and don't assume that even if that wiki displays some help in English this will be enough, not everyone can read the alternate English if they cannot read the default language of that wiki!). The problem being that there's still NO global preference for the user's language (the first barrier to remove before cleaning up the way to allow them manage preferences without having to visit hundreds of wikis)

Finally, the user preferences (that have no history) would be useful to store personal data (including personal scripts of stylesheets) in a dedicated special namespace (working across all wikis).

This global user space should also have contained the global "user page", except that it is made to be exposed publicly on all wikis... and versioned: so it cannot be the same namespace and has to be on a separate repository, and MetaWiki is OK for storing it (and sharing it publicly across all other wikis). But there's still no simple way for a user to remove a local version of his user page by the global user configured in MetaWiki (and to forbid it to be recreated locally by someone else to hide the global page configured on MetaWiki).

@Verdy_p, you should add your comments about global preferences to the existing tickets about it.

For the purposes of this ticket, we will add a warning for users (as the title says). If there is demand for private scripts, that should be tracked as a separate task.

Change 298188 had a related patch set uploaded (by Brian Wolff):
Tell users that js/css subpages are public

https://gerrit.wikimedia.org/r/298188

So I'm just going to make a public patch for this, since not really an exploitable issue.

https://gerrit.wikimedia.org/r/298188

Change 298188 merged by Dpatrick:
Tell users that js/css subpages are public

https://gerrit.wikimedia.org/r/298188