> I see we copied the headers restrictions from Chrome, do we have an idea of the rational here? It might be from Chrome, but the list actually references the Fetch spec. It probably made sense to copy Chrome if we're going for compat, and It was a safe choice by default, without going into details of each header. https://fetch.spec.whatwg.org/#forbidden-header-name About Referer specifically, I can see two subtle issues: - If your extension has `a.com` host permission, it can modify the download headers and insert `b.com` as Referer, - but If it has `b.com` permission, there are ways to trigger a load from `b.com` with `a.com` as a Referer (ie embedding an image). I'm not sure which one is more surprising, but since either workaround doesn't already require both permissions, I think we can allow the header for downloads without any host permissions. > I would imagine if we allow Cookie you could trigger remote endpoints with the users' credentials, which might be unexpected for an extension that only has the download permission, but no hosts permission. Cookies already require host permissions, so we wouldn't want to relax that. Checking permissions would be possible, but not sure it's worth it without a good use case that isn't covered by just using the cookies api.
Bug 1367626 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> I see we copied the headers restrictions from Chrome, do we have an idea of the rational here? It might be from Chrome, but the list actually references the Fetch spec. It probably made sense to copy Chrome if we're going for compat, and It was a safe choice by default, without going into details of each header. https://fetch.spec.whatwg.org/#forbidden-header-name About Referer specifically, I can see two subtle issues: - If your extension has `a.com` host permission, it can modify the download headers and insert `b.com` as Referer, - but If it has `b.com` permission, there are ways to trigger a load from `b.com` with `a.com` as a Referer (ie embedding an image). I'm not sure which one is more surprising, but since either workaround doesn't already require both permissions, I think we can allow the header for downloads without any host permissions. > I would imagine if we allow Cookie you could trigger remote endpoints with the users' credentials, which might be unexpected for an extension that only has the download permission, but no hosts permission. Cookies already require host permissions, so we wouldn't want to relax that. Checking permissions would be possible, but not sure it's worth it without a good use case that isn't covered by just using the cookies api.
> I see we copied the headers restrictions from Chrome, do we have an idea of the rational here? It might be from Chrome, but the list actually references the Fetch spec. It probably made sense to copy Chrome if we're going for compat, and It was a safe choice by default, without going into details of each header. https://fetch.spec.whatwg.org/#forbidden-header-name About Referer specifically, I can see two subtle issues: - If your extension has `a.com` host permission, it can modify the download headers and insert `b.com` as Referer, - but If it has `b.com` permission, there are ways to trigger a load from `a.com` with `b.com` as a Referer (ie embedding an image). I'm not sure which one is more surprising, but since either workaround doesn't already require both permissions, I think we can allow the header for downloads without any host permissions. > I would imagine if we allow Cookie you could trigger remote endpoints with the users' credentials, which might be unexpected for an extension that only has the download permission, but no hosts permission. Cookies already require host permissions, so we wouldn't want to relax that. Checking permissions would be possible, but not sure it's worth it without a good use case that isn't covered by just using the cookies api.