Remove <object typemustmatch>

[annevk]

It did not get wide enough adoption and causes a minor cross-origin leak.

See https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0144.html for its introduction and https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#object-typemustmatch for the leak.

• At least two implementers are interested (and none opposed):
  • Neither Chrome nor Safari has shipped this in the past 8 years and Firefox is willing to remove.
• Tests are written and can be reviewed and commented upon at:
  • HTML: mark typemustmatch historical web-platform-tests/wpt#16656
• Implementation bugs are filed:
  • Chrome: NA
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1548773
  • Safari: NA

(See WHATWG Working Mode: Changes for more details.)

---

/iframe-embed-object.html ( diff )
/indices.html ( diff )
/obsolete.html ( diff )

[zcorpan]

How does the leak of the content-type compare to the risk the attribute is supposed to help with? Can we still address the original attack somehow?

  <p class="warning">Authors who reference resources from other <span data-x="origin">origins</span>
  that they do not trust are urged to use the <code
  data-x="attr-object-typemustmatch">typemustmatch</code> attribute defined below. Without that
  attribute, it is possible in certain cases for an attacker on the remote host to use the plugin
  mechanism to run arbitrary scripts, even if the author has used features such as the Flash
  "allowScriptAccess" parameter.</p> <!-- for example, if the user doesn't have flash installed but
  does have java installed, and the remote site unexpectedly returns java instead of flash, then
  java will run, and it will ignore the allowScriptAccess thing -->

Java is not available anymore, but the attack could be to load HTML instead of Flash, or Flash instead of an image or PDF.

This functionality can be used to determine whether the response has the Content-type: text/html because if the embedded object was loaded successfully the number of frames will increase.

So this allows for stricter checking if something is of a particular content-type compared to other features.

Worth to mention, typemustmatch also ensures that the server responded with a 200 OK header or the resource won't be loaded otherwise. Hence, it is possible to detect error pages as well.

I think this is possible regardless of typemustmatch (per spec).

[annevk]

Basically, do not use object or embed to load untrusted resources, as I wrote in the obsolete section. Plugins are slowly going away and there's not much motivation from anyone to further invest in these elements I think.

(I agree that 2xx is exposed either way, not sure why that was mentioned as part of this attribute.)

[zcorpan]

I think we should still have a warning for embed and object about the risk of loading an untrusted resource, and trying to use type-specific sandboxing techniques (like "allowScriptAccess" for Flash).

Also we should probably more directly recommend to use iframe for HTML (and PDF?) and img for images, instead of embed/object. (This can be separate though.)

[sideshowbarker]

heads-up @whatwg/documentation