Skip to content

Instantly share code, notes, and snippets.

@bkardell

bkardell/tag-mathml.md Secret

Last active October 29, 2019 22:25
Show Gist options
  • Save bkardell/46ed26841c5a730a5eb878eb3f96f1ad to your computer and use it in GitHub Desktop.
Save bkardell/46ed26841c5a730a5eb878eb3f96f1ad to your computer and use it in GitHub Desktop.
Download ZIP
Raw
tag-mathml.md

Hello TAG Friends!

I'm requesting a TAG review of:

Further details:

  • Relevant time constraints or deadlines: None specifically beyond our goals to fully upstream an implementation by October 2020 We'd like to continue to progress this long-overdue work.
  • I have read and filled out the Self-Review Questionnare on Security and Privacy. (the assessment is below).
  • I have reviewed the TAG's API Design Principles
  • The group where the work on this specification is: MathML Refresh CG
  • Links to major pieces of multi-stakeholder review or discussion of this specification: * Much of this specification is clarifying with modern rigor a subset of what was both specified in MathML 3 and already shipping in two browsers. Thus far, both WebKit and Firefox have participated, accepted patches and aligned with MathML Core. Our issue tracker shows work and engagement from multiple vendors, including lots of advice and questions from Googlers. Our Intent to Implement also includes encouraging responses.
  • Links to major unresolved issues or opposition with this specification:

You should also know that...

MathML Core comes from previous TAG review of MathML specs/plans. Among our primary aims is to establish an interoperable and widely agreeable starting point for discussions that have been created by MathML's largely unique history. We've taken very much history, commentary (including TAG's) and challenges into account. We've taken great pains to balance many things: Making this as small as possible, align as directly as possible with the rest of the platform (including DOM and CSS), eliminate unknowns and surprises, apply learnings from actual implementations (firefox, webkit, office and TeX), rigorously specify and remain useful and compatibile, improving the many documents that already exist.

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • leave review feedback as a comment in this issue and @-notify @bkardell @fred-wang @rwlbuis

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

Security Questionnaire...

  • What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

    • This feature allows some OpenType parameters from the MATH table to be tested via MathML constructions, similar to what is done in the corresponding WPT tests. These can allow a third-party to detect whether a known math font is installed. This is non-similar to any other non-sensible font data used for text layout, though.
    • The MathML href attribute can be a potential risk of third-party detecting visited websites. We expect that the same mitigation as SVG/HTML links will be performed by implementers.

  • Is this specification exposing the minimum amount of information necessary to power the feature?

    • Yes, no information is exposed in new ways.

  • How does this specification deal with personal information or personally-identifiable information or information derived thereof?

    • n/a - this is simply about the rendering of a kind of text in a tree and setting it inline with other DOM/CSS expectations.

  • How does this specification deal with sensitive information?

    • It doesn't.

  • Does this specification introduce new state for an origin that persists across browsing sessions?

    • No

  • What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?

    • Because it is based on integration with the rest of the platform, we believe nothing new, beyond what is mentioned in the first question.

  • Does this specification allow an origin access to sensors on a user’s device

    • No

  • What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. * Nothing

  • Does this specification enable new script execution/loading mechanisms?

    • This specification adds new script execution mechanisms in event handler attributes (onclick, etc) or href="javascript:..." links, but these already exist for HTML or SVG. It does not add new script loading mechanisms.

  • Does this specification allow an origin to access other devices?

    • No

  • Does this specification allow an origin some measure of control over a user agent’s native UI?

    • No

  • What temporary identifiers might this this specification create or expose to the web?

    • None.

  • How does this specification distinguish between behavior in first-party and third-party contexts?

    • The specification itself does not make any distinction. MathML can be embedded into HTML and in SVG (via the foreignObject element) and it is expected that the same existing restrictions as HTML/SVG will apply for third-party contexts.

  • How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode?

    • No differences.

  • Does this specification have a "Security Considerations" and "Privacy Considerations" section?

    • No, but we will be adding them, largely to reflect what we have listed here.

  • Does this specification allow downgrading default security characteristics?

    • No
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment