Skip to content
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

Origin policy for fs: URIs #71

Closed
the8472 opened this issue Feb 11, 2016 · 8 comments
Closed

Origin policy for fs: URIs #71

the8472 opened this issue Feb 11, 2016 · 8 comments
Labels
help wanted Seeking public contribution on this issue kind/discussion Topical discussion; usually not changes to codebase status/blocked/missing-api Blocked by missing API topic/security Work related to security

Comments

@the8472
Copy link
Contributor

the8472 commented Feb 11, 2016

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 lidel added kind/discussion Topical discussion; usually not changes to codebase topic/security Work related to security labels Feb 11, 2016
@lidel
Copy link
Member

lidel commented Feb 11, 2016

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
Copy link
Member

Kubuxu commented Feb 11, 2016

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

@the8472
Copy link
Contributor Author

the8472 commented Feb 12, 2016

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 lidel added the help wanted Seeking public contribution on this issue label Feb 12, 2016
@lidel
Copy link
Member

lidel commented Feb 12, 2016

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

@lidel
Copy link
Member

lidel commented Feb 17, 2016

Quick brain dump or related resources:

@the8472
Copy link
Contributor Author

the8472 commented Feb 17, 2016

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
Copy link
Member

lidel commented Feb 17, 2016

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
Copy link
Member

lidel commented Feb 7, 2017

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

@lidel lidel closed this as completed Feb 7, 2017
@ipfs ipfs locked and limited conversation to collaborators Feb 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Seeking public contribution on this issue kind/discussion Topical discussion; usually not changes to codebase status/blocked/missing-api Blocked by missing API topic/security Work related to security
Projects
None yet
Development

No branches or pull requests

3 participants