[x3d-public] browser importDocument SAI service

[Leonard Daly]

On 10/24/2016 8:23 AM, Don Brutzman wrote:
> On 10/23/2016 8:18 PM, Leonard Daly wrote:
>> On 10/23/2016 2:35 PM, Don Brutzman wrote:
>>> On 10/22/2016 8:35 PM, Andreas Plesch wrote:
>>>> On Oct 22, 2016 6:27 PM, "Don Brutzman" <brutzman at nps.edu> wrote:
>>
>>>>> - loading HTML that contains embedded X3D scene
>>>>
>>>> parsing HTML into a DOM is very available. I am not quite sure what 
>>>> scenario you would have in mind here.
>>>
>>> something like
>>>
>>> http://www.web3d.org/x3d/content/examples/HelloWorldCobweb.html
>>> or
>>> http://www.web3d.org/x3d/content/examples/HelloWorldX3dom.xhtml
>>>
>>> in other words, an HTML document that contains an X3D scene, should 
>>> we have a utility method that loads the document but strips out any 
>>> HTML/CSS/etc. and leaves only X3D scene
>>
>> This is potentially risky because JavaScript can modify or even 
>> create the HTML as the file is loading to produce different results. 
>> Some HTML frameworks (e.g., React.js) load partial content until the 
>> region to be display is nearly visible to the user, then the entire 
>> region is loaded. The scene may also contain some vendor-specific 
>> scene elements that should not be filtered out.
>>
>> It is probably much easier (and safer) if you only accept straight 
>> X3D than start mandating that the embedded X3D in HTML follow some 
>> very specific design constraints.
>
> Security issues are certainly always worth considering.

Security is potentially an issue. I was thinking of something much more 
just related to content.

Consider the following HTML code snippet


<script>
document.writeln ('<X3D id="x3d_scene" ...>');
</script>
     <Scene>
         <Transform>...</Transform>
             :
             :
     </Scene>
</X3D>


Without the part in the script, there the opening X3D tag is missing; 
however, a browser would handle this correctly.

Another case: Someone is developing a new node -- StereoViewpoint. If 
the extractor program knew X3D nodes, then StereoViewpoint would not be 
identified as such. If the extractor program did not know about X3D 
nodes but took everything between <x3d> and </x3d>, then any non-X3D 
nodes (e.g. HTML elements) would be included.

My point being that requiring a capability to store X3D nodes in an HTML 
document is creating a very difficult and perhaps unsolvable 
requirement. For an analogy, you don't see HTML embedded in JPEGs.


Leonard Daly




>
> Any DOM-tree document is subject to prior modification before loading.
>
> Importing a DOM document is not a live self-modifying object at time 
> of import, rather it is simply the string data contained in the DOM 
> element/attribute tree.
>
> If a utility method filters out everything but the X3D-related 
> document subgraph within an HTML document graph, the security issues 
> would seem to be the same as importing an X3D document in the first 
> place.
>
> all the best, Don


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161024/37c2c2b7/attachment.html>