This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27302 - Define an elaboration of #may-document-use-powerful-features that checks ancestor browsing contexts
Summary: Define an elaboration of #may-document-use-powerful-features that checks ance...
Status: ASSIGNED
Alias: None
Product: WebAppsSec
Classification: Unclassified
Component: Mixed Content (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Mike West
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 27190
Blocks: 27271
  Show dependency tree / graph
 
Reported: 2014-11-11 13:56 UTC by Henri Sivonen
Modified: 2014-11-25 10:55 UTC (History)
4 users (show)

See Also:

Attachments

Description Henri Sivonen 2014-11-11 13:56:49 UTC 
https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features checks ancestor browsing contexts only for srcdoc documents. This makes the algorithm mainly useful for API that are restricted to Potentially Trusted origins in order to protect misunderstanding Web authors from assuming things that aren't true otherwise. That is, the algorithm is useful for informing Web authors about Web Crypto not providing the security properties that many people seem to think it provides on untrusted origins.

However, when the goal is to prevent a MITM from calling a privacy-sensitive API, to account for the case where the MITM injects a https iframe into an http victim origin such that the https iframe loads content from a MITM-controlled domain that has a legitimate cert, there is a need for an algorithm that checks *all* ancestors and doesn't stop climbing the browsing context chain when a non-srcdoc document is found.

Please define such a variant of the algorithm to be referenced from EME to resolve bug 27271.
Comment 1 Mike West 2014-11-11 14:03:52 UTC 
It's not clear to me that it's useful to have multiple versions of the algorithm (presumably for "powerful APIs" and "really powerful APIs"?). The privacy-relevant rationale for WebCrypto seems to me to be the same as the rationale for EME; if we wish to restrict one to documents whose entire ancestor chain is verified in a relevant way, we should probably restrict both.
Comment 2 Mike West 2014-11-20 07:46:41 UTC 
I've adjusted http://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features to add an "ancestors flag". If set when the algorithm is called, it'll only return "Allowed" if all the ancestor documents would return "Allowed".

WDYT?
Comment 3 Anne 2014-11-20 10:01:26 UTC 
If we are going to have two different kinds of "powerful features" I think we should give them distinct names.

And we should come up with a story of what APIs get to not set that flag.
Comment 4 Mike West 2014-11-20 10:17:11 UTC 
I don't really think we should have two types. However, I'm not sure it's MIX's job to dictate terms. :)
Comment 5 Anne 2014-11-20 11:12:37 UTC 
It is. Someone needs to own this.
Comment 6 Mike West 2014-11-20 11:16:45 UTC 
I'm not saying it's not WebAppSec's job. I'm saying that if we're going to outline what APIs MUST do one or the other, that's a reason for splitting this out into a separate doc. Which I kinda don't want to do.
Comment 7 Anne 2014-11-20 11:28:10 UTC 
I assume you added the flag since you don't want to change the story around crypto. Are there any similar APIs or is crypto a legacy accident?

I thought the idea was that we would have a single policy and deploy that everywhere for new features.

I don't think you're going to be able to move this document forward without addressing this. And also, addressing this is really important if we want this to succeed. We need to have a clear story.
Comment 8 Mike West 2014-11-20 11:40:02 UTC 
(In reply to Anne from comment #7)
> I assume you added the flag since you don't want to change the story around
> crypto. Are there any similar APIs or is crypto a legacy accident?

I'm hopeful that it's a legacy accident. It's unfortunately a widely-deployed legacy accident.
 
> I thought the idea was that we would have a single policy and deploy that
> everywhere for new features.

That's where I'd like to be, yes.

> I don't think you're going to be able to move this document forward without
> addressing this. And also, addressing this is really important if we want
> this to succeed. We need to have a clear story.

Yup.
Comment 9 Mike West 2014-11-20 13:29:32 UTC 
After talking with Anne a bit more, I think he's right that we need to explain the categorization, and also right that we should just have one path.

https://w3c.github.io/webappsec/specs/powerfulfeatures/ is a strawman I just threw at WebAppSec. Needs a lot of fleshing out.