[Labs-l] Labs privacy policy questions

Magog The Ogre magog.the.ogre at gmail.com
Tue Mar 8 14:07:19 UTC 2016


I'm sorry, I meant to say I do not log the password data (if you reread my
sentence, you'll see it makes no sense otherwise)

PHP automatically logs function arguments in stack traces, so the
programmer must take care to avoid this scenario. But that's the problem;
it's easy to have an oversight.

And that's just one way the data could get logged. There are also server
POST logs, PHP/Java core dumps, etc.

The point being, if we deal with passwords anywhere, we should take the
utmost precaution to avoid passwords leakage, but we might miss something.

Magog
On Mar 8, 2016 8:51 AM, "Maximilian Doerr" <maximilian.doerr at gmail.com>
wrote:

> Actually that makes me more concerned.  If you’re going out of your way to
> log people’s passwords, even if they are non-WMF passwords for WMF users,
> that should be disclosed in big red font.
>
>
>
> Also session handling should be separated from stack traces.  There’s no
> reason for a stack trace to print session data.
>
>
>
> I’ve never ever had an unexpected exception resulting in session data
> being printed into a stack trace.
>
>
>
> Peachy for example, dumps a record of its communications it does to a log
> file, but I made sure that private data is not spilled there.
>
>
>
> Cyberpower678
>
> English Wikipedia Account Creation Team
>
> Mailing List Moderator
>
> Global User Renamer
>
>
>
> *From:* Labs-l [mailto:labs-l-bounces at lists.wikimedia.org] *On Behalf Of *Magog
> The Ogre
> *Sent:* Tuesday, March 08, 2016 7:49 AM
> *To:* Wikimedia Labs <labs-l at lists.wikimedia.org>
> *Subject:* Re: [Labs-l] Labs privacy policy questions
>
>
>
> And just to clarify, I go out of my way log the password, and I'm sure
> Magnus doesn't either. But any information that is stored in session can
> accidentally leak into logs by one means or another (stack traces that
> aren't handled carefully, PHP dumps, etc.)
>
>
>
> I hope this answers everyone's concerns.
>
>
>
> Magog
>
>
>
> On Tue, Mar 8, 2016 at 7:23 AM, Magog The Ogre <magog.the.ogre at gmail.com>
> wrote:
>
> May I remind everyone about TUSC (http://tools.wmflabs.org/tusc/)? This
> is a tool used for authentication built around a username-password. Tools
> by nature must have a copy of the password before passing it to TUSC. While
> users are encouraged not to use their Commons passwords, the tool cannot
> enforce it.
>
>
>
> The tool is deprecated in favor of OAuth. I have personally been trying to
> get off the ground with OAuth for a while now (see my email from this
> weekend). I am not sure but if there are any tools left other than my own
> which still use TUSC.
>
>
>
> Magog
>
>
>
>
>
> On Tue, Mar 8, 2016 at 7:13 AM, Maximilian Doerr <
> maximilian.doerr at gmail.com> wrote:
>
> I must also say that I am deeply uncomfortable with the
> username/password.  No tool labs tool or project has any business
> collecting usernames and passwords unless it's a local tool login
> completely separate login from WMF wikis.  If I am interpreting this
> incorrectly, I apologize.
>
>
>
> That also goes without saying the collecting Access tokens of OAuth users
> is completely unacceptable too.
>
> Cyberpower678
>
> English Wikipedia Account Creation Team
>
> ACC Mailing List Moderator
>
> Global User Renamer
>
>
> On Mar 8, 2016, at 04:57, Merlijn van Deen (valhallasw) <
> valhallasw at arctus.nl> wrote:
>
> Hi Pine,
>
>
>
> On 8 March 2016 at 09:11, Pine W <wiki.pine at gmail.com> wrote:
>
> Does "username/password combination for accounts created in Labs services"
> refer to service-specific Labs passwords rather than Wikimedia login
> credentials?
>
> Yes. It refers to e.g. the username/password combination you use on
> https://phab-01.wmflabs.org/ or http://en.wikipedia.beta.wmflabs.org.
> Wikimetrics uses OAuth, so it will not get to know your credentials.
>
>
>
> I'm deeply uncomfortable with the idea that someone who logs into a Labs
> account could have their IP made public, and it also seems to me that any
> Labs tool owners who capture the IPs of tool users should be required to
> pass a similar level of scrutiny as is applied to Checkusers. Is this
> something that I should bring up with James Alexander and/or Michelle
> Paulson?
>
>
>
> > someone who logs into a Labs account could have their IP made public
>
> Wikitech itself falls within the WMF Privacy Policy, so creating a Labs
> account (and logging in to Wikitech) will not share your IP with any
> projects.
>
>
>
> Using web tools hosted on Labs could, however, and realistically there
> not much we can do about it. For example, in the case of Tool Labs, we do
> not pass the IP address of the user to the tool, but a malicious tool could
> load an external resource and track users using that external resource.
> This means we would need to require checkuser-level scrutiny for *every* labs
> user, which would just mean people will host their tools off labs. The
> requirement to show a warning when private information is logged (cf.
> https://wikitech.wikimedia.org/wiki/Wikitech:Labs_Terms_of_use#What_information_should_I_provide_to_users.3F
> ) is a compromise.
>
>
>
> In practice, Labs projects should be considered the same as any external
> resource: they might store private information. We just require labs
> project to be clear about this in advance.
>
>
>
> Merlijn
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
>
>
>
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/labs-l/attachments/20160308/6ca4278e/attachment-0001.html>


More information about the Labs-l mailing list