Subject: [Cellar] Matroska Attachments

From: Dave Rice <[email-masked]>
Date: Sun, 13 Mar 2016 10:44:52 -0400

Dear CELLAR,

From a review of the Attachments section a few more questions and comments before I send a patch.

What is the status of FileReferral, FileUsedStartTime, and FileUsedEndTime. These seem to be part of a Matroska extension for divX. Should these Elements be included in our work? Are these deprecated?

FileUID is defined as "Unique ID representing the file, as random as possible." (actually many UID Elements use this language about randomness). Does this mean that a Unique ID field could be any length from 1 to 8 octets? Or are Unique IDs presumed to be a specific length?

Most of the specific narrative about attachments appears to be here: https://www.matroska.org/technical/cover_art/index.html. It lists some reserved attachment file names like cover, cover_land, small_cover. Are there more reserved names like this? I think this document should be expanded to cover other use cases for attachments to include both access and preservation examples, but what should they be:
- cover, poster images
- fonts to support subtitles
- logs or additional metadata
- archived copy of a decoder?

I'd be interested to here in other innovative ways to use attachments.

Also the cover image examples seem to use specs that are aged. A cover image is recommended to be 600 pixels tall/wide, but should this values be increased as user expectations of image quality increase?

Dave Rice

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 20 Mar 2016 10:26:03 +0100

> FileUID is defined as "Unique ID representing the file, as random as possible." (actually many UID Elements use this language about randomness). Does this mean that a Unique ID field could be any l…

It doesn't specify any length, but the bigger the more random. The
binary approach of FileReferral allows longer lengths so we may keep
it. But it's not good to have 2 systems in place. I'd rather turn
FileUID into a binary element (as well as TagAttachmentUID and
AttachmentLink). It's doable as all existing values would still be
interpreted the same.

As for the format, different systems may want to use different things
like MD5, SHA-1 or some random number. Not sure if we should force one
of them.

> I'd be interested to here in other innovative ways to use attachments.

A matroska file with just attachments for storage. But I don't think
it has any advantage over TAR or RAR.

> Also the cover image examples seem to use specs that are aged. A cover image is recommended to be 600 pixels tall/wide, but should this values be increased as user expectations of image quality inc…

As recommandations, yes.

> Dave Rice
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sun, 20 Mar 2016 19:32:49 +0100

>> I'd be interested to here in other innovative ways to use attachments.

- Preview images for media catalogs that don't contain any codecs.
- Text-basted information about the content, plot, cast or whatever.
(media libraries could use them)
- Error recovery files e.g. using hamming codes. (for tools that try to
recover errors, not for players)
- Specifications of Matroska, the audio codecs, video codecs, the
subtitles (for very long-term storage)
- Public-key (DRM is possible, but also authenticating against a server
to get updates on the content you watch [or are about to watch], like a
documentary you purchased.)
- Picture or text-based annotations.

> it has any advantage over TAR or RAR.

It certainly has the advantage that attachments can't be lost.
Attachments can't be edited (directly), which has both advantages and
disadvantages. So unless someone touches the matroska file it contains
all the attachments that are the way the creator intended them to be.

With an archive you can extract all files, then delete some or extract
the archive just partly.

Like having a font that is supposed to be used with one of the subtitles
that has been muxed into the file.

Having more ways to interact with attachments in Matroska seems like a
good thing to me. Safely handling the attachments is up to the
application anyway. Should anyone be concerned about security
attachments could be ignored.

I'd like to see Matroska used more often than it is right now. AVI was
good enough back in the good old days, currently MP4 seems to offer
enough that it is used very very often. If Matroska has more advantages
over other containers it should see more usage, at least in theory.

>> Also the cover image examples seem to use specs that are aged. A cover image is recommended to be 600 pixels tall/wide, but should this values be increased as user expectations of image quality in…

How would "values be increased as user expectations of image quality
increase" be specified?

It is possible to recommend a minimum resolution. To me it seems like a
good idea to do so. It is possible to recommend a maximum resolution,
but here I would let it open as the limit might not be adequate.

Currently it can't be expected that a 4K image will be displayed by
everything that supports cover images right now, but at some point in
might be the case.

You might could say "image quality should reflect state-of-the-art
standards, while also considering legacy systems."

Best regards,
Sebastian

---

From: Michael Niedermayer <[email-masked]>
Date: Sun, 20 Mar 2016 21:21:04 +0100

> recover errors, not for players)

isnt that outside the scope of matroska ?
that kind of recovery makes sense for any file, not just multimedia
also such attachments would become invalid very likely if they get
just copied from an input to an output matroska file, so would
require some special care in tools

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sun, 20 Mar 2016 21:51:30 +0100

> isnt that outside the scope of matroska ?

For implementing in Matroska directly, probably.

Since this is about the attachment system it can be used for that or any
other thing.

> require some special care in tools

Indeed, special tools would be required to handle this case.

That should be no concern to Matroska itself.

Even cover images are not of great use for a media player, that reads a
file and just plays it.

Best regards,
Sebastian

---

From: Steve Lhomme <[email-masked]>
Date: Mon, 28 Mar 2016 14:30:39 +0200

> With an archive you can extract all files, then delete some or extract

You can probably do the same with Matroska. Adding Matroska support in
7-zip might be a fun project (if it's not handled already). After
that, apart from the multimedia part of the file it's just a (very)
basic archival format.

> attachments could be ignored.

Yes, for example there might be a virus in a font and you might have
to install it on the system before you can use it. Same thing with a
PNG or a JPEG. That's already a concern with what we have now. But
it's out of the scope of Matroska how each type of file is used. As
long as we extract the proper data, not more, not less with the proper
strings attached, we're fine.

> over other containers it should see more usage, at least in theory.

I agree.

> How would "values be increased as user expectations of image quality

Not sure if there is a de facto standard for movies and TV shows or
album covers in the HD world. Maybe there is for pirated stuff that we
could look into. I'm not sure there's such a thing for legal content.

> everything that supports cover images right now, but at some point in

So far it's a grey area. I'm not sure this kind of recommendation
should be in the Matroska RFC. That's more guidelines around what the
specs cover.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Mar 2016 09:45:09 -0500

> strings attached, we're fine.

Any ability to carry arbitrary (potentially executable) attachments will 
get scrutiny from at least the security ADs and the security directorate 
reviewer(s). I agree it's out of scope for Matroska to police those, but 
you will want to at least have language describing the issue, and to 
point out that applications (or OSs or something) need to police them.

Thanks!

Ben.

---

From: Dave Rice <[email-masked]>
Date: Mon, 28 Mar 2016 11:35:02 -0400

> On Mar 28, 2016, at 10:45 AM, Ben Campbell <[email-masked]> wrote:
> 
> Any ability to carry arbitrary (potentially executable) attachments will get scrutiny from at least the security ADs and the security directorate reviewer(s). I agree it's out of scope for Matroska to police those, but you will want to at least have language describing the issue, and to point out that applications (or OSs or something) need to police them.

Presently an attached file in Matroska is only described with a FileName, mimetype, and description. There is no permissions, uid, gid, modification timestamps, etc. So IIUC there no method to clarify if an attached file is executable or not.

Perhaps the specifications should clarify though, if any permissions should be presumed of an attachment. For instance if a parser exports the Attachment back to a file, what defaults should be used for permissions and other file attributes.

Other question, should there be other Elements to track other file attributes? I remember a proposal to use Matroska Attachments similar to tar, but handling of file attributes is lacking to make this feasible.

Dave Rice

---

From: Moritz Bunkus <[email-masked]>
Date: Mon, 28 Mar 2016 17:52:27 +0200

Hey,

> Presently an attached file in Matroska is only described with a
> FileName, mimetype, and description. There is no permissions, uid,
> gid, modification timestamps, etc. So IIUC there no method to clarify
> if an attached file is executable or not.
>
> Perhaps the specifications should clarify though, if any permissions
> should be presumed of an attachment. For instance if a parser exports
> the Attachment back to a file, what defaults should be used for
> permissions and other file attributes.

I don't think that it's our (the spec's) job to specify how local system
security should be managed. This would be a slippery slope. We're not
security experts, and security is one of those fields someone has to be
really knowledgeable to get it right.

I also don't see the point in making any kind of rules from our
side. There are use cases across the whole board regarding system
security: from not using any attachments at all; over keeping them in a
temporary location only accessible to the current user and deleting them
right after playback; to asking the user if she wants to install the
fonts extracted from the attachments into the system's font database. It
should not be up to the specs to make any kind of assumption here.

The specs should mention attachments and the various attack vectors in
any future RFC's security section, of course.

I wouldn't track file attributes either. Let's see what kind of
attributes there are and whether or not it makes sense to include them:

- IDs of owning user/group: completely meaningless outside of origin's
  system/domain
- Names of owning user/group: just as meaningless outside of origin's
  system/domain
- Read-only, read/write: meaningless outside of origin's security zone
- Immutable: dito
- Executable: dangerous and prone to confusion with the MIME type. What
  if an attachment of MIME type text/plain is marked executable? Doesn't
  make sense, now does it? And what about different platforms? An
  attachment of MIME type application/x-dosexec on Linux?

MIME types should be enough for a reader to figure out whether or not an
attachment has any business of being executable on the current platform.

Kind regards,
mosu

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Mon, 28 Mar 2016 20:05:58 +0200

> should not be up to the specs to make any kind of assumption here.

I agree with the two paragraphs above. With the addition of recommending
to handle attachments in a safe way. Without trying to police it in any
way. This has to be up to the system handling Matroska files and
attachments.

For example, Email in itself does not restrict what I do with
attachments, some servers or mail-clients however, do restrict me. The
same could apply to Matroska, in theory I could attach anything to it,
but I have to live with restrictions, which are enforced by software
handling such files.

If someone chooses to parse an attached PDF while also supporting the
full PDF specifications s/he has to be sure to understand the
implications, like that PDF flies can contain flash.

> any future RFC's security section, of course.

Indeed that should be the case.

>   attachment of MIME type application/x-dosexec on Linux?

I also see very little, if any, gain in transporting those information
inside a Matroska file.

It might be interesting to have a read-only flag for an attachment to
signal that it shouldn't be altered. But again, I think it shouldn't be
policed.

I got told, that on Linux binaries (or files in general) saved with
Thunderbird don't have the executable flag. The user or some application
would have to do that. Might be worth to recommend such a behavior,
again without policing it. On Windows there is no execution flag anyway.

> attachment has any business of being executable on the current platform.

I agree that a reader should use the MIME type as an indicator to what
the file is supposed to be. It should not blindly trust that the MIME
type is correct. It is up to the software handling the attachment to
ensure that it is what it is supposed to be.

Not like reading an attachment that is supposed to be a font, but is in
fact some executable that then gets executed.

Out of my head I can't see why a reader would execute an attached
executable, while I still see a reason to attach an executable.
Currently, I hope any reader would not execute something without having
a very good reason for it (I currently can't think of one), because I
think no one would implement it in such a way. (I'm sure someone will
prove me wrong, at some point in time.)

You can have recommendations on how to handle attachments, but I don't
see a way to enforce some kind of policy.

Best regards,
Sebastian

---

From: Michael Niedermayer <[email-masked]>
Date: Mon, 28 Mar 2016 21:36:17 +0200

> any future RFC's security section, of course.

The specs could list a "core" set of attachment mime types that
are recommanded to be supported.
That would make it easier for applications generating files to know
what can be put in that is likely going to be interpreted and
applications on the receiving end to know what minium set makes sense
to support. (or looking at it from the other side what mime types
can be ignored to minimize the attack surface without impacting the
majority of uses)

[...]

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

---

From: Dave Rice <[email-masked]>
Date: Mon, 28 Mar 2016 17:25:53 -0400

> On Mar 28, 2016, at 3:36 PM, Michael Niedermayer <[email-masked]> wrote:
> 

+1

> can be ignored to minimize the attack surface without impacting the

For a whitelist we could use:
text/*
image/*
video/*
application/pdf
application/xml
?

I've had trouble locating existing Matroska files with Attachments. The Internet Archive has ~90,000 matroska files and has been my largest sample set, but none of them use attachments. The primary examples of attachments I've seen come from samples.ffmpeg.org. Are there any other online collections of matroska files that may include attachments that I could analyze?
Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Tue, 29 Mar 2016 11:21:39 -0400

> On Mar 28, 2016, at 3:36 PM, Michael Niedermayer <[email-masked] <mailto:[email-masked]>> wrote:
> 

+1

others?

I've had trouble locating existing Matroska files with Attachments. The Internet Archive has ~90,000 matroska files and has been my largest sample set, but none of them use attachments. The primary examples of attachments I've seen come from samples.ffmpeg.org <http://samples.ffmpeg.org/>. Are there any other online collections of matroska files that may include attachments that I could analyze?
Dave Rice