Identifier for external interpretation

[danja]

Clearly, as 'manifest URL' is defined, these files are expected to appear on the Web. But there doesn't appear to be an unambiguous means of interpreting their contents without additional out-of-band information.

My apologies if this has been discussed before. I'm fairly ignorant around these parts, which is why I happened to be exploring site manifest specs for a project. Thought I should airdrop this as I fly by.

So, I haven't read the WebArch doc in a long while, but I'm betting it says something like it SHOULD be possible to see what kind of representation something is with the HTTP stack alone. If required the follow-your-nose link protocol can provide more.

Here, there is a media type that would fulfil this role (application/manifest+json). This will typically require the filename to have the .webmanifest extension and the server knowing the association. However, .json is allowed as an option, and I suspect in practice that would be the first choice for most developers (not least because IDEs often key off the extension for syntax highlighting). It's easy to imagine non-compliance even if the manifest were mandated in the spec.

If this was starting from scratch, I'd have strongly recommended using a JSON-LD compatible structure (and media type). Looks a bit too late for that.

I've only checked using eyes and (unreliable) memory, but I don't think this structure will yield to the common JSON-LD tweak of dropping in an "@context":"http://example.org/spec" attribute so the whole lot can be fed to a standard JSON-LD parser. (May be worth checking.)

Right now I can't think of anything better than inserting a namespace-like URL attribute. At least there'll be something unambiguous there for anything that bothers to look inside. An alternative would be to put something in /.well-known/ but that feels a bit convoluted (unless there's something already defined that could be piggy-backed).

But I do reckon this is quite important. If a straightforward disambiguation mechanism can be found, aside from (hand waves) Web best practices, there are fairly immediate practical use cases. Discovery/search should be easier, automatic creation of directory/marketplace listings would be simplified, the data would also be available for immediate use by generic Linked Data tools (akin to DOAP, the RDF Description of a Project spec).

Anyway, I'll leave that with you. I'd better continue today's flight.

[dmurph]

The struggle here is spoofing - the source of trust / security guarantee is actually the html link attribute that says "yes, this manifest applies to me, it is trusted on my origin". Because people use CDNs to host their manifest (and thus it is cross-origin), it's not safe to just simply trust a manifest, as it can describe a cross-origin site. If you hosted a manifest for "turbotax" on your origin, we probably wouldn't want to be able to only look at that and say "yep, I trust this, this can install TurboTax and have the start_url be turbotax.com" etc.

Even if the manifest is same-origin, often they are versioned and it also seems weird to allow any of those versions to be trusted... maybe not as bad though.

We do have a unique identifier spec'd now, the manifest id. You can uniquely identify a manifest-backed entity now (e.g.usually an installed web app) now using this.

[danja]

I have to confess spoofing issues hadn't crossed my mind at all.

I bet there's overlap, but we're at cross purposes. What I'm trying to highlight is that, as defined in the current draft, as far as the Web is concerned, many manifests might as well be a random jumble of bytes. Unnecessarily so, and losing potential utility.

I'm not thinking in terms of a specific manifest associated with a specific app (though I am now starting to imagine the spoofing angle, yeah, I see that could easily get ugly). Rather what every manifest looks like.

Say my browser GETs a HTML page and in there is a link to style.css. Browser GETs style.css, interprets according to CSS definitions, applies whatever styling it's declared. How does it know what to do : the foundation authority is an IANA registered special string, "text/css" delivered in a HTTP header. But if the header said "image/jpeg", what then? Ok, this is contrived, there a loads of workarounds built into browsers.

webmanifest has "application/manifest+json", that's sound. But this file might legitimately arrive as "application/json". All that says is that it conforms to a particular syntax that can represent a Javascript object (and similar things). Yet it contains information that's clearly defined in a (draft) specification. It has fields like id, name, description. There's no additional security risk, spoofing or otherwise, in making that information more accessible to a client. If there's a lie in that information, it'll look the same to any agent that interprets the text according to the spec. If, say, a layer of signing/encryption is added, it may take some handshaking of keys or whatever, but any agent with appropriate credentials can potentially see it.

It's a painful thing to bring up in this day and age, but something that does what XML namespaces did (still do?) well. There's a base format that a generic parser can run through. But the naming of the elements is qualified by something with a URI. Ideally a dereferenceable URL that HTTP can go and look at.

In the same way (not great to begin with and I've not looked at it in year) https://purl.org/stuff/pets defines a way of describing animal friends in RDF. A major reason is to tie definitions to human concepts, but there are more immediate uses - through a link to WordNet, the French word for 'dog' is available. (Well, would be if danbri got someone in to fix that server).

So "name" in the context of webmanifest has a specific meaning, defined at https://www.w3.org/TR/appmanifest/#name-member But if someone (or their app) finds a webmanifest in the wild, however could they know that..?

Right now, as far as I can tell, unless an agent is told ahead of time "this is a webmanifest", it's effectively meaningless. A JSON interpretation will give you a pair "name": "turbotax", but it conveys no more information than "a string" : "another string". Meanwhile there's a document that's had 10 years of development that can tell you exactly what it means, if you only you (/your software agent) knew where to look. A day after bringing it up I still haven't checked the JSON-LD docs to see if that approach might work.

I believe these are strong reasons to address this point somehow. Rejection on pragmatic grounds is fair enough, but please after a little consideration.

[benfrancis]

I wanted web app manifests to be useful as standalone resources too (e.g for crawling, remote installation, app stores, all kinds of things), but I'm afraid that ship has long-since sailed.

The parsing algorithm only works if a user agent follows a link from an HTML page, and the parser knows both the manifest URL and the document URL of the page it was linked from. Therefore in practice the user agent doesn't need a .webmanifest file extension, Content-type HTTP header or a JSON-LD @context to know that the file is a manifest. It knows it's a manifest because it was linked to from a web page using a manifest link relation. At that point, if it can be parsed as a manifest then it's a manifest.

There's a long history for why this is the case, and at this point I'm afraid I don't think it can be fixed without backwards incompatible changes, especially for Chromium based browsers. Perhaps in a version 2!

[marcoscaceres]

so the whole lot can be fed to a standard JSON-LD parser.

While it's true that JSON-LD has its advantages, as far as I'm aware, current browsers don't support JSON-LD natively. It's an interesting idea, but for it to be feasible, browser support for JSON-LD would need to be considered and possibly implemented.

Discovery/search should be easier, automatic creation of directory/marketplace listings would be simplified, the data would also be available for immediate use by generic Linked Data tools (akin to DOAP, the RDF Description of a Project spec).

You raise some good points about the potential benefits of JSON-LD. However, in our past discussions and experiments (referenced in issues #266 and #316), we found that JSON-LD introduced some complexities without significantly enhancing our current format's capabilities for these purposes. It's something we can certainly revisit if new information or approaches emerge.

But if the header said "image/jpeg", what then?

In that case, the manifest would be considered either rejected or missing, in line with the manifest link relationship defined in the HTML specification. This approach helps maintain consistency and clarity in processing these manifests.

@benfrancis wrote:

It knows it's a manifest because it was linked to from a web page using a manifest link relation.

Yes, exactly! The manifest link relation in the web page helps eliminate any ambiguity and ensures the manifest is recognized correctly.

Closing as answered.