Re: Web Request Status Codes

On Thu, Apr 11, 2013 at 4:46 PM, Mark Nottingham <mnot@mnot.net> wrote:

> > Additionally, we are concerned that our users will be fingerprinted by
> malicious sites. Exposing additional information makes those attacks much
> easier.
>
> That's very reasonable as a position statement. However, it doesn't help
> decide whether to add new features, because taken at face value, we
> wouldn't add *any* features to the Web platform ("information" is
> unavoidably broad, after all).
>
> In this instance, can you explain how adding response status codes adds
> potential bits to a fingerprint (assuming same-origin constraints)? I agree
> there could be some convoluted scheme whereby a cached, non-standard status
> code could add a bit or two, but that doesn't seem relevant, when you
> consider that a cached ETag is a much simpler, already available and more
> capable way to do so.
>

You could get different response codes if requests were blocked by certain
anti-virus/anti-malware/ad-blocking software, for instance. (There's a
shocking number of users behind transparent proxies like these. We found
this out the hard way while experimenting with HTTP pipelining.)

FTR, I'm not a privacy expert, which is why I'm insisting we defer to them.
If they have no concerns, I'm happy to move forward.


> > I've requested review from the Chrome privacy and security teams. I
> don't think we should bother discussing Error Logging any further until
> everyone else does the same.
>
> Great. When will their review be complete? Will the results be shared with
> the WG?  (just trying to understand the process you're proposing)


I'll definitely report back when I hear. I don't know when they'll be done.
We should engage other such groups in the meantime.

James