New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement per-page suborigins in the gateway #651

Closed
lgarron opened this Issue Jan 25, 2015 · 19 comments

Comments

Projects
None yet
@lgarron
Contributor

lgarron commented Jan 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stevearm

stevearm Dec 19, 2015

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

stevearm commented Dec 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mappum

mappum Dec 19, 2015

Contributor

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

Contributor

mappum commented Dec 19, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@stevearm

stevearm Dec 19, 2015

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.

stevearm commented Dec 19, 2015

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.

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Dec 20, 2015

Member

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

Member

lgierth commented Dec 20, 2015

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

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Dec 20, 2015

Member

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

Member

lgierth commented Dec 20, 2015

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

@edrex

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Dec 20, 2015

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

edrex commented Dec 20, 2015

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

@edrex

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Dec 20, 2015

@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 commented Dec 20, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Dec 20, 2015

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?

edrex commented Dec 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@harlantwood

harlantwood Dec 20, 2015

Contributor

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

Contributor

harlantwood commented Dec 20, 2015

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

@metromoxie

This comment has been minimized.

Show comment
Hide comment
@metromoxie

metromoxie Dec 20, 2015

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.

metromoxie commented Dec 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Aug 23, 2016

Member

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

Member

whyrusleeping commented Aug 23, 2016

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

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Aug 23, 2016

Member

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
.

Member

jbenet commented Aug 23, 2016

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
.

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Aug 23, 2016

Member

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

Member

lgierth commented Aug 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Aug 24, 2016

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

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

mitar commented Aug 24, 2016

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

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

@metromoxie

This comment has been minimized.

Show comment
Hide comment
@metromoxie

metromoxie Aug 26, 2016

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

metromoxie commented Aug 26, 2016

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

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Sep 21, 2016

Member

@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

Member

lgierth commented Sep 21, 2016

@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

@lgierth

This comment has been minimized.

Show comment
Hide comment
@lgierth

lgierth Sep 21, 2016

Member

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.

Member

lgierth commented Sep 21, 2016

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.

@lgierth lgierth closed this Sep 21, 2016

@lidel lidel referenced this issue Jan 2, 2018

Open

Suborigins #66

@brettz9

This comment has been minimized.

Show comment
Hide comment
@brettz9

brettz9 Jan 3, 2018

Is there tracking for HSHCA support?

brettz9 commented Jan 3, 2018

Is there tracking for HSHCA support?

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping
Member

whyrusleeping commented Jan 3, 2018

Unsure, cc @kyledrake

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment