Remixing Content about wpub HOT 17 CLOSED

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?

from wpub.

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?

from wpub.

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).

from wpub.

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

from wpub.

from wpub.

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.

from wpub.

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

from wpub.

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).

from wpub.

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?

from wpub.

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?

from wpub.

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?

from wpub.

@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.

from wpub.

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.

from wpub.

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

from wpub.

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.

from wpub.

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.

from wpub.

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.

from wpub.