Last modified: 2010-09-24 22:13:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 25281 - Privacy issue: ResourceLoader lets you request other user's preferences
Privacy issue: ResourceLoader lets you request other user's preferences
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal major (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-24 02:10 UTC by P.Copp
Modified: 2010-09-24 22:13 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description P.Copp 2010-09-24 02:10:11 UTC
With load.php?modules=user.options&user=OtherUser you can easily retrieve someone else's preferences including the watchlist token.

Needs a check against $wgUser I think.
Comment 1 Trevor Parscal 2010-09-24 03:47:03 UTC
Well, the point is actually to make this resource cachable at the squid level.

I'm not doubting that it could be, but perhaps someone could help me to understand how is this type of information being available a problem.
Comment 2 MZMcBride 2010-09-24 03:59:52 UTC
(In reply to comment #1)
> I'm not doubting that it could be, but perhaps someone could help me to
> understand how is this type of information being available a problem.

I don't know the extent to which user preferences are available, but I would say that the most (and probably only) problematic user preference is user e-mail address. In addition to privacy and expectation of privacy concerns, something like this could theoretically be used for e-mail address harvesting or revealing that multiple accounts belong to the same individual.
Comment 3 P.Copp 2010-09-24 04:05:14 UTC
The personal settings of a user are usually considered to be private. I don't know if it's worth arguing about whether it's a problem or not that e.g. your personal watchlist is made publicly available.

I'd guess there's a reason that the API blocks these kind of requests, rsp. requires a special token from the user.
Comment 4 Andrew Garrett 2010-09-24 04:10:44 UTC
User preferences are not intended to be public. The most obvious problem is the watchlist token.

(In reply to comment #2)
> (In reply to comment #1)
> > I'm not doubting that it could be, but perhaps someone could help me to
> > understand how is this type of information being available a problem.
> 
> I don't know the extent to which user preferences are available, but I would
> say that the most (and probably only) problematic user preference is user
> e-mail address. In addition to privacy and expectation of privacy concerns,
> something like this could theoretically be used for e-mail address harvesting
> or revealing that multiple accounts belong to the same individual.

This wouldn't be revealed.
Comment 5 Trevor Parscal 2010-09-24 05:53:39 UTC
The watchlist thing sounds important, and the general idea of exposing something that's been considered private before seem like great reasons to change course here.

Are there any objections to including the user.options module as an inline script? Logged in users would naturally get their own versions while anons would get the defaults. This would solve the issue without having to give up the functionality.
Comment 6 Andrew Garrett 2010-09-24 06:10:15 UTC
The other possibility is using a user-specific token in the URL, or using something else and not caching in squid.
Comment 7 Niklas Laxström 2010-09-24 07:45:07 UTC
Why are all user preferences outputted unconditionally?
Comment 8 Trevor Parscal 2010-09-24 07:50:12 UTC
Access to user preferences on the client has been a want of front-end developers for some time, and has been being done in part for a while by in-lining them. However, it is completely reasonable to make a white/black list for these things, rather than just output them, as you say, unconditionally.

Assuming we never send the preferences of one user to another, the only advantage I can see to conditionally exporting user options to the client is a reduction of the size of the data being added to the page - which I am a fan of.
Comment 9 Roan Kattouw 2010-09-24 14:07:36 UTC
I think user preferences should not be loaded through the resource loader at all, but just inlined like mediaWiki.config.set() is. I'll poke at this.
Comment 10 Trevor Parscal 2010-09-24 17:15:19 UTC
I spoke with Tim about this approach last night. It seems to add about 1-2k of data to the page, but it uses fewer requests. He recommended we make it configurable so that it will either embed in the page or be available as a request (but will check against $wgUser) so that we can do some performance analysis between them and also so 3rd party users can choose different settings that make sense for us/them.
Comment 11 Trevor Parscal 2010-09-24 22:13:28 UTC
This has been solved in r73686, which supports both embedding the user options into the page using an inline script, or accessing them through ResourceLoader, in which case server caching is bypassed. In both cases the user parameter in the resource request is checked against $wgUser, and default user options are used in case of mismatch.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links