Consider if redirect tainting should apply to `Timing-Allow-Origin`

[noamr]

Redirect tainting is what changes the origin into "null" when there are cross-origin redirects. It makes sense in places where we deal with credentials & data, mainly to protect against confused deputy.

However, when timing are involved, the confused deputy attack is meaningless. All this does is make it so that an origin cannot read its own timing without TAO. Since an origin knows its own timing anyway in the server, this protection is mainly a nuisance. Perhaps there's a valid reason for it that I don't see, and perhaps we want to be careful about removing protections, but in either case it would be nice to spell out what this protects again in some informative note.

[annevk]

This does not just apply in A1 -> B -> A2 scenarios (though there too A2 might not want A1 to think it wasn't influenced by B), but also in A -> B -> C scenarios. C shouldn't think the authority is A when it's really a mix of A and B.

[noamr]

This does not just apply in A1 -> B -> A2 scenarios (though there too A2 might not want A1 to think it wasn't influenced by B), but also in A -> B -> C scenarios. C shouldn't think the authority is A when it's really a mix of A and B.

This issue also applies to A -> B -> C. In TAO, unlike CORS, B doesn't have any influence over C. The only thing exposed is timing of a resource from C, and it's only exposed to A. How can B affect the timing in a way that would make C expose something that it doesn't want to A?

[annevk]

Well, B was ultimately responsible for the request so C might want to be aware of that as it could have resulted in some side effects that are also reflected in the timing data. I don't think timing is uniquely different from other sorts of data in this respect.