Currently in the Chromium implementation has the following behavior:

• Insecure background attributionsrc requests are blocked if their urls are insecure
• Otherwise background attributionsrc requests are allowed to redirect through insecure origins, but responses for them will not be processed.

This behavior is not really consistent, so we should think through the desired behavior here. If we think about the security stance of the API - we say that the publisher is in control of who can register sources by nature of them placing the attributionsrc attribute. We then make an argument for supporting redirects via transitive trust. If party A trusts party B, we consider that trust to extend to party C which B calls into. As soon as any of those parties are insecure, I think that argument falls over, because it's equivalent to e.g. party B saying they trust everyone which feels possibly too permissive.

I see two possible solutions:

1. As soon as a redirect is insecure, taint the request so no further response headers can be processed. This would be a backwards incompatible change so we'd need to analyze feasibility.
2. Keep the behavior that allows intermediate insecure requests, and make the existing behavior consistent to allow the first URL to be insecure as well.

cc @apasel422
cc @letitz for security POV here with respect to powerful features. Do you have any opinions here?