-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
IPFS origins report wrong document.location.origin #13303
Comments
i think it's fine to have the apparent origin be ipfs:// as long as domain isolation is preserved (#12367). ex: ipfs://foo and ipfs://bar should be treated as third parties according to the same rules as http://a.com and http://b.com. re: what web features are accessible to an ipfs:// page, options are:
i think 2 makes the most sense since IPFS documents are served locally. |
I think we need |
if the origin changes, href, protocol, host, and hostname (possibly other properties) should change accordingly. i think host/hostname would be the CID, href should be the full URL, and protocol should be IPFS if we decide to do this. i'm somewhat concerned that this will be need to be a bigger change for consistency. for instance in https://docs.google.com/document/d/156bzOF8qkieyouqnhIQzwJsCxtsTNtyVcOiClSEgeU0/edit?disco=AAAAHwJ3OFc @lidel mentioned that this change might not have much practical value, in which case i think we should hold off on it unless it's causing major webcompat or developer issues. |
You can see the expected result using the URL object:
Chrome/Brave notably says the |
That’s the current state, though. There are all sorts of places where the double origin may cause issues and confusion for developers:
|
That's not true because of the work done here: We're looking into a different way of handling this to help address other points though. |
I'm not sure this is an issue we want to fix. The problem here that we also ran into in another issue is that hostnames are not case sensitive, but CID is. Right now ipfs/ipns are effectively treated like file urls and that preserves the case. I was originally in favor of making a change like this for other reasons, but I'm no longer sure it's a good idea. There are too many different places where the case is handled for host/origin and I don't see a safe and reliable way to make sure it's consistent across the codebase. |
I guess to be completely accurate DNS names are case insensitive, but in chromium that has translated to all hostnames being converted to lowercase and but there are multiple places this happens and not all of them provide access to the scheme to differentiate between ipfs and http/https |
and really since ipfs is "InterPlanetary File System", maybe it makes more sense to treat these like file urls except maybe for dnslink. It would have been much simpler if dnslink used a different scheme... |
having said all of that, |
Some notes that may be useful when it is time to address this:
|
If every cid can be converted to case insensitive encoding then this would be more viable. @lidel I want to verify that you're saying CIDv1 is already case insensitive? |
Yes. One of the primary purposes of CIDv1, and the reason there is an effort to deprecate CIDv0 in favor of CIDv1, is specifically that it is "all lowercase" so it can be used as a subdomain rather than being constrained to a path (which enables subdomain isolation between sites retrieved from a gateway). |
Yes, every CID can be turned into CIDv1 in base32 or base36. Technically, one can encode CIDv1 using different multibase, such as case-sensitive base64: $ ipfs cid format -b base64url bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
uAXASIMPEcz7Ir_0Gz56f9Q_8a80uyFphcABLtwlmnDHelDka But on the web, the default convention is to use base32 for /ipfs/ and base36 for /ipns/. This ensures CID is case-insensitive but also short enough to fit in a single DNS label (which has max length limit of 63), allowing use on subdomain gateways. |
Description
Brave returns an unexpected
document location.origin
when browsing on pages through theipfs:
andipns:
protocol schemes. Other properties in the location object (e.g. .protocol) are effected too.Steps to Reproduce
ipfs://hashhash
oripns://hashhash
document.location.origin
Expected result:
The function should return
ipfs://hashhash
.Actual result:
It returns
http://hashhash.ipfs.localhost:12345/
Reproduces how often:
Every time.
Brave version (brave://version info)
1.19.67
Version/Channel Information:
Beta only feature.
Miscellaneous Information:
This bug makes it more difficult to develop mixed HTTPS/IPFS websites as its more difficult to determine correctly what protocol scheme is being used. This might have unexpected security issues. The Chromium Extension API return the expected origin. However, some extensions get very confused when the tab.url and its document.location don’t match.
The text was updated successfully, but these errors were encountered: