{"action":"created","issue":{"url":"https://api.github.com/repos/WICG/origin-policy/issues/19","repository_url":"https://api.github.com/repos/WICG/origin-policy","labels_url":"https://api.github.com/repos/WICG/origin-policy/issues/19/labels{/name}","comments_url":"https://api.github.com/repos/WICG/origin-policy/issues/19/comments","events_url":"https://api.github.com/repos/WICG/origin-policy/issues/19/events","html_url":"https://github.com/WICG/origin-policy/issues/19","id":248445989,"number":19,"title":"JSON structure","user":{"login":"dhausknecht","id":6725355,"avatar_url":"https://avatars1.githubusercontent.com/u/6725355?v=4","gravatar_id":"","url":"https://api.github.com/users/dhausknecht","html_url":"https://github.com/dhausknecht","followers_url":"https://api.github.com/users/dhausknecht/followers","following_url":"https://api.github.com/users/dhausknecht/following{/other_user}","gists_url":"https://api.github.com/users/dhausknecht/gists{/gist_id}","starred_url":"https://api.github.com/users/dhausknecht/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dhausknecht/subscriptions","organizations_url":"https://api.github.com/users/dhausknecht/orgs","repos_url":"https://api.github.com/users/dhausknecht/repos","events_url":"https://api.github.com/users/dhausknecht/events{/privacy}","received_events_url":"https://api.github.com/users/dhausknecht/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2017-08-07T15:23:47Z","updated_at":"2017-10-05T23:41:26Z","closed_at":null,"author_association":"NONE","body":"Since it is clear that we are talking about headers to be included I propose to restructure the JSON to group by \"baseline\", \"fallback\",\"cors-preflight\". This eliminates the need for the the \"type\" attribute.\r\n\r\n`“baseline”: {`\r\n`  <baseline headers here>`\r\n`},`\r\n`“fallback”: {`\r\n`  <fallback headers here>`\r\n`},`\r\n`“cors-preflight”: {`\r\n`  <fancy CORS stuff here>`\r\n`}`"},"comment":{"url":"https://api.github.com/repos/WICG/origin-policy/issues/comments/334621313","html_url":"https://github.com/WICG/origin-policy/issues/19#issuecomment-334621313","issue_url":"https://api.github.com/repos/WICG/origin-policy/issues/19","id":334621313,"user":{"login":"lgarron","id":248078,"avatar_url":"https://avatars2.githubusercontent.com/u/248078?v=4","gravatar_id":"","url":"https://api.github.com/users/lgarron","html_url":"https://github.com/lgarron","followers_url":"https://api.github.com/users/lgarron/followers","following_url":"https://api.github.com/users/lgarron/following{/other_user}","gists_url":"https://api.github.com/users/lgarron/gists{/gist_id}","starred_url":"https://api.github.com/users/lgarron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lgarron/subscriptions","organizations_url":"https://api.github.com/users/lgarron/orgs","repos_url":"https://api.github.com/users/lgarron/repos","events_url":"https://api.github.com/users/lgarron/events{/privacy}","received_events_url":"https://api.github.com/users/lgarron/received_events","type":"User","site_admin":false},"created_at":"2017-10-05T23:41:26Z","updated_at":"2017-10-05T23:41:26Z","author_association":"NONE","body":"I have considered trying to update the preload list format to handle different security mechanisms more consistently, and your format looks like a good generalization of that. It would be nice if we could reuse it in Chromium (assuming we're comfortable with the backwards incompatibility risk) or other serializations of security mechanism configuration data.\r\n\r\n> I think we can do away with that in the manifest, and instead tie the lifetime of the pinned HSTS policy to that of the manifest.\r\n\r\nThis makes me worried:\r\n- I don't think the two values should be correlated.\r\n  - Chrome [currently](https://crbug.com/692348) caps dynamic HSTS at one year, and Firefox has it unlimited. We [recommend 2 years for HSTS `max-age`](https://hstspreload.org/#deployment-recommendations) at hstspreload.org\r\n  - Chrome caps HPKP at 60 days.\r\n  - It seem desirable to me for HSTS to outlast the origin policy itself. I would still want to prevent MitM when the user comes back after a few months, even if I don't want all my origin policy details to last that long.\r\n- Since the manifest is already meant to be served rarely (and cached), I don't think the extra space would be a big issue.\r\n- The HSTS header right now is simple to find, parse, and interpret from all clients/user agents. This sounds like it would require scanning tools to look in even *more* places (original request headers, manifest content, manifest lifetime), for data, parse that data, and hope they combine it correctly. I think putting it in the manifest itself will cause minimal statistics bugs and security incidents.\r\n- It seems that origin policies (or headers indicating where it is which version to use) are meant to be served dynamically based on client state and maybe user agent. From my hstspreload.org scans, it already seems hard enough to get sites to set a single static header value and keep serving it. Serving a static origin-ish origin policy with explicit encoded max-ages sounds like a reasonable intermediate.\r\n\r\nAlso, we need a way to specify `includeSubDomains` and `preload` for HSTS. Those should probably be grouped instead of being placed into `tls` directly."}}
{"actor":{"display_login":"lgarron"}}