Remixing Content

[lrosenthol]

@HadrienGardeur wrote on #6

Also, I'd like to have the ability to remix content on the Web. If I have zero write-access to the content that I'd like to remix within a Web Publication, there's no way I'll be able to include such a link in HTML or HTTP.

Remixing isn't one of the original use cases (though collation/combining was). But assuming we do want to address it, it's going to be a huge set of hurdles to cross with respect to security and other considerations. And that's just in the WP world - PWP just ups the ante...

[HadrienGardeur]

Can you point specific issues regarding security?

If I simply render each resource in a Web Publication in a sandboxed iframe or a separate webview, and simply provide a mean to move to the next/previous resource, what would be the threat for instance?

[lrosenthol]

If I simply render each resource in a Web Publication in a sandboxed iframe or a separate webview, and simply provide a mean to move to the next/previous resource, what would be the threat for instance?

You could do that - but that's not actually remixing (at least in my definition). For example, that particular piece of the web publication wouldn't look or act like the rest of the publication. In other words, if the rest of the publication has chosen to use MyFavoriteWebFont for display but this "linked" page used YourFavoriteWebFont - it would be clear they came from different places.

But back to security - what happens when the user clicks on a link in that iframe/view? Do you keep it in the same frame/view or move to another one? What if it uses a "target='_blank'", what does that mean in this context?

[HadrienGardeur]

You could do that - but that's not actually remixing (at least in my definition). For example, that particular piece of the web publication wouldn't look or act like the rest of the publication. In other words, if the rest of the publication has chosen to use MyFavoriteWebFont for display but this "linked" page used YourFavoriteWebFont - it would be clear they came from different places.

Which IMO is fine and could still be useful.

It should also be possible for someone to create a manifest for a publication if it doesn't have one. For example I could create a manifest for http://poignant.guide/

But back to security - what happens when the user clicks on a link in that iframe/view? Do you keep it in the same frame/view or move to another one? What if it uses a "target='_blank'", what does that mean in this context?

That's up to the minimal UA and our security policy to decide.

In the mobile version of Readium-2, we don't re-use webviews, so clicking on a link would open a new webview but the behavior might be slightly different if the new resource is part of the publication (remain in app, also preload the previous and next resource in the linear reading order) or not (open Chrome or Safari).

[dauwhe]

The privacy and copyright issues boggle the mind. The web works because of links—I can link to your content. But I can't take your content wholesale without permission. The white paper says this pretty clearly, I think.

A Web Publication is not just a collection of links— the act of publishing involves obtaining resources and organizing them into a publication

[lrosenthol]

On Tue, Jul 11, 2017 at 10:47 PM, Dave Cramer ***@***.***> wrote: The privacy and copyright issues boggle the mind.

Yeah, I was ignoring that piece. Remember, there is a LOT of content on the web (and published in general) that would allow it...

The web works because of links—I can link to your content.

Sort of. To be pedantic, you can link to pieces of content that I have broken up in chunks that are identifiable using current OWP mechanisms. (you can't link to an arbitrary paragraph or table or list item).

[HadrienGardeur]

A manifest is a collection of links.

I find it hilarious that in one case (links in a manifest), you raise the issue about privacy and copyright, while on the other hand you say that links are the very foundation of the Web.

[dauwhe]

I'm happy to tell someone my address, but that doesn't mean they can have my house :)

[HadrienGardeur]

Sorry but this is not an analogy that works.

All that the manifest does is provide the address (URL). Re-hosting resources from a publication raises copyright issues, but linking doesn't (no matter how you link).

[dauwhe]

All that the manifest does is provide the address (URL). Re-hosting resources from a publication raises copyright issues, but linking doesn't (no matter how you link).

How would rendering such a web publication work? Say you create manifest.json, which lives at hadrien.com. The only spine item is dave.com/story/index.html. A reader goes to hadrien.com/story/manifest.json—sending a GET request to your server. What does your server return? Would script create an iframe in a document on hadrien.com, with the source set to dave.com? Would such a WP be possible if dave.com has X-Frame-Options set to deny or sameorigin?

Would this be possible for PWP as well as WP?

[HadrienGardeur]

Let's use Readium-2 as an example:

• first of all, the UA needs to discover the WP. This could be using the URL of the manifest directly in an OPDS feed, or it could be using discovery on a separate page on hadrien.com.
• once it knows the URL to the manifest (hadrien.com/story/manifest.json), it'll do a GET request to obtain it
• now the UA knows all the info that it needs about the publication
• since the publication contains a single resource in its spine, it'll open a single webview that will display dave.com/story/index.html

Would script create an iframe in a document on hadrien.com, with the source set to dave.com? Would such a WP be possible if dave.com has X-Frame-Options set to deny or sameorigin?

I think you're confusing the Web Publication with its User Agent.

Why would I open an iframe on hadrien.com if I'm providing a Web Publication?

[llemeurfr]

I'm happy to tell someone my address, but that doesn't mean they can have my house :)

This issue will appear when we talk about packaging -> PWP. It is the step at which content is "taken".
What can happen with a WP manifest containing a free set of links are especially 401 (unauthorized) or 404 http errors (+ all 4xx and 5xx errors).

The issue which can be discussed is therefore: should we allow the creation of Web Publications that won't be packageable (for copyright issues)? If the answer is yes, I think that considering a WP manifest as a enhanced linkbase is ok. If the answer is no, this is another matter.

So yes or no?

[HadrienGardeur]

@llemeurfr I don't think that handling HTTP errors has anything to do specifically with remixing content. This is something that we'll need to deal with for any WP.

I'm not sure what you mean by the way by copyright issues. As I've said before, linking to resources on the Web is not a copyright issue, no matter how we link. I don't think that using a UA to cache for offline reading or package a publication would be a copyright issue either.

If that was the case, services like Pocket or Instapaper would have major copyright issues, but that's not the case.

[dauwhe]

I don't think that using a UA to cache for offline reading or package a publication would be a copyright issue either.

If that was the case, services like Pocket or Instapaper would have major copyright issues, but that's not the case.

Pocket and Instapaper are for personal use, not for publishing.

[HadrienGardeur]

What's the difference? As long as you don't package and host yourself the package, it's exactly the same thing:

• bunch of links
• that a user can cache or package for personal use

[JayPanoz]

Which IMO is fine and could still be useful.

Actually Have a use case for this: one publisher wanted to have one ad at the end of the book, to promote their newest publications. Consequently, they wanted to update the ad on a regular basis.

So yeah, it could be useful to them and they would probably judge important it is cached for offline reading. Needless to say putting and updating the ad in every publication is unrealistic.

[llemeurfr]

Actually have a use case for this: one publisher wanted to have one ad at the end of the book, to promote their newest publications. Consequently, they wanted to update the ad on a regular basis.

This is a very good use-case, where a document in the publication (a primary resource) is shared between a large number of publications and often updated. Such a document will not list (via html links) all publications it belongs to because it won't be used for discovery (and listing 1000+ publications would be a loss of time).
This use-case must IMO be added to the list maintained by the WG.

[wareid]

As discussed in the meeting on Feb 4 2019, we will close this issue as it is untouched. If there is interest in this, please open a new issue with consideration for the spec.