Implement per-page suborigins in the gateway

[lgarron]

Right now, all pages/web apps served from the same server have access to all each other's saved state of the same-origin policy.

@metromoxie is currently implementing a first version of per-page suborigins in Chrome, which should let the server isolate web app nodes from each other (by sending a unique string in the header for each one). http://www.chromium.org/developers/design-documents/per-page-suborigins

[stevearm]

Is there a reason why we can't implement per-root dns subdomains (<hash>.gateway.ipfs.io)? If we can, wouldn't they do everything that per-page suborigins would, while providing broader support (all browsers currently enforce SOP based on dns subdomains while suborigins are still experimentally supported).

[mappum]

@stevearm I've been thinking about this for a while, and I believe it's a good choice. The path ordering is not ideal (ipfs.io/ipfs/HASH makes more sense), but that's a secondary issue.

A very cool use case that could be made possible is SOP for IPNS names, which would allow applications that are published on IPNS to store data that will be accessible across updates. This could have a path such as <hash>.ipns.ipfs.io or <hash>.ipns.name.

This even lets applications easily create new SOP scopes at runtime by creating new IPFS objects. For instance, an application could create multiple Bitcoin wallets that each store their own private keys and manage access capabilities. Then, even as the application is updated via IPNS, the new untrusted code won't be able to change its access to the private keys (since they are on a different domain).

[stevearm]

I agree, and there's been discussion on faq#32 about this sub-domain solution which is pretty relevant.

I think per-page suborigins make sense in cases where one can't use subdomains, but if we are free to use multiple dns subdomains I think we should. We can reap the benefit of universal SOP browser enforcement instead of working towards using a brand-new feature that won't give us additional functionality.

[ghost]

A very cool use case that could be made possible is SOP for IPNS names, which would allow applications that are published on IPNS to store data that will be accessible across updates. This could have a path such as .ipns.ipfs.io or .ipns.name.

I ordered ipns.name for exactly this use case just a few days ago :)

[ghost]

While I think it makes sense for IPNS names, I'm not convinced it does for arbitrary /ipfs hashes.

[edrex]

@mappum, what do you think of using https://github.com/neocities/hshca/ for the domain component?

[edrex]

@lgierth you may be right. The only use I can think of would be to enable immutable applications, which are guaranteed not to be changed by the publisher. I don't know if people will find that useful. But generally I think people will publish and use apps under an IPNS node.

[edrex]

btw, +1 for going forward with sub domains using hshca for now. Anyway the gateway is a transitional technology, and maybe we should be thinking about the end game when clients understand IPFS. How will application security scopes work then?

[harlantwood]

+1 for doing this for IPNS names.
+1 for using hshca.

[joelweinberger]

FWIW, if you can do separate, unique subdomains for your purposes, it's probably a superior option for all of the reasons you've listed. Suborigins (which aren't even complete yet) are most useful for a world where that's not possible or reasonable.

For example, imagine you are trying to separate two legacy applications which, perhaps for SEO reasons, need to live on the same top level domain. Then Suborigins would be useful because it would give you origin separation while still living on the same host.

Another reason you might prefer Suborigins would be if you needed direct access to some subset of shared resources. For legacy purposes, we're carving out a few exceptions where you can (unsafely) allow for the sharing of some origin-specific resources between an origin and a suborigin, such as cookies.

[whyrusleeping]

Per page suborigins would be great. Are they implemented in major browsers yet?

[jbenet]

Not yet and it looks like the spec is going in odd directions. We need to
participate in that discussion to make sure it goes well and supporting our
use cases
On Tue, Aug 23, 2016 at 17:55 Jeromy Johnson notifications@github.com
wrote:

Per page suborigins would be great. Are they implemented in major browsers
yet?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#651 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoXI0Qb5VmTrOJ6hG5QTxFsWaGxF0ks5qi2xdgaJpZM4DW04N
.

[ghost]

@jbenet you were already saying in Lisbon that right now is the time to articulate our use case and feedback to the suborigins working group. I can go draft something next week-ish.

[mitar]

Yes, it is really going into odd directions. :-)

I think only Chrome has implementation with a runtime command line switch.

[joelweinberger]

@jbenet, can you clarify what direction you think is odd about Suborigins? I would certainly prefer for that not to be the outcome :-) While we can't get every feature in v1, at the very least I want to make sure we know of developers needs so we don't build something that is unusable.

[ghost]

@metromoxie hey, I had a look at the current editor's draft and I think it still fits our use case, see my comments in #3209

[ghost]

Closing this one -- the gateway has been setting the Suborigin for ages, and we're ironing out a few remaining issues in #3209. DNS names like <hash>.ipns.name can be achieved using HSHCA which we'll implement in go-ipfs.

[brettz9]

Is there tracking for HSHCA support?

[whyrusleeping]

Unsure, cc @kyledrake