⚓ T265726 Assign oathauth-verify-user to bureaucrats on WMF wikis
Page Menu
Phabricator
Create Task
Maniphest
T265726
Assign oathauth-verify-user to bureaucrats on WMF wikis
Closed, Resolved
Public
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
EggRoll97
Authored By
Xaosflux
Oct 16 2020, 1:56 PM
2020-10-16 13:56:57 (UTC+0)
Tags
Wikimedia-Site-requests
(Analysis / under discussion)
WMF-Legal
(Backlog)
Privacy Engineering
(Completed)
SecTeam-Processed
(Completed)
User-notice-archive
(Backlog)
Referenced Files
None
Subscribers
A_smart_kitten
Aklapper
alaa
Ameisenigel
Base
Bawolff
CptViraj
View All 33 Subscribers
Description
Bureaucrats on WMF wiki's are given the ability to issue interface administrator access to other users, and WMF has required that holders of this group have 2FA enabled. This access will allow these groups to ensure that the foundation requirements are met before performing that action.
This tool was created in
T209749
, see similar permission rollout in
T251447
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Assign oathauth-verify-user to default bureaucrat
operations/mediawiki-config
master
+1
-0
InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
operations/mediawiki-config
master
+1
-0
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Restricted Task
Open
None
T150898
Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis
Resolved
EggRoll97
T265726
Assign oathauth-verify-user to bureaucrats on WMF wikis
Declined
None
T282624
Limit IA granting/revoking to stewards only
Mentioned In
T401350: Bureaucrats should be able to access Special:Log/oath
T398518: verifyoathforuser-text and verifyoathforuser-summary on Special:VerifyOATHForUser are empty
T398107: Enable abusefilter-revert on testwiki
T282624: Limit IA granting/revoking to stewards only
Mentioned Here
T398107: Enable abusefilter-revert on testwiki
T282624: Limit IA granting/revoking to stewards only
T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis
T209749: Allow privileged accounts to determine if an account has enrolled in 2FA
T251447: Assign oathauth-verify-user to stewards at metawiki
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
Tgr
subscribed.
Oct 17 2020, 8:50 PM
2020-10-17 20:50:25 (UTC+0)
Comment Actions
2FA logins are global, so this would mean someone taking over an xywiki bureaucrat account could check which valuable accounts on large wikis are easy targets. Once
T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis
gets enforced, that might be an acceptable risk, as account takeover is not terribly damaging for non-sensitive accounts; for now, I'm not sure it is a good idea.
Xaosflux
added a comment.
Oct 18 2020, 1:14 AM
2020-10-18 01:14:00 (UTC+0)
Comment Actions
@Tgr
- we also allow all those 'crats to issue int-admin to anyone - but they are not supposed to do it unless the accounts have 2FA -- but they aren't able to actually check that so they just give it to anyone that claims they have 2FA, defeating the control (also not allowing audit to see if 2FA has been disabled). I expected this to be a bit borderline due to the way some projects (such as eswiki I mentioned above) give out 'crat to lots of users.
Tgr
added a comment.
Oct 19 2020, 5:11 AM
2020-10-19 05:11:12 (UTC+0)
Comment Actions
I suppose being able to make others into interface admin is already dangerous enough that 2FA checks do not add much risk; but the former has a public audit trail which makes abusing it much more difficult. How are 2FA checks logged?
Urbanecm
added a comment.
Edited
Oct 19 2020, 9:31 AM
2020-10-19 09:31:46 (UTC+0)
Comment Actions
Private log available only to stewards
sbassett
subscribed.
Oct 19 2020, 8:10 PM
2020-10-19 20:10:04 (UTC+0)
taavi
moved this task from
Backlog
to
Analysis / under discussion
on the
Wikimedia-Site-requests
board.
Oct 21 2020, 7:39 AM
2020-10-21 07:39:17 (UTC+0)
taavi
subscribed.
Tks4Fish
subscribed.
Oct 22 2020, 9:40 PM
2020-10-22 21:40:26 (UTC+0)
CptViraj
subscribed.
Nov 2 2020, 5:32 PM
2020-11-02 17:32:11 (UTC+0)
Urbanecm
triaged this task as
Lowest
priority.
Dec 15 2020, 10:55 AM
2020-12-15 10:55:44 (UTC+0)
Base
subscribed.
Feb 15 2021, 12:48 PM
2021-02-15 12:48:36 (UTC+0)
Zabe
subscribed.
Feb 27 2021, 6:19 PM
2021-02-27 18:19:48 (UTC+0)
MF-Warburg
subscribed.
Apr 28 2021, 9:21 AM
2021-04-28 09:21:58 (UTC+0)
FriedrickMILBarbarossa
added a project:
MediaWiki-extensions-OATHAuth
Apr 29 2021, 11:10 AM
2021-04-29 11:10:53 (UTC+0)
FriedrickMILBarbarossa
subscribed.
Apr 29 2021, 11:19 AM
2021-04-29 11:19:03 (UTC+0)
DannyS712
removed a project:
MediaWiki-extensions-OATHAuth
Apr 29 2021, 5:43 PM
2021-04-29 17:43:53 (UTC+0)
Comment Actions
(this is a configuration change, not a change to the extension itself)
Xaosflux
mentioned this in
T282624: Limit IA granting/revoking to stewards only
May 12 2021, 12:59 AM
2021-05-12 00:59:38 (UTC+0)
Xaosflux
added a comment.
Edited
May 12 2021, 1:07 AM
2021-05-12 01:07:35 (UTC+0)
Comment Actions
Assuming
T282624
completes, this will become invalid.
FriedrickMILBarbarossa
awarded a token.
May 14 2021, 3:54 AM
2021-05-14 03:54:37 (UTC+0)
SpartacksCompatriot
subscribed.
May 16 2021, 3:14 PM
2021-05-16 15:14:40 (UTC+0)
Aklapper
added a subtask:
T282624: Limit IA granting/revoking to stewards only
Jul 21 2021, 8:49 AM
2021-07-21 08:49:27 (UTC+0)
Stang
subscribed.
Jan 11 2022, 10:00 PM
2022-01-11 22:00:31 (UTC+0)
gerritbot
added a comment.
Sep 26 2022, 7:06 PM
2022-09-26 19:06:25 (UTC+0)
Comment Actions
Change 835252 had a related patch set uploaded (by Samtar; author: Samtar):
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
gerritbot
added a project:
Patch-For-Review
Sep 26 2022, 7:06 PM
2022-09-26 19:06:26 (UTC+0)
TheresNoTime
subscribed.
Sep 26 2022, 7:06 PM
2022-09-26 19:06:45 (UTC+0)
GeneralNotability
subscribed.
Sep 26 2022, 7:12 PM
2022-09-26 19:12:57 (UTC+0)
Lomrjyo
subscribed.
Sep 26 2022, 9:58 PM
2022-09-26 21:58:52 (UTC+0)
gerritbot
added a comment.
Sep 28 2022, 8:26 PM
2022-09-28 20:26:05 (UTC+0)
Comment Actions
Change 835252
abandoned
by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Reason:
Legal: NDA issue, see task
Urbanecm
closed this task as
Declined
Sep 28 2022, 8:26 PM
2022-09-28 20:26:33 (UTC+0)
Comment Actions
In
T265726#6550102
@Urbanecm
wrote:
This needs approval by WMF legal.
In
T265726#6550135
@Urbanecm
wrote:
I have emailed them.
WMF Legal got back to me. They said that "account's 2FA status would constitute non-public personal information". This means that this level of access cannot be granted to bureaucrats, as they aren't necessarily under an NDA. Setting the status to Declined.
Maintenance_bot
removed a project:
Patch-For-Review
Sep 28 2022, 8:32 PM
2022-09-28 20:32:27 (UTC+0)
Xaosflux
added a comment.
Edited
Sep 28 2022, 8:56 PM
2022-09-28 20:56:52 (UTC+0)
Comment Actions
Thanks for the note; so seems like this could be done to a group that already requires NDA - such as oversighters or checkusers, correct?
Of course the initial problem of: bureaucrats assign access that requires 2FA, but aren't able to validate 2FA isn't directly solved even with that. (Unless only Crats that are also CU/OS were doing this)
GeneralNotability
added a comment.
Edited
Sep 28 2022, 9:09 PM
2022-09-28 21:09:41 (UTC+0)
Comment Actions
The ruling that 2FA status is "non-public personal information" doesn't make sense to me. How is it any more non-public than than "has an email address set"? For reference, the email address status is exposed to anyone with an account and verified email address via Special:EmailUser (attempting to email a user without an email set will get the error
This user has not specified a valid email address.
). Further, the 2FA group requests take place on a public noticeboard (
), a steward confirms that they have added the oauth-tester group, and the group membership is public. As possible attack vectors go, one can have a fairly good chance at identifying 2fa users by membership in said group or lack thereof. Or if someone requests intadmin but doesn't have 2FA set...the stewards will most likely say something to the effect of "sorry, we can't grant this until you turn on 2FA," won't they? Or will they have to give vague decline reasons if someone refuses to enable it?
Tks4Fish
added a comment.
Sep 28 2022, 11:04 PM
2022-09-28 23:04:59 (UTC+0)
Comment Actions
@GeneralNotability
: if NDA is not required, that means we would be able to make a list of people that do and don't have 2FA enabled and release it freely, increasing the attack probability for those users. OTOH, group membership doesn't mean 100% that the user has 2FA enabled, and even if the user has IA somewhere, it's not guaranteed that they do have it enabled, even though it's required. The way it currently is seems the safest to me, only a few privileged users (obligatory disclaimer: of which I'm part of) have access to that, and it is logged so that any other steward or WMF staff can verify what they're doing. Furthermore, the difference between emails and 2FA is (among other things) that 2FA enrollment is only queryable by stewards/staff/sysadmins, all of which have mandatory NDAs.
GeneralNotability
added a comment.
Edited
Sep 28 2022, 11:55 PM
2022-09-28 23:55:13 (UTC+0)
Comment Actions
You're arguing that this information is security-relevant. That is not the same thing as "non-public personal information". I'm absolutely being an armchair lawyer here, but
the privacy policy
is pretty clear that it applies to information which could be used to identify you. There is no PII contained in the one-bit "2FA enabled" / "2FA disabled" setting, and that's a significant part of my objection.
And yes, a malicious actor could release the 2FA list, and yes, that could be used to identify easier users to attack. It indicates more vulnerable users, but does not itself constitute an attack vector. I argue that that is a very low-probability risk, given that (as far as I know) all 'crats will have already met the community-review standards for adminship. These are people who, by and large, aren't dumping deleted articles onto the Internet or leaking abuse filters. Also, a steward could release that information just as easily as a local 'crat, and before Legal's response today that wouldn't have even been a clear-cut reason to revoke said steward's NDA. And - once again - what happens if a steward has to say "sorry, we can't grant you IA because you don't have 2FA enabled" or "we will not grant this user IA because they have refused to meet the security standards"? According to the above, that's an NDA breach, but that's kind of ridiculous.
Furthermore, the difference between emails and 2FA is (among other things) that 2FA enrollment is only queryable by stewards/staff/sysadmins, all of which have mandatory NDAs.
That's rather circular, isn't it? The fact that something is currently only accessible to people who have signed the NDA does not inherently mean that that thing is NDA-protected.
SCP-2000
subscribed.
Sep 29 2022, 2:46 AM
2022-09-29 02:46:48 (UTC+0)
SCP-2000
added a comment.
Sep 29 2022, 2:57 AM
2022-09-29 02:57:07 (UTC+0)
Comment Actions
Note: According to
Data retention guidelines
, account settings belong to Non Public Personal information. Thanks.
Vermont
subscribed.
Sep 29 2022, 7:28 PM
2022-09-29 19:28:53 (UTC+0)
GeneralNotability
added a comment.
Sep 29 2022, 11:46 PM
2022-09-29 23:46:40 (UTC+0)
Comment Actions
Huh. I had not seen that particular document, would have been nice if it had been mentioned in the privacy policy. Thanks
@SCP-2000
Stang
unsubscribed.
Oct 3 2022, 11:33 PM
2022-10-03 23:33:04 (UTC+0)
Jrogers-WMF
subscribed.
Oct 12 2022, 6:50 PM
2022-10-12 18:50:41 (UTC+0)
Comment Actions
Hi folks, just want to add a note from WMF Legal since we're looking at this. We do think as Urbanecm relayed, that this info is personal data, and the discussion here already is correct in how to think about it. On GeneralNotability's point, we are planning to take a review over the privacy policy in the next couple years ("couple" used loosely here, we don't have a firm date yet) and can take this point into account as we update. I think what counts as personal info in various laws around the world has updated quite a bit in the last few years. Also as a general note, I at least am of the opinion that 2FA is good and helpful overall, even with problems it can cause. So if various legal and policy issues do cause significant disruption to the ability of folks to set it up, please let us know and we'll focus on finding ways to improve the situation.
Xaosflux
added a comment.
Oct 17 2022, 7:59 PM
2022-10-17 19:59:06 (UTC+0)
Comment Actions
@Jrogers-WMF
what spawned this is that WMF wants certain accounts to have 2FA enabled (e.g. interface admins); however the groups that give this out (e.g. bureaucrats) can't check if this is in place, or ensure it is left enrolled. Is the only block from WMF that this check tool should only be available to users that have enrolled in the NDA process, if so perhaps a different existing group (e.g. checkusers) could be leveraged?
HitomiAkane
unsubscribed.
Oct 17 2022, 8:03 PM
2022-10-17 20:03:03 (UTC+0)
sbassett
added a comment.
Oct 17 2022, 8:48 PM
2022-10-17 20:48:38 (UTC+0)
Comment Actions
In
T265726#8322821
@Xaosflux
wrote:
@Jrogers-WMF
what spawned this is that WMF wants certain accounts to have 2FA enabled (e.g. interface admins); however the groups that give this out (e.g. bureaucrats) can't check if this is in place, or ensure it is left enrolled. Is the only block from WMF that this check tool should only be available to users that have enrolled in the NDA process, if so perhaps a different existing group (e.g. checkusers) could be leveraged?
This might work as a solution to this problem, since CUs (or even OSes) should already be covered by appropriate NDAs or similar agreements. If they could support those additional workloads, of course. But there is a secondary issue (as discussed a bit above) about the 2fa status of users being considered non-public data which would substantially hinder certain on-wiki processes, such as confirming 2fa status with various users, which happens publicly in many cases right now, AIUI.
gerritbot
added a comment.
Dec 7 2022, 7:13 PM
2022-12-07 19:13:21 (UTC+0)
Comment Actions
Change 835252
restored
by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
gerritbot
added a project:
Patch-For-Review
Dec 7 2022, 7:13 PM
2022-12-07 19:13:22 (UTC+0)
Xeno_WMF
subscribed.
Dec 7 2022, 7:56 PM
2022-12-07 19:56:38 (UTC+0)
DannyS712
closed subtask
T282624: Limit IA granting/revoking to stewards only
as
Declined
Jan 12 2024, 12:41 AM
2024-01-12 00:41:18 (UTC+0)
Johannnes89
subscribed.
Jan 12 2024, 10:11 AM
2024-01-12 10:11:27 (UTC+0)
gerritbot
added a comment.
Jan 18 2024, 5:53 AM
2024-01-18 05:53:12 (UTC+0)
Comment Actions
Change 835252
abandoned
by Samtar:
[operations/mediawiki-config@master] InitialiseSettings.php: Add oathauth-verify-user to default bureaucrat
Reason:
Ammarpad
removed a project:
Patch-For-Review
Jan 18 2024, 9:08 AM
2024-01-18 09:08:48 (UTC+0)
Novem_Linguae
subscribed.
Apr 25 2024, 9:01 AM
2024-04-25 09:01:19 (UTC+0)
MGChecker
subscribed.
May 25 2024, 11:00 AM
2024-05-25 11:00:27 (UTC+0)
Ameisenigel
subscribed.
Sep 24 2024, 9:09 AM
2024-09-24 09:09:38 (UTC+0)
Comment Actions
Could we re-open this Task? According to
the legal issue should be resolved.
Xaosflux
added a comment.
Sep 24 2024, 9:13 AM
2024-09-24 09:13:21 (UTC+0)
Comment Actions
In
T265726#10170351
@Ameisenigel
wrote:
Could we re-open this Task? According to
the legal issue should be resolved.
@Urbanecm
your decline reason appears to have been overcome?
Urbanecm
reopened this task as
Open
Sep 24 2024, 9:23 AM
2024-09-24 09:23:33 (UTC+0)
Comment Actions
Yep. I don't quite agree with this, but Legal signed this off, and that was the sole reason for the
Declined
status.
sbassett
added a project:
Privacy Engineering
Sep 24 2024, 2:06 PM
2024-09-24 14:06:39 (UTC+0)
Comment Actions
Tagging
Privacy Engineering
to get this in their queue as they have direct interactions with
WMF-Legal
(which isn't really active on Phabricator at all AIUI).
Nemoralis
subscribed.
Oct 22 2024, 8:58 PM
2024-10-22 20:58:26 (UTC+0)
A_smart_kitten
subscribed.
Nov 22 2024, 9:26 PM
2024-11-22 21:26:57 (UTC+0)
Sdrqaz
subscribed.
Jan 4 2025, 2:18 AM
2025-01-04 02:18:31 (UTC+0)
Bawolff
subscribed.
Jan 5 2025, 9:50 PM
2025-01-05 21:50:03 (UTC+0)
Comment Actions
As an aside, perhaps a better solution would be to simply reject adding the group in [[Special:UserRights]] if the user does not have 2FA and 2FA is required for the group (Ideally only check during submit to prevent enumeration). Or perhaps force the user to enable 2FA during their next login.
Of course those solutions don't exist yet, and this one does.
Tgr
added a parent task:
T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis
Mar 29 2025, 3:37 PM
2025-03-29 15:37:36 (UTC+0)
EggRoll97
claimed this task.
Jun 21 2025, 1:44 AM
2025-06-21 01:44:04 (UTC+0)
gerritbot
added a comment.
Jun 21 2025, 1:55 AM
2025-06-21 01:55:01 (UTC+0)
Comment Actions
Change #1162158 had a related patch set uploaded (by EggRoll97; author: EggRoll97):
[operations/mediawiki-config@master] Assign oathauth-verify-user to default bureaucrat
gerritbot
added a project:
Patch-For-Review
Jun 21 2025, 1:55 AM
2025-06-21 01:55:02 (UTC+0)
EggRoll97
changed the task status from
Open
to
Stalled
Jun 23 2025, 8:05 PM
2025-06-23 20:05:50 (UTC+0)
Comment Actions
Stalled on re-confirmation from Legal of the ANPDP exception.
Stang
subscribed.
Jun 24 2025, 12:18 AM
2025-06-24 00:18:55 (UTC+0)
EggRoll97
changed the task status from
Stalled
to
In Progress
Edited
Jun 28 2025, 4:37 PM
2025-06-28 16:37:22 (UTC+0)
Comment Actions
Legal confirmed per Gerrit comment, now waiting on deployment. I plan to get this deployed this week.
Nemoralis
added a project:
User-notice
Jun 29 2025, 12:14 PM
2025-06-29 12:14:27 (UTC+0)
gerritbot
added a comment.
Jul 2 2025, 1:05 PM
2025-07-02 13:05:22 (UTC+0)
Comment Actions
Change #1162158
merged
by jenkins-bot:
[operations/mediawiki-config@master] Assign oathauth-verify-user to default bureaucrat
Stashbot
mentioned this in
T398107: Enable abusefilter-revert on testwiki
Jul 2 2025, 1:05 PM
2025-07-02 13:05:49 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2025-07-02T13:05:48Z]
T265726
)]], [[gerrit:1164637|Add abusefilter-revert to sysops on testwiki (
T398107
)]]
Stashbot
added a comment.
Jul 2 2025, 1:08 PM
2025-07-02 13:08:09 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2025-07-02T13:08:05Z]
T265726
)]], [[gerrit:1164637|Add abusefilter-revert to sysops on testwiki (
T398107
)]] synced to the testservers (see
). Changes can now be verified there.
Stashbot
added a comment.
Jul 2 2025, 1:17 PM
2025-07-02 13:17:11 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2025-07-02T13:17:05Z]
T265726
)]], [[gerrit:1164637|Add abusefilter-revert to sysops on testwiki (
T398107
)]] (duration: 11m 16s)
EggRoll97
closed this task as
Resolved
Jul 2 2025, 1:18 PM
2025-07-02 13:18:16 (UTC+0)
Comment Actions
Should be on all production wikis assigned to bureaucrats.
sbassett
moved this task from
Incoming
to
Completed
on the
Privacy Engineering
board.
Jul 2 2025, 1:50 PM
2025-07-02 13:50:48 (UTC+0)
sbassett
edited projects, added
SecTeam-Processed
; removed
Patch-For-Review
Nemoralis
mentioned this in
T398518: verifyoathforuser-text and verifyoathforuser-summary on Special:VerifyOATHForUser are empty
Jul 2 2025, 9:56 PM
2025-07-02 21:56:25 (UTC+0)
Trizek-WMF
moved this task from
To Triage
to
In current Tech/News draft
on the
User-notice
board.
Jul 3 2025, 3:35 PM
2025-07-03 15:35:46 (UTC+0)
Pikne
subscribed.
Jul 6 2025, 7:23 AM
2025-07-06 07:23:58 (UTC+0)
Comment Actions
This makes me wonder. Since March the foundation requirement is enforced by other means, it is no longer technically possible to use IA rights without having 2FA enabled (
T150898#10689383
). So didn't the motivation to grant given right to bureaucrats drop off with this?
Johannnes89
added a comment.
Jul 6 2025, 9:38 AM
2025-07-06 09:38:05 (UTC+0)
Comment Actions
In
T265726#10976868
@Pikne
wrote:
This makes me wonder. Since March the foundation requirement is enforced by other means, it is no longer technically possible to use IA rights without having 2FA enabled (
T150898#10689383
). So didn't the motivation to grant given right to bureaucrats drop off with this?
All accounts with IA permissions should be secured by 2FA all the time. The new "enforcement" motivates users to turn on 2FA, but doesn't guarantee it because users can still use their account without 2FA (just not their IA permissions). Bad actors could therefore target IA accounts without 2FA and just turn on 2FA themselves after gaining access in order to abuse the permissions. That's why bureaucrats being able to verify 2FA is still an important step to make sure more IA accounts are secured.
UOzurumba
moved this task from
In current Tech/News draft
to
Already announced/Archive
on the
User-notice
board.
Jul 9 2025, 6:56 PM
2025-07-09 18:56:08 (UTC+0)
Maintenance_bot
edited projects, added
User-notice-archive
; removed
User-notice
Jul 19 2025, 7:30 PM
2025-07-19 19:30:41 (UTC+0)
Ameisenigel
mentioned this in
T401350: Bureaucrats should be able to access Special:Log/oath
Aug 6 2025, 7:30 PM
2025-08-06 19:30:40 (UTC+0)
Stang
unsubscribed.
Oct 14 2025, 1:29 PM
2025-10-14 13:29:05 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits
US