[sc34wg3] <mergeMap/> and security

[Patrick Durusau]

Lars,

Lars Heuer wrote:

>Hi Patrick,
>
>[...]
>  
>
>>What do you think the "purpose of the "mergeMap" element [was] in the 
>>first place?"
>>    
>>
>
>I think the mergeMap element was designed to ease the _authoring_ of
>XML Topic Maps.
>
>  
>
?? Well, I suppose if you think of merging as _authoring_ that is a 
valid claim.

>[...]
>  
>
>>And how do you see that as fitting into a notion of an "interchange" syntax?
>>    
>>
>
>  
>
>>Note that I am assuming that by "interchange" we actually mean 
>>"anonymous interchange," that is no further communication with the 
>>source of the file is needed for me to use the file that I have been 
>>given.
>>That is it contains all the information necessary for me to make
>>use of it. It does not, however, predetermine the use to which it may be
>>put.
>>    
>>
>
>That is exactly my point of view. But as long as the mergeMap element
>is in the syntax, the user needs to communicate.
>IMO a user expects that a particular file is self-contained. But with
>the mergeMap element inside the XTM syntax, a XTM document may not be
>self-contained.
>The user cannot put a XTM file on a USB stick and read it with a
>laptop without an Internet connection if it contains a mergeMap
>element. To ensure that she can read the XTM document under (nearly) all
>possible circumstances, she has to open the XTM file and look if it
>contains mergeMap elements (a XTM novice won't do that).
>
>  
>
You are presuming that the 2nd XTM instance is not also residing on the 
USB stick.

>>With that observation, what is the purpose of the "mergeMap" element?
>>    
>>
>
>It may ease the authoring process but it puts definitely a burden on
>the receiver of a XTM file.
>
>*We* know that the usage of the mergeMap element in a document may
>cause problems, novice XTM / Topic Maps users will not.
>
>Novice XTM authors are not aware of the impact of the mergeMap
>element. They will use it because it is in the syntax. They don't
>imagine that the receiver of the XTM file may disable the processing
>of mergeMap element because of security or other reasons. Or that the
>user of the XTM file uses an application with a fixed or configurable
>'mergeMap-processing-level'.
>They assume that everything works fine, because the mergeMap element
>is part of an international standard. They cannot know about the
>provisos against the mergeMap element (either for security or other
>reasons).
>
>If the mergeMap element is not in the standard nobody can use it and
>we won't have XTM reader implementations with different behaviours.
>
>  
>
Well, yes, but I hate to think that we would alter the syntax to account 
for user ignornance.

But your argument has uncovered a problem with the original syntax.

Instead of:

ATTLIST mergemap

id ID #IMPLIED
xlink:type FIXED 'simple'
xlink:href CDATA #REQUIRED

We should have added:

xlink:actuate (onLoad | onRequest | other | none ) #IMPLIED

>The self-contained XTM file will be proceed how the author of the XTM
>document assumes that it will be proceed without taking care about the
>security settings of the receiver.
>
>  
>
An XTM document with mergeMap proceeds just as its author expected as 
well. I thought that was your point.

That is that a malicious XTM author would rely upon mergeMap to inflict 
harm on an unsuspecting consumer of an XTM instance.

Now we have an idiot who doesn't understand the function of mergeMap 
that is committing topic map suicide.

But in either case, it is the behavior of the application that is at 
issue. Yes?

Hope you are having a great day!

Patrick

PS: I don't disagree that there are all sorts of vicious things that are 
possible even with XTM topic maps. Moreover, there is the more 
interesting (to me anyway) question of how does one hide information in 
a topic map? We have always presumed that information is placed in a 
topic map to be found, but that may not always be the case. Or at least 
one may only want it to be found by particular individuals or under 
certain circumstances. Thinking of "hiding" information in plain sight 
as it were.

-- 
Patrick Durusau
Patrick at Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!