Suborigins

[lidel]

Suborigins are WIP standard that – if implemented by browser vendors – could provide a way to isolate CID-specific paths into their own Origins.

It is an alternative way to solve the Problem of Inability to Control How Origin Is Calculated in Web Browsers (other one being CID-in-subdomain and programmable protocol handler API).

This is a meta-issue to track related work and provide a quick context for newcomers

References

• W3C Suborigins Working Group Repo: https://github.com/w3c/webappsec-suborigins
  • Editor's draft: https://w3c.github.io/webappsec-suborigins/
• ipfs/specs: Feedback for the Suborigin working group
• ipfs/go-ipfs: Ongoing discussion about suborigin header format and gateway
• Support in Web Browsers
  • Firefox
    • https://bugzilla.mozilla.org/show_bug.cgi?id=1231225
    • https://bugzilla.mozilla.org/show_bug.cgi?id=1391251
  • Chromium
    • https://bugs.chromium.org/p/chromium/issues/detail?id=555117
    • https://bugs.chromium.org/p/chromium/issues/detail?id=580320

Notable Events

• 2014-11 public standards discussion announced @ lists.w3.org
• 2015-01 ipfs/go-ipfs Implement per-page suborigins in the gateway
• 2016-09 w3c/webappsec-suborigins: not allowed to start with number/can only start with letters
• 2016-12 ipfs/go-ipfs: gateway: disable Suborigins as it conflicts the spec
• 2017-09 Suborigins mozilla/standards-positions#31 (opened with a note about outstanding issues)
• 2019-11 Suborigins mozilla/standards-positions#31 (comment) (closed due to no work)
• ❓

[brettz9]

This is excellent to see the addressing of suborigins to allow content-specific storage...

Although the following suggestion goes a bit in the opposite direction (to enable site-independent storage accessible to any origin upon but upon user permission), I think it may be reasonable to consider the two use cases together, especially given that the decentralized nature of IPFS seems to cry out for a means of common site-agnostic storage (albeit one which is of course subject to user permission).

I'd like to request that provision be made--whether at the IPFS level or more ideally I think at the browser level (if our voice can influence the browsers)--to create a form of site agnostic origin-independent storage (whether for localStorage, indexedDB, cookies, etc.) which is deliberately accessible to any origin or suborigin upon user consent.

Just as one can freely choose any local application to handle any given data file, one should be able to choose any website to handle data created by another site. Moreover, no particular site, including the original creator of the origin-independent data would be the gate-keeper, but it would instead be accessible to or modifiable by any origin upon user permission. We could call this proposal tentatively, COIS (Common, Origin-Independent Storage).

COIS should obviously occur at the user's discretion rather than the current situation where any webpage served from localhost can access and even modify the same localhost storage of another localhost web app without needing user permission.

Automatically using, or at least offering the option of using COIS, would be in the interest of many sites, as their storing the user's data in an open, site-agnostic format would assure their users that their data would not be inaccessible or require exporting from a remote site, etc., if their site ever went belly-up, or if the user just happened to want to switch at will between different applications to manage their own data (without the need of intermediate steps of exporting and importing with attendant inconvenience and synchronization-between-sites problems).

I would thus suggest considering enabling ideally both of the following options for users:

1. The user could allow any website to request permission to access COIS (ideally even granular to a particular subnamespace of data within COIS and granular as to whether an origin or suborigin is seeking to gain readonly or readwrite access). If browsers don't provide such an API, then IPFS could still conceivably recommend a particular origin (or suborigin) which hosted code with an API to gain access to that (shared) origin's storage.

2. The user has the browser prevent websites from even being able to ask permission for access to COIS but the user can whitelist particular origins (or suborigins) in local preferences to enable such sites to access COIS. If browsers will not implement then IPFS could perhaps, through a browser add-on, have its own preferences that would allow COIS origin/suborigin whitelisting.

What do you think?

[lidel]

@brettz9 I am afraid something like COIS would require a lot of investment on the browser vendor part. Note that browsers would have to implement entirely new UX, design new security model around it, etc. While I see some exciting use cases that would arise from such shared storage space, I'd say it is unlikely we will see vendors adding it "natively" any time soon. In current state of things a simple and isolated storage would be more useful for developers than a complex and shared one, so "niche" things like COIS would have lower priority.

We are aware that Suborigins are only a stop gap, but relatively cheap to implement by vendors because it relies on existing Origin-based security model.

FYSA we plan to ask vendors to provide means of controlling how Origin is calculated, probably as a new WebExtension API (ipfs/ipfs-companion#343). For more context, see Problem 2 in Roadblocks for IPFS in Browser Extension.

TL;DR
If we are able to control how Origin is calculated, we are able to "merge" Origins for IPFS resources across different public gateways, giving users the same context no matter which GW is used.
Note that such API would also provide us with tooling for creating something very like COIS, eg. some kind of URI hint (/?cois/) would trigger custom protocol to always return the same Origin, effectively creating opt-in COIS context shared between different websites .

[lidel]

As noted in ipfs/kubo#3209 (comment) Suborigin value must start with alpha:

LOWERALPHA *( LOWERALPHA / DIGIT )

Revisiting this in context of move to CIDv1 Base32 (https://github.com/ipfs/ipfs/issues/337) we probably should aim at normalizing to cidv1b32:

• Location: https://ipfs.io/ipfs/bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy
• Prefix (ensures LOWERALPHA requirement is fulfilled): ipfs000
• Suborigin: ipfs000bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy

This is only for /ipfs/, as we don't have case-insensitive solution for /ipns/ yet (ipfs/kubo#5287).