Clarify data URLs are not publication resources

[mattgarrish]

This one got me pretty twisted up trying to solve.

There's a second case I thought of where you could technically use a data URL in the manifest: fallback resources. You could encode a CMT image as a data URL for an img element fallback, for example. But do we really want to support this or having a nav doc not in the spine as a data URL? I'm guessing not.

Assuming that's the case, what I've done is try to make clearer that data URLs are not unique from their container resource. They must not be listed in the manifest, but because they have media types separate from their container they are still subject to fallback restrictions.

I've also assumed that we don't care what people do with linked resources, so data URLs are allowed in link elements in the metadata.

Anyway, take a good look at this PR as it's a bit of a convoluted problem.

Fixes #2485

---

Preview | Diff

[rdeltour]

This looks OK to me, pending some (minor) edit suggestions.

Also, if we allow data URLs on linked resources, we may want to change the following (from the link element definition):

The media-type attribute is OPTIONAL when a linked resource is located outside the EPUB container, as more than one media type could be served from the same URL [url]. EPUB creators MUST specify the attribute for all linked resources within the EPUB container

to

The media-type attribute is OPTIONAL when a linked resource is located outside the EPUB container (as more than one media type could be served from the same URL [url]), or when the resource is encoded as a data URL (in the href attribute). EPUB creators MUST otherwise specify the attribute for all linked resources located within the EPUB container.

[mattgarrish]

we may want to change the following (from the link element definition):

Ya, that's fine with me. I just reworked it into a bullet list as there's a lot going on in the sentence.

Since linked resources are kind of a niche anyway, allowing data URLs for them doesn't bother me. But if we don't want them at all in the package document I can go that way, too.

[mattgarrish]

Should we ban data URLs in link elements and be done with them in the package document? Given the problematic security of data URLs, and the limited uses of links, it seems like a prudent thing to do.

[rdeltour]

Should we ban data URLs in link elements and be done with them in the package document?

Yeah, no strong opinion here, but I'm pretty confident no one will complain if we ban them.

[iherman]

Should we ban data URLs in link elements and be done with them in the package document? Given the problematic security of data URLs, and the limited uses of links, it seems like a prudent thing to do.

Same as @rdeltour.

[mattgarrish]

I've updated the PR to disallow data urls in the package document, but it's meant some rewriting of the data URLs section.

It didn't make sense to lead into the restriction in the package document by talking about publication resources, so I added the restriction to the list of scenarios that can result in insecure rendering. Instead of saying these will result in top-level content documents/browsing context, I shifted it to "can result" to justify having the link element in there. It's a bit of an outlier, as we don't know how a reading system will present a link.

I then shifted the text about data URLs not being unique publication resources down to the paragraph about their still having their own media types so being subject to fallback requirements.

Otherwise, I just undid the bits that were dealing with the link element - the one note about allowing data urls and the paragraph about linked resources not needing a media-type attribute when expressed as data urls.

[mattgarrish]

As this has been open for a week now, I'm going to merge.