opened
lgarron
username_0
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](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy).

@username_6 is [currently implementing](https://code.google.com/p/chromium/issues/detail?id=336894&q=suborigins&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified) 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
Implement per-page suborigins in the gateway
issue
created
stevearm
username_1
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).
comment
created
mappum
username_2
@username_1 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).
comment
created
stevearm
username_1
I agree, and there's been discussion on [faq#32](https://github.com/ipfs/faq/issues/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.
comment
created
lgierth
username_3
I ordered ipns.name for exactly this use case just a few days ago :)
comment
created
lgierth
username_3
While I think it makes sense for IPNS names, I'm not convinced it does for arbitrary /ipfs hashes.
comment
created
edrex
username_4
@username_2, what do you think of using https://github.com/neocities/hshca/ for the domain component?
comment
created
edrex
username_4
@username_3 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.
comment
created
edrex
username_4
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? @username_8?
comment
created
harlantwood
username_5
+1 for doing this for IPNS names. 
+1 for using hshca.
comment
created
edrex
username_4
ok, let's not start +1ing up this issue.
comment
created
metromoxie
username_6
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.
comment
created
whyrusleeping
username_7
Per page suborigins would be great. Are they implemented in major browsers yet?
comment
created
jbenet
username_8
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
comment
created
lgierth
username_3
@username_8 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.
comment
created
mitar
username_9
Yes, it is really going into odd directions. :-)

I think only Chrome has implementation with a runtime command line switch.
comment
created
metromoxie
username_6
@username_8, 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.
comment
created
lgierth
username_3
@username_6 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
comment
created
lgierth
username_3
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](https://github.com/neocities/hshca) which we'll implement in go-ipfs.
comment
closed
lgierth
username_3
issue
created
brettz9
username_10
Is there tracking for HSHCA support?
comment
created
whyrusleeping
username_7
Unsure, cc @kyledrake
comment