{"action":"created","issue":{"url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/890","repository_url":"https://api.github.com/repos/slightlyoff/ServiceWorker","labels_url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/890/labels{/name}","comments_url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/890/comments","events_url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/890/events","html_url":"https://github.com/slightlyoff/ServiceWorker/issues/890","id":151530581,"number":890,"title":"clarify secure context requirements in Handle Fetch","user":{"login":"wanderview","id":1256526,"avatar_url":"https://avatars.githubusercontent.com/u/1256526?v=3","gravatar_id":"","url":"https://api.github.com/users/wanderview","html_url":"https://github.com/wanderview","followers_url":"https://api.github.com/users/wanderview/followers","following_url":"https://api.github.com/users/wanderview/following{/other_user}","gists_url":"https://api.github.com/users/wanderview/gists{/gist_id}","starred_url":"https://api.github.com/users/wanderview/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wanderview/subscriptions","organizations_url":"https://api.github.com/users/wanderview/orgs","repos_url":"https://api.github.com/users/wanderview/repos","events_url":"https://api.github.com/users/wanderview/events{/privacy}","received_events_url":"https://api.github.com/users/wanderview/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-04-28T01:48:53Z","updated_at":"2016-04-28T02:06:06Z","closed_at":null,"body":"Handle Fetch step 12.1 says this for non-subresource requests:\r\n\r\n> If client is not a secure context, return null. \r\n\r\nThe client in this case is the window that initiated the request.\r\n\r\nFor some cases this makes sense.  For example, a nested iframe making the request to load its document.  This check should prevent an insecure parent document from creating a nested https iframe in order to postMessage() to the server.  That's good.\r\n\r\nIt doesn't seem to make sense, though, for things like navigations.  If I'm on http://foo.com and follow a link to https://bar.com, I should totally be able to get an intercepted and controlled https://bar.com.\r\n\r\nCan we just use the concept of \"reserved\" or \"target\" Client here instead?  I think maybe \"target\" client would be right.  (Assuming an about:blank in a new tab would pass the secure context check by being a local url.)"},"comment":{"url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/comments/215287350","html_url":"https://github.com/slightlyoff/ServiceWorker/issues/890#issuecomment-215287350","issue_url":"https://api.github.com/repos/slightlyoff/ServiceWorker/issues/890","id":215287350,"user":{"login":"mkruisselbrink","id":5649,"avatar_url":"https://avatars.githubusercontent.com/u/5649?v=3","gravatar_id":"","url":"https://api.github.com/users/mkruisselbrink","html_url":"https://github.com/mkruisselbrink","followers_url":"https://api.github.com/users/mkruisselbrink/followers","following_url":"https://api.github.com/users/mkruisselbrink/following{/other_user}","gists_url":"https://api.github.com/users/mkruisselbrink/gists{/gist_id}","starred_url":"https://api.github.com/users/mkruisselbrink/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mkruisselbrink/subscriptions","organizations_url":"https://api.github.com/users/mkruisselbrink/orgs","repos_url":"https://api.github.com/users/mkruisselbrink/repos","events_url":"https://api.github.com/users/mkruisselbrink/events{/privacy}","received_events_url":"https://api.github.com/users/mkruisselbrink/received_events","type":"User","site_admin":false},"created_at":"2016-04-28T02:06:06Z","updated_at":"2016-04-28T02:06:06Z","body":"It doesn't even make sense for \"target client\". The way things like window.open are specified for example the \"noopener\" flag isn't applied until after fetch has completed. And that noopener flag can be the difference between the target client being a secure context or not.\r\n\r\nBut this is kind of the same issue I was trying to figure out for Link headers (how to specify that Link: rel=serviceworker headers should only be processed for top-level requests that will result in a secure context). I somehow didn't realize that we already have this problem with Handle Fetch. I don't think there is a way with the way the fetch, html and secure contexts spec are currently written to properly specify this. But it certainly seems likely a request will need access to both the client that initiated a request and the client that could possibly be created using the result of the request."}}