Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

Isn't the whole purpose of the tag mechanism there to provide a way for the
sender to tell the receiver more specifically what type the data actually
is?   IE) regular expression instead of just a string,  URI instead of just
a string,  Uint8ClampedArray instead of just a Uint8Array.    Even though
the concept of a Uint8ClampedArray is mostly a javaScript thing as most
other languages naturally are "clamping" bytes to the 0 to 255 range
(because of the definition of a byte), one of the golden rules I always to
try to follow is to preserve "type" as much as possible.

IMHO, the lack of good data typing is one of the reasons we have problems
with JSON.  Having mechanisms to explicitly communicate data type from
sender to receiver is one of the areas where CBOR shines.  Frankly, I don't
see it as any more of a security issue than any other data type tagging in
CBOR.  In all cases, all receivers should be coded to properly handle what
data types it needs to deal with and also properly handle any situation
where it receives a tag that it isn't coded to explicitly handle.

..Sean Solberg

On Thu, Jul 25, 2019 at 9:06 PM Carsten Bormann <cabo@tzi.org> wrote:

> On Jul 25, 2019, at 16:36, Jeffrey Yasskin <jyasskin@google.com> wrote:
> >
> > I remain
> > uncomfortable with having a serialization format describe behaviors
> > that the data had or should have when it was or is loaded into a
> > program.
>
> I don’t know how to avoid that.  If the input is an array, in most generic
> decoders I get an array to work from.  If the input is instead a map, I get
> a map (or a JavaScript object); that has quite different behavior.  So the
> supplier of the input already has a lot of control over the data structures
> that are input to my system.  Uint8ClampedArray just adds a slight twist to
> that as it might look too much like a Uint8Array.
> None of this relieves an application of validating its input — with a
> standard serialization format and a robust generic decoder, this can now
> simply be done on a higher level.
>
> Grüße, Carsten
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>