Re: [Ltru] Re: WGLC security considerations

At 04:10 17/08/2005, Frank Ellermann wrote:
>r&d afrac wrote:
>
> > The specific risks due to the language tags are numerous. I
> > will identify three of them:
>
> > - risk of confusion as they introduce non network related
> >   information where network related information is needed.
> >   This risk is structural
>
>In other words it's a feature and no bug, unavoidable, if an
>evil party wants to censor say "ARAB" they can (try to) do
>this.  I could also do it for completely harmless reasons,
>because I cannot read this script.
>
>That's nothing new, everybody knows it, it's also applicable
>on charsets.  Your concept of "non network related information"
>makes no sense for me.  Language tags and / or charsets are
>"network related".

Frank,
I am afraid you miss the point here. What is considered is the nature of 
the information which does not match the needed nature. The information 
passed in langtags defined by the Draft necessarily consider a language as 
something probably totally different from the way a network-aware 
application or network user will consider it. Necessarily because it is 
related to ISO 639 which does not define language in a network environement 
and because the Draft does not say how it adapts the ISO lists to an IETF 
protocol. A simple example is that the computer languages are not 
supported. I do not know what is/is not a computer language. When I filter 
English with DoD programs to evaluate their complexity am I refering to 
plain English or to a computer acceptable language? When I use "English" as 
a programmation Language in an IA or Pick or else environment what is it? 
There are many computer scripts which are totally understandable by humans. 
What is "basic English"? Is it documented?

The systems we work on are to support billions of language variations, to 
support every individual's avatars and computerised tools (not big deal, 
just standard internet architecture - but used in a distributed way, not in 
a centrally controlled way), how can the language tags support that in a 
human readable/mnemonic way?

The risks of confusion, innovation blockage, etc. is not only for the Draft 
application. It has been fully documented by the way this WG has receieved 
our current work.

> > Language tags greatly simplifies the intelligence gathering,
> > filtering, spying, censoring ... and their errors.
>
>Yes, I know that risk since I tried to "spamcop" a mail from
>Martin because it had a 2047 subject with a Japanese charset.
>
>There are uses, abuses, and errors.  Not very surprising, that
>is obvious.

The purpose of the security section is to document all the risks increase a 
user may run into in applying the document. This has nothing to do with the 
fact the document is good or not. Except that the document is bad if it 
does not provide a full review of the risks increases.

> > Not considering language tags in OPES context for example is
> > big mistake.
>
>Let the OPES folks address it in their documents, it's not
>different from the situation as it is today (before 3066bis).

??? I am afraid you have missed the purpose of the Draft then. And of the 
Security section.
IRT OPES folks, if I am here it is because of the disregard of the OPES 
which are not an issue of the WG-OPES (which have published difficulties 
understanding the matter which is complex) but an issue related to the IAB 
RFC 3238 on the matter.

This will certainly be a point to be risen in a request for IAB guidance in 
IAB level appeal.

> > But the main issue is that the user cannot turn it down.
>
>Of course you can, nothing forces you to spell out say "TW" if
>you think that this might hurt the propagation to "CN".

???
You are to receive the langtags sent by the sender, that you like it or not.
To some extent, OPES are a danger used by a foe, and an help to remove them 
if used by a friend.

> > I have no doubt people will die and suffer because of the
> > ABNF.
>
>Assuming that the "TW" example is dangerous, then using x-tw1
>to "avoid" this risk is 1) allowed 2) won't help.  The worst
>you can do for privacy and anonymity are _false_ promises.

Again, the point is not to address the problem. The point is to list it. 
Possibly document it. It is to the users to decide using it or not, 
considering its con and pros.

jfc

_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru