Minutes_ MathML Core meeting _ 29 April_ 2024

04/29/2024 MathML Core Meeting<https://github.com/w3c/mathml-core/issues/239>

Attendees

  *   Brian Kardell
  *   Neil Soiffer
  *   Louis Maher
  *   David Carlisle
  *   Deyan Ginev
  *   Paul Libbrecht
  *   Bruce Miller
  *   Bert Bos

Regrets

Action Items

ACTION PL will summarize his resolution into MathML Elements in the HTML Sanitizer issue (227)<https://github.com/w3c/mathml-core/issues/227> PL will ask Fred for his comments. PL's resolution is:

( PL: proposed resolution:

  *   Name spaces are meant to be completely reduced to what is in the dom, and scripts should be emptied, and href should be treated like html.
  *   maction is emptied
  *   annotation and annotation-xml go away in "paranoia" mode and are kept otherwise (paranoia mode is that of data- attributes). )



ACTION NS will look at section 4.1.2 in the spec and see if there are any issues with name role and value computations. He will check to see if other specs say something about this.


Agenda Items
Announcements/Updates

The next core meeting will be held on Friday, May 24, 2024, at our regular time.

The June core meeting will be held on Thursday, June 27, 2024, at our regular time. This meeting will be a combined core and intent meeting.


MathML Elements in the HTML Sanitizer<https://github.com/w3c/mathml-core/issues/227>

PL: We need to do something when we can act. There is the restricted view to just ditch everything annotation related so that everything is safe.

DG thought that we could keep annotation in some cases.

PL: I would suggest that we keep annotation XML, but we remove anything that is known to be dangerous, which is namespaces, external entities, and essentially any HTML element.

PL: I think doing this makes it bulletproof, unless someone has a dangerous semantic behind something like calculating the factorial of a million, which is dangerous to all computers.

DG described a method where you could inject JavaScript and gain control of the web page and host server.

PL: That would mean that the sanitization takes responsibility for broken parsers. To me, this is going too far.

PL: But I know that you can find vulnerabilities everywhere. Hackers are creative.

PL: I would expect this to be a political thing that says, you know, somewhere you are introducing extensibility, and that extensibility is going to be abused, so we should have an on/off switch for the extensibility.

PL: Then potentially we should not allow any annotation; but, then text annotation is just as dangerous.

PL: There is an open operability somewhere, but it may be broken and because it may be broken, we need to be able to shut it off on a browser safety thing or on a web page.

DG: They think that even programming languages have something like taint mode where you just go into paranoid mode and shut off as many capabilities as you can to have a very small surface that is safe from attackers.

NS: Do we have a problem with intent which is not open ended, but it is complex?

DG: I would compare intent to the style attributes, and it is fine.

BK: Do you want some proposed resolution? I was looking at this today to see if there is a MathML safe list.

BK wanted to see what SVG does; however, SVG does not have a safe list either.

NS: I do not see that the sanitizer documentation mentions links.

PL: Links require an explicit action from the user, so they are OK.

BK: There are still things that are being figured out. This document has had work lately.

BK to PL: Do you have a concrete thing to have a resolution on?

PL: proposed resolution:

  *   Name spaces are meant to be completely reduced to what is in the dom, and scripts should be emptied. href should be treated like html.
  *   maction is emptied
  *   annotation and annotation-xml go away in "paranoia" mode and are kept otherwise (paranoia mode is that of data- attributes).

BK: The paranoia mode should be the default, and then you can opt to be less paranoid.

BK to DG: Are you looking for a resolution?

DG: I am neutral on whether there are one or two switches. But I am hoping we can get the switch to choose whether annotation is or is not allowed.

BK: Can we provide a custom dictionary?

PL: Currently we can provide a custom dictionary.

BK: I believe that we can provide a default dictionary, and users can provide a custom dictionary.

