Re: Web Request Status Codes

On 12/04/2013, at 10:12 AM, James Simonsen <simonjam@google.com> wrote:

> 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.)

Yep, been there :)


> 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.

Great. I'll try to loop in a few folks as well.

Cheers,




--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 12 April 2013 00:17:53 UTC