Charlie Harrison

Hey @letitz , when you mention the "tainting" design, do you mean the option (1) I am suggesting we may move to? Just to clarify this is not the current...

Ah, in our current design if you imagine a redirect chain of 1. https://secure1.example 2. http://insecure.example 3. https://secure2.example If all of those hops send response headers configuring ARA, then we...

@letitz we don't have metrics but we can investigate, your feedback is really appreciated.

Note that due to mixed content blocking and auto-upgrading, in practice I believe this issue should _only_ affect navigation requests. To protect against being redirected to in an insecure way...

> Notifying subsequent websites about the error would provide them with some data about other origins involved in the redirect chain. Could an attacker abuse this? Good call out @letitz...

Thanks for the feedback @letitz . I think it may be feasible for the redirect chain to expose this information on their own (in an opt-in way) without browser involvement...

Update on our side: we have implemented metrics in Chromium to detect the breakage of the tainting proposal. We expect that the [HTTPS upgrading](https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE) proposal will also mitigate this to...

Right now we set a null client, which appears at first glance to work (i.e. it does not cache the response), but it looks like it reuses a "null"-keyed connection...

cc @baz1 @spacegnome for thoughts. Note that this analysis currently only applies if `source_registration_time` is set on triggers. If it is not, the maximum # of reports you can receive...

Hey @eysegal , this use-case should be supported to some extent now that we have support for multiple destinations (https://github.com/WICG/attribution-reporting-api/pull/601). Here is how you can do it: 1. In source...