[x3d-public] Simplifying ProtoInstance nodes; spec security precaution
John Carlson
yottzumm at gmail.com
Mon May 12 12:01:44 PDT 2025
Understood that catching this error may slow down performance, and
debugging should be done in offline tools.
Obviously the programmer may not know that a Proto is a X3D native node.
Essentially, we want const for X3D and perhaps provide an SFBool field for
people to override a node definition.
John
On Mon, May 12, 2025 at 11:49 AM Andreas Plesch via x3d-public <
x3d-public at web3d.org> wrote:
> 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
> _______________________________________________
> 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/762d9b8c/attachment-0001.html>
More information about the x3d-public
mailing list