Add [gateway.]ipfs.io to public suffix list

[willglynn]

The Public Suffix List is used to determine administrative boundaries – that is, which part of a domain name is shared and which part is not. These boundaries are irregular and often have security implications. For example, a.foo.com should be permitted to set a cookie for foo.com, while a.co.uk should not be permitted to set a cookie for co.uk.

Besides top-level domains, the public suffix list includes a number of private domains that warrant similar treatment:

// ===END ICANN DOMAINS===
// ===BEGIN PRIVATE DOMAINS===
// (Note: these are in alphabetical order by company name)

// Amazon CloudFront : https://aws.amazon.com/cloudfront/
// Submitted by Donavan Miller <…> 2013-03-22
cloudfront.net

// Amazon Elastic Load Balancing : https://aws.amazon.com/elasticloadbalancing/
// Submitted by Scott Vidmar <…> 2013-03-27
elb.amazonaws.com

// Amazon S3 : https://aws.amazon.com/s3/
// Submitted by Eric Kinolik <…> 2015-04-08
s3.amazonaws.com

// DynDNS.com : http://www.dyndns.com/services/dns/dyndns/
dyndns.org

// GitHub, Inc.
// Submitted by Ben Toews <…> 2014-02-06
github.io
githubusercontent.com

// Heroku : https://www.heroku.com/
// Submitted by Tom Maher <…> 2013-05-02
herokuapp.com
herokussl.com

I'm not sure what the desired policy is but something relating to ipfs.io should be listed here. Specifically, I think the resulting rule(s) should at least prevent cookies from being set for gateway.ipfs.io, as well as any subdomains (#81).

[ghost]

I've never even heard of the Public Suffix List to be honest, but it makes sense -- thanks for the suggestion!

We actually want to sandbox every object on ipfs.io and gateway.ipfsio as much as possible. I think we can't even cleanly give a child object access to its parent's cookies/localstorage/etc.

For (sub)domains which don't expose /ipfs or /ipns, it'll be a bit cleaner. There are non so far, but we'll have dist.ipfs.io and another soon.

[jbenet]

@willglynn oh this is great! thanks! i wasn't aware of this list either, though in retrospect it makes perfect sense.

We actually want to sandbox every object on ipfs.io and gateway.ipfsio as much as possible.

yep!

I think we can't even cleanly give a child object access to its parent's cookies/localstorage/etc.

that would make it very difficult to make webapps. i think sandboxing "per-root" is probably ok. there probably are ways of "including the object in question" as your own child to get it to set cookies or something, but i think things may just have to start doing detection on the root of the path. ideally, this is would be treated as window.location.host by browser implementations.

but again, im not sure about any of this yet. we need careful study of all the security implications.

I think the resulting rule(s) should at least prevent cookies from being set for gateway.ipfs.io, as well as any subdomains (#81).

I think it should be:

ipfs.io
gateway.ipfs.io

hshca-style subdomains should be able to set cookies on themselves though.

if anything. though i wonder about the implications of saying "no cookies" altogether. i mean, ideally, this would merge sooner. maybe we can talk to that group and help push it fwd. TBL himself recently talked about this. Actually, PPSO is implemented already, just not merged it looks like: https://code.google.com/p/chromium/issues/detail?id=336894

[mburns]

[mburns]

I've begun this process: publicsuffix/list#766

After talking with @lgierth, I've used *.{ipfs,ipns}.dweb.link instead of [gateway.]ipfs.io.

[lidel]

publicsuffix/list#766 got merged:
https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat#L12501-L12503

[mburns]

Closing as complete. Thanks to @willglynn for starting this conversation.