Origin policy for fs: URIs

[the8472]

According to mozilla bug 1247529#c16 it should be possible to give individual uris custom origins, similar to chrome's suborigins.

The question is what the origin policy should be for various kinds of paths

[lidel]

I don't see a lot of options here.
The closes thing to an origin would probably be the first segment after /ip(f|n)s/ (hash or fqdn).

As for implementation.. aren't you afraid when you read things like:

Note that these APIs aren't guaranteed to stay stable.

Remember that we will need to stop using XUL/XPCOM soon.
I strongly believe our effort should go into designing/requesting any missing WebExtensions APIs, as it is the only thing that will reliably work in future.

For me, implementing things that are already marked as deprecated is really frustrating 😢 but if you produce PR I won't say no.

[Kubuxu]

I also agree on first segment after /ip(f|n)s/.
Also we should insert our own localStorage on per origin basis.

[the8472]

aren't you afraid when you read things like:

Note that these APIs aren't guaranteed to stay stable.

It should be easy enough to isolate this into a separate module and have tests for it. Add CI running against nightly and there would be enough early warning if they break something. And it's not like they aren't breaking stuff every now and then anyway.

I strongly believe our effort should go into designing/requesting any missing WebExtensions APIs, as it is the only thing that will reliably work in future.

I think it's important to demonstrate a current use of such APIs. Also, an alternative plan to beg for APIs will be write your own webextension APIs, allow mozilla to adopt them later

[lidel]

Thanks, it makes more sense to me now ("demonstrating use" is a sound policy).
PR welcome.

[lidel]

Quick brain dump or related resources:

• Suborigins Spec: W3C Editor’s Draft
• go-ipfs gateway already returns HTTP Suborigin header with every response for /ipfs/ resources: core/corehttp/gateway_handler.go#L176.
• Related discussion about Suborigin support in go-ipfs / Chrome
• Firefox did not start implementing it yet 😢 Bug #1231225 - Suborigins namespace mechanism

[the8472]

I think suborigins are useless in this context because they are only sub- in nature. fs:/ URIs have no origin and thus get random UUID origins as per rfc6454

Putting any fixed suborigin under a random top origin won't win us anything, since the combination of both is still random.

[lidel]

Yes, suborigins are a half measure that "works" as long user keeps using the same gateway.

I mentioned it because there will probably be no other option than to use Suborigins under Chrome/Blink. It will be the lowest common denominator and a good reason to model Firefox origin policy to be compatible with Suborigin header (and additionally gateway-agnostic).

If uri-scheme is "file", the implementation MAY return an implementation-defined value.

Cool, so we probably could bend it a bit, apply this to fs: and instead of
(uri-scheme, uri-host, uri-port)
use
(uri-scheme, (ipfs|ipns), (multihash|ipns-name))

..assuming WebExtensions will provide API for this in future (there is no such API at this moment).

[lidel]

This issue is outdated. Closing.
A more broad discussion continues in ipfs/in-web-browsers#6 and ipfs/in-web-browsers#13

Status of Custom Protocols in WebExtension will be tracked in #164