ACTION PL will summarize his resolution into MathML Elements in the HTML Sanitizer issue (227)<https://github.com/w3c/mathml-core/issues/227> PL will ask Fred for his comments. PL's resolution is: ( PL: proposed resolution:

  *   Name spaces are meant to be completely reduced to what is in the dom, and scripts should be emptied, and href should be treated like html.
  *   maction is emptied
  *   annotation and annotation-xml go away in "paranoia" mode and are kept otherwise (paranoia mode is that of data- attributes). )

BK: The busy people's introduction to trusted types: From Brian Kardell to everyone: https://bkardell.com/blog/blessing-strings.html

DG: I would like to back off at least half of my points. Maybe I should back off the entire point. So, I was reading and listening to you (BK). It was extremely helpful. I realized that the data flag exists as a flag because it is not possible to capture it with a list, because the data- is a namespace. You can list out any attributes, annotation, annotation Xml or fixed there. Just so you can use the existing attribute, and element slots to list them. So, there is no need for a new mechanism. So, I would like to retract that entirely on my part. I still think the data toggle on and off is the same as annotation on and off.

BK: I have some moderate feelings on the linking element as well. Mainly because most of the links that exist are not on mrow today, and that aligning it on (a) seems to be a good idea.


Add more details to the stretchy algorithm<https://github.com/w3c/mathml-core/issues/238>

Define Accessibility Mappings for MathML Elements #196<https://github.com/w3c/mathml-core/issues/196>

NS has submitted his request to be a co-author. He has not heard back about that.

BK: We cannot close the issue until NS is confirmed to be a co-author.

BK was going to create a pr for NS to be a co-author.


i18n review

  *   Define that (and how) glyph assemblies are mirrored in rtl formulas<https://github.com/w3c/mathml-core/issues/235>
  *   Explain the mapping tables (appendix C)<https://github.com/w3c/mathml-core/issues/234>
  *   Whether/when to mirror operators #233<https://github.com/w3c/mathml-core/issues/233>
  *   lspace/rspace have confusing names #232<https://github.com/w3c/mathml-core/issues/232>

BB: We can say that we do not plan to change this notation. BB thinks this would be acceptable.

BK: We could do what CSS did and have boarders: top, bottom, left, and right.

BK: The current terms must remain in place as a legacy issue.

BK: Maybe we open an issue and/or make a note in the spec.

  *   Clarify single character of mi as italic #231<https://github.com/w3c/mathml-core/issues/231>


APA review<https://github.com/w3c/apa/issues/344>

BK: We received feedback from accessibility review, and we have a lot of issues to work out. We must resolve these issues before we can advance.

BK thinks everyone should go and digest the feedback on issue 344.

PL: This is about the spec itself, to be APA compatible, and to be readable.

IN issue 344, Keith Newton (newtonsgroov" commented that Our document did not mention a base-level of compliance. We need to include such a statement. He offered several levels:

Simple, more robust, and even more robust.

BK: See if a recent spec would give us something to follow.

NS: SVG would not be a proper guide.

We resolved to do the simple level of compliance in issue 344.

ACTION NS will look at section 4.1.2 in the spec and see if there are any issues with name role and value computations. He will check to see if other specs say something about this.

After the meeting NS wrote:

( At the core meeting, I was tasked to look at some specs for how they handle the accessibility requirements.

There is some semi-boilerplate that is in line with our thoughts for "simple" in response to the APA requests (see below for examples). They are in the spec itself, not an appendix. However, they tend to be the end near sections on security, privacy, and internationalization.

To me, it seems fine to add another appendix near the current ones entitled "Accessibility Considerations".

Some examples: https://www.w3.org/TR/vc-bitstring-status-list/#accessibility-considerations https://www.w3.org/TR/vc-jose-cose/#accessibility https://www.w3.org/TR/vc-data-model-2.0/#accessibility-considerations https://www.w3.org/TR/epub-33/#sec-accessibility )