Page MenuHomePhabricator

Use a parser function to encapsulate signatures
Open, Needs TriagePublic

Description

In order to more reliably identify signatures on talk pages, it would be best to encapsulate them. This would also allow us to implement a oft-requested user feature: automatically updating signatures on old talk pages.

The proposal is simply to change the pre-save-transform (PST), which currently maps ~~~~ to $nickname $date to:

{{#~:$username|$date}}
{{#~:$username|$date|$nickname}}

There would be a new option in the user preferences, "Always use latest signature", which is true by default. If it is true, the first form of {{#~}} is used, which dynamically fetches the latest signature for display. Some users like the way things currently work, however, where you can archive old versions of your signature. The second form would be used in that case, which inserts the current signature as the optional third argument.

By naming the parser function '~' we don't have to localize it.

For performance, changes to a user's signature preference by default do *NOT* invalidate pages on which their signature appears. So old signatures may persist for some time in the page cache. That's okay.

Note that this change also mitigates issues like T230652: Tilde stripping in signatures is inadequate -- if you manage to emit {{#~:username|date|~~~~}} it may still be confusing to human readers, but the stored wikitext unambiguously records the actual username and timestamp.

The convention is that each wiki specifies a particular timestamp format and timezone via $wgLanguageCode and $wgLocaltimezone. We could use this format for the signature argument so wikitext editors can easily read the timestamp; this format should be able to be unambiguously parsed, although there could be issues with parsing localized month strings if an existing wiki changes $wgLanguageCode. For example, on frwiki, my signature might appear as Cscott (discuter) 17 août 2019 à 22:31 (CEST) -- if the wikilanguage was changed that wouldn't parse.

An alternative would be to switch to human-readable ISO 8601 timestamps -- yyyy-mm-dd hh:mm Z -- for the parser function argument. In either case, display could be customized by the parser function to the user's preferred format and timezone, although obviously that would end up skipping the parser cache.

(Note: T204371 would eventually allow using a vertical bar instead of a colon to separate the first argument, and T204307 would allow using named parameters. Both of these issues are orthogonal to this proposal, however.)

Details

Related Gerrit Patches:

Event Timeline

cscott created this task.Aug 17 2019, 1:27 PM
Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptAug 17 2019, 1:27 PM
cscott updated the task description. (Show Details)Aug 17 2019, 10:02 PM
cscott updated the task description. (Show Details)Aug 18 2019, 1:40 PM

It would also be nice if the parser function output contained this structured data, e.g. <span data-timestamp="YYYYMMDDHHMMSS" data-user="Bob">....</span>

It would also be nice if the parser function output contained this structured data, e.g. <span data-timestamp="YYYYMMDDHHMMSS" data-user="Bob">....</span>

+1!

Anomie added a subscriber: Anomie.Aug 19 2019, 5:18 PM

How will this parser function interact with renames? For example, if "Bob" is renamed to "UserFormerlyKnownAsBob", what happens to all the existing {{#~|Bob|...}} that now refer to an unregistered account?

There would be a new option in the user preferences, "Always use latest signature", which is true by default. If it is true, the first form of {{#~}} is used, which dynamically fetches the latest signature for display.

What would be the performance impact on the page parse of fetching hundreds of users' current signatures?

Note that this change also mitigates issues like T230652: Tilde stripping in signatures is inadequate -- if you manage to emit {{#~|username|date|~~~~}} it may still be confusing to human readers, but the stored wikitext unambiguously records the actual username and timestamp.

Unless this parser function also somehow also magically protects the third parameter from the preprocessor, the subsequent save would turn it into {{#~|username|date|{{#~|username2|date2}}}}. That's still a problem.

We usually leave a redirect page in place for user renames. For example: https://en.wikipedia.org/w/index.php?title=User:Cananian&redirect=no

We'd have to look at performance, probably just a single batch database query.

The last example isn't really a problem. It's still confusing to readers, but it's unambiguous to parse and doesn't fool tools.

I mean, policy on wiki will probably still forbid it (as it does now). But it wouldn't break anything.

We usually leave a redirect page in place for user renames. For example: https://en.wikipedia.org/w/index.php?title=User:Cananian&redirect=no

I'm not sure a redirect would be the best thing to do. What if someone retargets it? What if someone usurps the old name?

The last example isn't really a problem. It's still confusing to readers, but it's unambiguous to parse and doesn't fool tools.
I mean, policy on wiki will probably still forbid it (as it does now). But it wouldn't break anything.

It doesn't break anything now either, but we still have a task about it. I'm just saying that I don't think you could justify claiming T230652 was actually fixed here.

We usually leave a redirect page in place for user renames. For example: https://en.wikipedia.org/w/index.php?title=User:Cananian&redirect=no

I'm not sure a redirect would be the best thing to do. What if someone retargets it? What if someone usurps the old name?

Then you deal with it in the old user page, perhaps by adding an {{usurped}} template at the top which tells readers when the name was usurped. Or revert the edit retargeting the user.

Existing signatures don't update the old user either. We can't always expect silver bullets. You could insert a numeric user id into the template as well, but as long as most people are still reading/writing Wikitext on talk pages, this will be perceived as degrading readability. And if we user the local userid this doesn't necessarily help us obtain an unambiguous SUL userid, since that mapping can change over time as well.

Yes, existing signatures don't update the old user. But they also don't magically change when the usurping user sets a new signature for the account.

After this discussion, I'd probably recommend dropping the "looks up the current signature" magic if you don't want to include the local user ID. Just have {{#~|User|Date}} output the generic signature used when the preference is not set.

And if we user the local userid this doesn't necessarily help us obtain an unambiguous SUL userid, since that mapping can change over time as well.

Why would we want the SUL user ID in there in the first place?

cscott added a comment.EditedAug 22 2019, 5:57 PM

My point is that there are a number of levels of indirection between local username and some stable notion of "real user". Over time the local username can map to a different local userid, and in term the local userid can map to a different SUL userid. I don't think we should try to solve the global identity problem.

It would be not-too-hard to add "last usurped" timestamp to the user record, so when we look up {{~#|User|Date}} we only apply the "most recent signature" magic if Date is newer than last usurped. Otherwise we substitute a generic signature, or even better add an automatic warning that this username was usurped/renamed.

Esanders added a subscriber: Catrope.

Is there any reason you proposed {{#~|user|date}} as opposed to {{#~:user|date}}? The latter would be implementable in an extension without parser modifications, by registering a parser function named ~. I understand the reasoning behind naming the parser function ~ instead of sig or something, so that it doesn't have to be localized, but was the colon-vs-pipe thing deliberate or an oversight?

cscott added a comment.EditedSep 17 2019, 4:41 PM

@Catrope: oops, sorry, I had it in my head that T204371: Replace initial colon in (hash-prefixed) parser function invocation with vertical bar was already implemented, instead of still future work.

For this task, use the colon. Eventually T204371 will land and you'll be able to use vertical bar as well; you might have to set SFH_NAMED_ARGS when you register it (T204307) to enable that... but baby steps. Let's keep those tasks separate.

I've updated the task description to switch back to the colon.

cscott updated the task description. (Show Details)Sep 17 2019, 4:42 PM
cscott updated the task description. (Show Details)

Change 538913 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] [WIP] Experimenting with a signature parser function

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

Alsee added a subscriber: Alsee.Sep 29 2019, 5:16 AM

oft-requested user feature: automatically updating signatures on old talk pages.

While there may have been requests for this, I think it unlikely that the community would actually want this. Changing signatures with no entry in the page history would be strange, confusing, and open to abuse.

  1. Make an apparently innocent edit.
  2. At any time, change signature preference. Purge the page to apply the change. These actions are unlogged and invisible to the community.
  3. The page may now be in a deceptive or malicious state.
  4. At any time, change signature preference. Purge the page to apply the change. These actions are unlogged and invisible to the community.
  5. The page is back in an apparently innocent state. There does not exist any log or other evidence that the user committed the abuse.

The most obvious issue would be to impersonate someone else, however it's more serious than may first be apparent. This exploit enables a clever user to inject arbitrary wikitext&content at several points in the page, with surprisingly powerful possibilities.

That's a very good point, thanks for raising it. One particularly worrisome variant would be if a user who has signed a bunch of comments in a bunch of different places either turns malicious or has their account compromised, and changes their signature preference to something that's so bad that it's oversight-worthy (e.g. doxing, death treats). In that situation, oversighters wouldn't have good tools to get rid of it: you could remove the signatures from existing discussions even without necessarily needing to oversight those edits, but there would be too many places the signature is used to feasibly do this. The proper way to fix this situation is to change the user's signature to something non-terrible, but admins/oversighters don't have the power to change another user's preferences (nobody does).

Spitballing some ideas here that would avoid this issue:

Don't support dynamic signatures (at first?)
The simplest way to avoid issues with dynamic signatures is to not support them. If the user has a custom signature, we'd always embed it in the parser function call, like we currently propose doing when the user has disabled dynamic signatures ({{#:username|timestamp|verbatim custom signature}}). Only if the user does not have a custom signature would we use the abbreviated {{#:username|timestamp}} syntax (such signatures would technically be dynamic, but only with respect to any global changes to the default signature format). One downside of this is that many of the most-used signatures are customized, so the {{#:...}} syntax would make the signature wikitext longer. We would still want the parser function to be there, so that we can output and track metadata about the signature/comment. As @Esanders pointed out to me, we can also start with this at first, then consider one of the other options later (i.e. only allow dynamic signatures once a way to audit their use is in place).

Log changes to signatures
Right now a user's signature is technically private (because it's a preference), but it becomes public as soon as they use it. We could instead make signatures really public, and log changes to them to Special:Log/signature or something. This would provide basic tools to detect abuse, and log entries for "bad" signatures could be oversighted. Then, in order to address cases of abuse...

Disable custom signatures for blocked users
Make it so that if a user is blocked (either with a certain flag, or just for any sitewide block), their custom signature is ignored, and the default signature is used. This would allow cases of abuse that are found to be resolved quickly by anyone who can block users. One downside is that pages would need to be purged in order for the "bad" signature to change back to the default one, and tracking down the pages where this needed would be hard.

Make signatures their own page
This is @Esanders's idea, and I think it's likely better than my log+block ideas above. Each user would have a special page like User:Catrope/signature or Signature:Catrope or something where there signature lives. This page would be publicly visible and would be versioned the same way as any other wiki page, so changes to it show up in RecentChanges, individual edits to it could be oversighted, etc. Unprivileged users would not be able to edit other users' signatures, but a privileged class of users (e.g. admins) would be able to either edit, rollback or delete them to combat abuse. This could be implemented while keeping the current UI as a shell around it: we could continue to let people change their signature and related settings in the preferences form, but instead of changing a "real" preference this would make an edit to their signature page.

Treat (custom) signature invocations as transclusions
Me building forth on Ed's idea above: one problem I mentioned earlier is that finding and purging all the pages where a problematic signature was used is hard. But if we pretend that each (custom) signature is/contains a template transclusion of the user's signature page (which is conceptually pretty accurate anyway), in the sense that we register in the templatelinks table that Wikipedia talk:Picture of the day transcludes User:Catrope/signature, then that would solve that problem. You'd be able to see all uses of my signature by going to Special:Whatlinkshere/User:Catrope/signature, and purges would be done automatically by existing functionality in MediaWiki core that reparses pages that use a template when the template is edited. I was a bit worried that the signatures of prolific users (who are also disproportionately likely to use custom signatures) would essentially become templates that are used in thousands of times, which would mean we'd incur a bunch of tracking overhead (not quite as bad as one templatelinks row per comment, but still one row per commenting user per talk page) and we'd cause a lot of pages to be purged when a signature is edited. But we already cause two pagelinks rows to be added (for the user's user page and their user talk page) per commenting user per page with the current signature model, and the numbers don't seem to be too bad: I've only found a couple of users that have more than 10k links to their user talk pages. I'll get more detailed numbers on this later.

As a proxy for the number of pages a user has their signature on, I looked at the number of pages that link to their user talk page. Here are the top 100 linked-to user talk pages on enwiki:

1[enwiki]> select user_name, count(*) as c from user join pagelinks on pl_title=REPLACE(user_name, ' ', '_') and pl_namespace=3 group by user_name order by c desc limit 100;
2+----------------------------+---------+
3| user_name | c |
4+----------------------------+---------+
5| ClueBot NG | 2017150 |
6| InternetArchiveBot | 914825 |
7| ClueBot | 468609 |
8| Materialscientist | 395292 |
9| XLinkBot | 257842 |
10| HasteurBot | 163684 |
11| MediaWiki message delivery | 160564 |
12| Oshwah | 149026 |
13| HostBot | 147690 |
14| Cyberbot II | 147285 |
15| Gilliam | 128008 |
16| I dream of horses | 127439 |
17| BracketBot | 111583 |
18| Gene93k | 106988 |
19| Widr | 103279 |
20| Jim1138 | 96419 |
21| J.delanoy | 88113 |
22| Shellwood | 82564 |
23| BetacommandBot | 79898 |
24| Alansohn | 77122 |
25| CAPTAIN RAJU | 75088 |
26| Donner60 | 71513 |
27| Alexf | 71409 |
28| DGG | 71055 |
29| DPL bot | 69410 |
30| Mattythewhite | 69115 |
31| Serols | 68303 |
32| Tide rolls | 68140 |
33| Northamerica1000 | 67575 |
34| SwisterTwister | 62855 |
35| NawlinWiki | 62251 |
36| Excirial | 62206 |
37| Drmies | 57379 |
38| JMHamo | 54574 |
39| CorenSearchBot | 53611 |
40| CLCStudent | 52795 |
41| Diannaa | 51376 |
42| JohnCD | 51195 |
43| Pseudomonas | 50257 |
44| SineBot | 49685 |
45| Cirt | 49677 |
46| Gogo Dodo | 47733 |
47| Favonian | 47520 |
48| PseudoBot | 45234 |
49| Ian (Wiki Ed) | 44684 |
50| Binksternet | 43878 |
51| Discospinster | 43540 |
52| ImageTaggingBot | 42464 |
53| C.Fred | 41704 |
54| JamesBWatson | 41634 |
55| KylieTastic | 40783 |
56| Ronhjones | 39652 |
57| Edgar181 | 39471 |
58| Epbr123 | 39349 |
59| Pinethicket | 38225 |
60| Ohnoitsjamie | 38013 |
61| Onel5969 | 37414 |
62| Wikipelli | 36867 |
63| COIBot | 36765 |
64| Acroterion | 36611 |
65| JJMC89 | 36528 |
66| Legacypac | 35705 |
67| ReferenceBot | 35631 |
68| MusikAnimal | 35222 |
69| Sfan00 IMG | 34501 |
70| Orangemike | 33844 |
71| STBotI | 33797 |
72| GiantSnowman | 33602 |
73| Red Director | 33345 |
74| DASHBot | 32944 |
75| Dcirovic | 32655 |
76| Coren | 32553 |
77| Robert McClenon | 32487 |
78| B-bot | 32273 |
79| DVdm | 32266 |
80| CommonsNotificationBot | 32211 |
81| Mark Arsten | 31293 |
82| Wtmitchell | 31144 |
83| BJBot | 31107 |
84| Bongwarrior | 31025 |
85| NeilN | 30903 |
86| MBisanz | 30840 |
87| Eeekster | 30807 |
88| K6ka | 30466 |
89| TenPoundHammer | 29801 |
90| Flyer22 Reborn | 29637 |
91| Biografer | 29416 |
92| Juliancolton | 29123 |
93| Lugia2453 | 28883 |
94| Stefan2 | 28804 |
95| Walter Görlitz | 28239 |
96| Jimfbleak | 28126 |
97| IronGargoyle | 28116 |
98| Chzz | 27974 |
99| Marek69 | 27692 |
100| Community Tech bot | 27521 |
101| Theroadislong | 27432 |
102| Rosiestep | 26618 |
103| Abelmoschus Esculentus | 26356 |
104| Piotrus | 26309 |
105+----------------------------+---------+
106100 rows in set (1 min 30.74 sec)

There are 15 users whose signature appears on >100k pages (and 9 of them are bots), a couple dozen over 50k, about a hundred over 25k, and just under 500 users over 10k. So it looks like having your signature used on 10k pages is decently common, but having more than 50k is uncommon and more than 100k is rare.

On metawiki (which I think of as a discussion-heavy wiki) the numbers are much lower:

1mysql:research@dbstore1003.eqiad.wmnet [metawiki]> select user_name, count(*) as c from user join pagelinks on pl_title=REPLACE(user_name, ' ', '_') and pl_namespace=3 group by user_name order by c desc limit 100;
2+----------------------------+---------+
3| user_name | c |
4+----------------------------+---------+
5| Meta-Wiki Welcome | 8107657 |
6| COIBot | 121256 |
7| Billinghurst | 28355 |
8| Mikhailov Kusserow | 4547 |
9| Tegel | 4195 |
10| I JethroBT (WMF) | 3896 |
11| Liuxinyu970226 | 3510 |
12| Herbythyme | 3392 |
13| Mike.lifeguard | 2550 |
14| MarcoAurelio | 2464 |
15| MediaWiki message delivery | 2238 |
16| PiRSquared17 | 2130 |
17| Trijnstel | 2070 |
18| Spacebirdy | 2065 |
19| Ottava Rima | 1980 |
20| Ajraddatz | 1832 |
21| Sj | 1675 |
22| Dferg | 1606 |
23| Defender | 1605 |
24| Stryn | 1595 |
25| DerHexer | 1535 |
26| Teles | 1526 |
27| Rschen7754 | 1425 |
28| Thogo | 1423 |
29| Thehelpfulone | 1418 |
30| Cbrown1023 | 1355 |
31| NickK | 1341 |
32| Bluerasberry | 1277 |
33| Matiia | 1265 |
34| Abigor | 1261 |
35| Slade | 1246 |
36| Mardetanha | 1242 |
37| Beetstra | 1236 |
38| Pmlineditor | 1231 |
39| Ruslik0 | 1206 |
40| Ruy Pugliesi | 1174 |
41| Glaisher | 1160 |
42| Alexmar983 | 1147 |
43| Snowolf | 1139 |
44| Barras | 1107 |
45| StevenJ81 | 1056 |
46| Savh | 1048 |
47| Peteforsyth | 1032 |
48| Vituzzu | 1013 |
49| Dungodung | 976 |
50| Syum90 | 959 |
51| Mathonius | 927 |
52| Shanmugamp7 | 919 |
53| AWang (WMF) | 914 |
54| Steinsplitter | 857 |
55| Vogone | 855 |
56| Alexanderps | 853 |
57| Cometstyles | 834 |
58| Xaosflux | 830 |
59| Cirt | 811 |
60| WizardOfOz | 804 |
61| Shizhao | 780 |
62| Majorly | 779 |
63| Pine | 779 |
64| Risker | 771 |
65| MER-C | 768 |
66| Mike Peel | 755 |
67| Wolliff | 752 |
68| Another Believer | 749 |
69| Ijon | 749 |
70| Davidpar | 746 |
71| Anonymous Dissident | 745 |
72| Quentinv57 | 732 |
73| Nick1915 | 707 |
74| Cekli829 | 705 |
75| Innv | 703 |
76| Doc James | 699 |
77| Micki | 693 |
78| Fastily | 688 |
79| MBisanz | 683 |
80| Jonathan Balima WMFr | 672 |
81| Mjohnson (WMF) | 656 |
82| Lar | 651 |
83| Pharos | 646 |
84| Samwalton9 (WMF) | 644 |
85| CindyDavidWMFr | 639 |
86| Hoo man | 630 |
87| Matanya | 626 |
88| QuiteUnusual | 622 |
89| Tiptoety | 621 |
90| A. B. | 615 |
91| Juliancolton | 615 |
92| NaBUru38 | 607 |
93| Aphaia | 602 |
94| Slowking4 | 598 |
95| Base | 592 |
96| Jusjih | 591 |
97| John Vandenberg | 581 |
98| RadiX | 579 |
99| WereSpielChequers | 574 |
100| Pbsouthwood | 569 |
101| NahidSultan | 562 |
102| Wittylama | 553 |
103| Varnent | 547 |
104| Yeza | 542 |
105+----------------------------+---------+
106100 rows in set (1 min 5.32 sec)

For good measure I also looked at dewiki (P9234) and frwiki (P9235); dewiki looks roughly similar to metawiki but with slightly higher numbers; frwiki looks roughly similar to enwiki but with slightly lower numbers.

Alsee added a comment.EditedOct 3 2019, 6:52 PM

For raw disruption, I believe someone could put image(s) in their signature. Aside from the obvious image-content issues, the image(s) may be up to 100 megabytes each and/or animated gifs.

For those who are more nefarious, I believe someone could use this exploit to wrap nearly the entire page-contents inside an HTML-comment vanishing it from the page, and use a user-space template call to replace almost the entire page with fabricated comments by other users.

I'm not 100% sure on this, but I think by planting a carefully crafted subst, it may be possible to coerce the next person who edits one part of the page into unknowingly also adding arbitrary content to another part of the page. I believe the diff would show that content as written by that editor. Because the signature exploit would leave no logs, page-history-entry, and no other other trace, there would be no way to tell that the victim had not written the content. The malicious user could make it look like a staff member had given some order, or they could make it look like someone has said something egregiously offensive/abusive.

Given all the exploits and problems, given the bloat this would add to signatures, given the extra processing load, I'm wondering if there's any sufficiently pressing need for this? Instead of going crazy figuring out workarounds and fixes, can the task just be declined?

Catrope added a comment.EditedOct 3 2019, 11:24 PM

For those who are more nefarious, I believe someone could use this exploit to wrap nearly the entire page-contents inside an HTML-comment vanishing it from the page, and use a user-space template call to replace almost the entire page with fabricated comments by other users.

I suppose this wasn't made super clear in the task description and we should clarify it: when we say we want to "encapsulate" signatures, that means we'd wrap signatures in some sort of HTML tag (<span> probably), and enforce that signatures must be balanced HTML. So this kind of attack, where a signature opens a comment or a bold tag or something else that then affects the rest of the page, would no longer be possible. The effects of markup in a signature would be contained to the signature itself.

I'm not 100% sure on this, but I think by planting a carefully crafted subst, it may be possible to coerce the next person who edits one part of the page into unknowingly also adding arbitrary content to another part of the page. I believe the diff would show that content as written by that editor. Because the signature exploit would leave no logs, page-history-entry, and no other other trace, there would be no way to tell that the victim had not written the content. The malicious user could make it look like a staff member had given some order, or they could make it look like someone has said something egregiously offensive/abusive.

Agreed that recursive substitution definitely needs to be disallowed in signatures. Even in the current system, that's bad and we prevent it best we can (not sure how watertight it is, I haven't tried to break it).

Given all the exploits and problems, given the bloat this would add to signatures, given the extra processing load, I'm wondering if there's any sufficiently pressing need for this? Instead of going crazy figuring out workarounds and fixes, can the task just be declined?

I should clarify that dynamic signatures are not the primary purpose of this task, and we could decline to implement them while still implementing this task. The primary reason for wrapping signatures in a parser function is that we would record structured metadata about the signature (who signed and when). That is valuable separate from the question of whether such a parser function would embed the signature dynamically or statically.

In other words, changing signatures to look like {{#:Catrope|20191003162112|[[User:Catrope|Roan]] <sup>([[User talk:Catrope|talk to me]]</sup>}} would be useful, even if this parser function doesn't do anything clever and just outputs its third parameter verbatim (maybe wrapped in something like <span class="signature" data-author="Catrope" data-timestamp="20191003162112">...</span>).

Edited to add: the parser function would also format the timestamp in the wiki language+timezone

Izno added a subscriber: Izno.Oct 5 2019, 6:44 PM

Some thoughts, some of which are in the gist of the above discussion and some of which are new points.

Take care to consider most of the content of en.wp WP:SIG. It has a number of "thou shalt be carefuls", including on the topics of lengthy or transcluded signatures (the latter of which is banned entirely for mostly-good reason and the former of which is frowned-upon). Conversely to the guidance against lengthy signatures, I don't entirely see why a parser function is necessary here to identify signatures reliably. Pick some standard inline elements and add a wrapper on the output of the current signature box. (Any user who wants to remove the cruft after the page saves is going to remove the cruft and we can't do anything about that anyway.)

On that point:

It would also be nice if the parser function output contained this structured data, e.g. <span data-timestamp="YYYYMMDDHHMMSS" data-user="Bob">...</span>

We should use HTML 5 instead if we pursue this option: <span data-user="Bob">... <time...>...</time></span>. The point seems made though.

Make signatures their own page

This or similar might be valuable regardless of this discussion as it would fix T140606: User preferences: Check raw signature for linter errors (or at least subject signatures to wikitext community editing, which also might help communities to enforce their signature policies/guidelines). The problem of course comes down to deciding how to protect the page (maybe set it to have some wikitext signature contentmodel, which has protections similar to the current user css/js content models?).

I have not generally seen signatures with block elements but it's not in the realm of impossibility.

Ontopic but slightly aside, it might be reasonable also to consider T37704: Drop support in wikitext for inline styles in this discussion of signatures (if it ever gets implemented--I have some doubt it will pass the community test, ever).

Jc86035 added a subscriber: Jc86035.EditedWed, Nov 6, 9:59 AM

I think the easiest way to avoid the transclusion problem, while still using such a parser function, would be to insert the complete HTML of the signature into a parameter of the parser function (or to include it before/after the parser function) and add any other necessary user/revision data in other parameters upon page save. While this would introduce redundancy, it would presumably be easier to implement without breaking certain things; e.g. if the user ID is included as a separate parameter, the new talk page interface could link to the user's current userpage regardless of what username is stored in the signature. (I imagine this could cause issues if talk page discussions were imported between wikis, though...)

(I noted in T230658#5637465 that it could be possible to use a signature parser function as a comment delimiter, as opposed to inserting additional HTML into the wikitext in order to do the same thing.)