[x3d-public] Simplifying ProtoInstance nodes; spec security precaution
Andreas Plesch
andreasplesch at gmail.com
Mon May 12 09:47:32 PDT 2025
Good point, trying to overload/redefine existing nodes should be considered
on a different level than undefined behaviour for rendering or interactions.
What are the implications of the spec. deeming this an error ?
- the document becomes invalid X3D ?
- a conforming browser should/must recognize the conflict and do something
appropriate, eg. warn and halt, or warn and ignore proto declaration, or
just warn ?
- what else ?
-Andreas
> Date: Mon, 12 May 2025 04:36:26 +0000
> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> To: Holger Seelig <holger.seelig at yahoo.de>, X3D <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Simplifying ProtoInstance nodes; spec
> security precaution
> Message-ID:
> <
> BY3PR13MB4884EC77F3E676D12B70AED3C497A at BY3PR13MB4884.namprd13.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> I found the specification prose mentioning re-definition of existing
> nodes. Important problem to catch in implementations!
>
>
> *
> X3D Architecture, v4.1 draft, Clause 4 Concepts, 4.4.4 Prototype
> semantics, 4.4.4.1 Introduction
> *
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#PrototypeSemanticsIntro
> *
> "Node type names shall be unique in each X3D file. The results are
> undefined if a prototype is given the same name as a built-in node type or
> a previously defined prototype in the same scope."
>
> I also found the following related security precaution, introduced in X3D
> 4.0:
>
>
> *
> X3D Architecture, v4.1 draft, Clause 4 Concepts, 4.4.4.3 PROTO definition
> semantics
> *
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#PrototypeSemantics
> *
> "Security precaution: it is an error for a prototype to reference an
> instance or repeated declaration of itself, directly or indirectly, in
> order to avoid nonterminating recursion loops. This error might occur with
> either local or external (PROTO or EXTERNPROTO) declarations. X3D browsers
> shall not honor self-referential loading of prototype declaration loops in
> order to avoid security vulnerabilities."
>
> Along those lines, it is easy to imagine all sorts of mischief if a
> prototype overloads a given node in the specification. For example,
> creating a new Transform prototype that is actually a Box then breaks all
> other regular Transform nodes.
>
> As a result, I now think we should not allow overloading an existing node
> name, since it is a security problem. Saying that results are undefined is
> unacceptably weak.
>
> Something else to remain cognizant of: during X3D evolution, we often
> prototype proposed new nodes to test their proposed functionality.
> Further, if the node is eventually accepted, then existence of the
> prototype provides helpful backwards compatibility for earlier versions of
> the X3D standard.
>
> Suggested spec change in 4.4.4.1 Introduction of X3D Architecture, thus
> applying to all X3D file encodings and programming-language bindings:
>
>
> *
> "Security precaution: it is an error for a prototype to rename a built-in
> node type that is already defined in the X3D version referenced by an X3D
> model."
> *
> "The results are undefined if a prototype is given the same name as a
> built-in node type or a previously defined prototype in the same scope."
>
> *
> TODO: consider including an example that renames Transform using a
> prototype declaration for a Box, specifically saying it is not allowed.
> This is similar to your example Holger, but more egregious and damaging to
> the model.
> *
> EXAMPLE PROTO Transform [] { Box {} } # specifically disallowed
>
> As ever, comments welcome. Dick and I will also consider this situation
> when creating the Mantis issues and specification prose improvements.
>
> Have fun with secure X3D...
>
>
> all the best, Don
>
> --
>
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, navy robotics
> https://faculty.nps.edu/brutzman
>
>
>
> ________________________________
> From: Holger Seelig
> Sent: Saturday, May 10, 2025 12:37 PM
> To: X3D
> Cc: Michalis Kamburelis; Brutzman, Donald (Don) (CIV)
> Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>
> There is another drawback which already exist in VRML encoding. What take
> precedence if a PROTO is named as a build-in node. Consider a PROTO named
> Box with a Sphere as root node. What is happening if a Box is now
> instantiated?
>
> PROTO Box []
> {
> Sphere {}
> }
>
> Shape {
> Box {}
> }
>
> This behaviour is not handled by the specification, but X_ITE does the
> following: build-in nodes will take precedence over over PROTO nodes, it
> will still display a Box node. Don?t know what Caste or X3DOM does. With
> current XML encoding this is very cleared and there is no prob at all. But
> in VRML encoding or with XML ?short syntax? this may be worth a spec
> comment.
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
> https://patreon.com/X_ITE
>
>
>
> Am 10.05.2025 um 20:44 schrieb Brutzman, Donald (Don) (CIV) via x3d-public
> <x3d-public at web3d.org>:
>
> +1 on all counts, thanks for thoughtful consideration Michalis.
>
> Further considerations are always welcome.
>
> Next week Dick and I will review comments, then consider a Mantis issue
> and draft prose addition to X3D XML Encoding.
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu<mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> https://faculty.nps.edu/brutzman
>
>
>
> ________________________________
> From: Michalis Kamburelis
> Sent: Saturday, May 10, 2025 11:38 AM
> To: Extensible 3D (X3D) Graphics public discussion
> Cc: Brutzman, Donald (Don) (CIV)
> Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>
> I think this short form (in XML encoding) makes sense, and Castle Game
> Engine / Castle Model Viewer could support it too.
>
> It makes XML encoding and classic encoding more consistent: you can use
> PROTO to define a new node, and then use the new node with the same syntax
> as "built-in nodes". This is already true for classic encoding, it's nice
> to bring this feature to XML encoding.
>
> Don has already expressed the important drawback of this "short form":
> such XML will not validate. I mean, it will validate in X3D-specific tools
> like "castle-model-converter --validate .." (once we add support for it),
> but the general XML validation using XML Schema has no way of validating
> it. You cannot tell in XML schema "this XML element name is valid, if
> defined by some XML attribute elsewhere". I'm guessing this was the whole
> reason why ProtoInstance, fieldValue etc. were invented in XML encoding.
>
> I'm guessing in JSON X3D encoding, the consideration will be similar: it
> can be implemented, but the resulting file will not validate with JSON
> schema ( https://json-schema.org/ ).
>
> Anyhow, if we're all fine with accepting this drawback, then we sure can
> go ahead and add it to spec :) As long as "long form" remains available,
> and thus tools like XML schema and JSON schema remain useful, I think it
> makes sense to have this choice.
>
> Regards,
> Michalis
>
> sob., 10 maj 2025 o 18:38 Brutzman, Donald (Don) (CIV) via x3d-public <
> x3d-public at web3d.org<mailto:x3d-public at web3d.org>> napisa?(a):
> Thanks for the interesting, innovative discussion. Excerpting the example:
>
>
> *
>
> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>
> _________________________
> XML Encoding
>
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
>
>
> <!-- Official Syntax -->
> <ProtoInstance name='BouncingBall'>
> <fieldValue name='cycleInterval' value='2'/>
> <fieldValue name='bounceHeight' value='3'/>
> </ProtoInstance>
> <!-- Short Syntax -->
> <BouncingBall
> cycleInterval='2'
> bounceHeight='3'/>
>
>
> Classic VRML Encoding
>
> 1
> 2
> 3
> 4
>
>
> BouncingBall {
> cycleInterval 2.0
> bounceHeight 3.0
> }
>
>
> _________________________
>
> One drawback with the "short" XML syntax is that it will not pass XML
> DOCTYPE or XML Schema validation, although it still must conform to XML
> well-formed rules. Additional tool-specific capabilities can check for
> such correctness during parsing, of course. Avoiding XML validation
> relaxes quality assurance (QA) for the entire scene, not just that
> prototype instance, and so use of the short form should be considered
> carefully.
>
> Of course there is much merit too, not least of which are readability and
> consistency with other XML-encoded nodes.
>
> As it turns out, now is a good time to consider such a change to the X3D
> Standards suite. We have highly mature documents defining X3D encodings
> using XML and ClassicVRML syntax. Conceivably a "short" form for
> ProtoInstance will carry over satisfactorily for JSON and other encodings
> as well, when we get to them this fall.
>
> If X_ITE and X3DOM already handle this form, and if Castle Model Viewer
> (Castle Game Engine) is also supportive, I'm not yet seeing any blockers to
> adoption. Further implementation and evaluation of course will be useful
>
> Reference and specific clause that would need modification:
>
>
> *
> X3D XML Encoding 4.0<
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/X3D_XML.html>
> revision 19776-1
> *
> 4.3.3.2 ProtoInstance node and fieldValue statement syntax
> *
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/concepts.html#ProtoInstanceAndFieldValueStatement
>
>
> Probably no changes needed:
>
>
> *
> X3D Classic VRML Encoding 4.0<
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/X3D_ClassicVRML.html>
> revision 19776-2
> *
> 4.3.3.2 Prototype instances and field value initialization syntax
> *
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/concepts.html#ProtoInstanceAndFieldValueStatement
>
> *
> X3D Architecture 4.1<
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/Architecture.html>,
> revision 19775-1
> *
> 4.4.4 Prototype semantics
> *
>
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#PrototypeSemantics
>
> Thanks for careful consideration of this potential capability. All
> feedback welcome.
>
> Have fun with X3D extensibility! ?
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu<mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> https://faculty.nps.edu/brutzman
>
>
>
> ________________________________
> From: x3d-public on behalf of Holger Seelig via x3d-public
> Sent: Saturday, May 10, 2025 1:13 AM
> To: X3D
> Cc: Holger Seelig
> Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>
> This is already possible if you use the ?short syntax? of a proto instance:
>
>
> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>
> You can use this in X_ITE, but also in X3DOM.
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de<mailto:holger.seelig at yahoo.de>
> https://create3000.github.io/x_ite/
> https://patreon.com/X_ITE
>
>
>
> Am 10.05.2025 um 05:55 schrieb John Carlson via x3d-public <
> x3d-public at web3d.org<mailto:x3d-public at web3d.org>>:
>
> My thought is to replace ?ProtoInstance? tags with ?MenuItem? tags, and
> fieldValue statements with attributes, but I?ve not done that before. My
> goal is to make the model more accessible to screen readers.
>
> Any examples are welcome.
>
> See attached link and model.
>
> John
>
> ---------- Forwarded message ---------
> From: John Carlson <yottzumm at gmail.com<mailto:yottzumm at gmail.com>>
> Date: Thu, Mar 6, 2025 at 4:35?PM
> Subject: Latest cleaned Jin FACS (needs metadata)
> To: Don Brutzman <brutzman at nps.edu<mailto:brutzman at nps.edu>>, Joe D
> Williams <joedwil at earthlink.net<mailto:joedwil at earthlink.net>>
>
>
> Attached.
>
> And:
>
> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d
>
> John
> <CleanedYouClocks.x3d>_______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org<mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org<mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250512/43904ff2/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 194, Issue 43
> *******************************************
>
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250512/e4ceff29/attachment-0001.html>
More information about the x3d-public
mailing list