Site might phish a site that archives it

[jyasskin]

I've been designing as if we could have a page like https://web.archive.org/web/20200914192731/https://www.example.com/ serve a web bundle that it doesn't do a lot of work to vet because it winds up executing in a suborigin. However, @wycats pointed out that that could allow https://web.archive.org/web/20200914192731/https://attack.web.archive.evil.example/ to show a login form for https://web.archive.org, and because the browser would emphasize the serving origin, it would probably fool the user. See also some discussion on #560.

A couple thoughts:

• This is still better than the current situation, where an unvalidated archived site can just exfiltrate login cookies.
• Some discussion in Network access #576 suggests a way to mark a bundle as having no network access, which might prevent it from using any credentials it manages to phish. Is that sufficient?
• This probably isn't a worry for bundles accessed as file:s?

[TimothyEBaldwin]

Prohibiting network access does not prevent exfiltrating the phished credentials by using a side channel, such as CPU, GPU and memory usage, electricity consumption, or displaying them possibly in a covert fashion.

[quasicomputational]

Is it too late in the day to suggest that unsigned bundles should always be an opaque suborigin unless the distributor explicitly sets a header requesting that it be treated as authoritative (in which case the browser will treat it as authoritative iff distributor origin == publisher origin, as the plan is now)?

[jyasskin]

@quasicomputational It's not too late in the day, but I think that's also orthogonal to the question of how to protect sites that want to serve bundled archives of cross-origin sites, which would always live in suborigins. The similar fix here might be to put bundles in completely opaque origins, giving users no indication of where the bundle comes from or what it claims to be a copy of when they're reading it.