Re: Web Request Status Codes

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

> Third party errors are absolutely off limits unless we receive explicit permission to report them. Without succeeding with the HTTP request, we don't have that permission. Otherwise, sites can figure out which bank a user uses by requesting third party resources from all of the banks and seeing which report errors.

Agreed 100%.


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


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

WRT the specifics of the proposal - why are we enumerating the status codes? Why not just refer to the registry <http://www.iana.org/assignments/http-status-codes/http-status-codes.xml> and report the three-digit code?

Cheers,


> 
> James
> 
> 
> On Thu, Apr 11, 2013 at 11:44 AM, Austin,Daniel <daaustin@paypal-inc.com> wrote:
> Hi James,
> 
>  
> 
>                 Thanks for the feedback. I appreciate your taking the time to look at this.  However, I’m not yet convinced that there is any privacy/security concern here. My reasoning goes like this:
> 
>  
> 
> a)      There are a large number of companies doing this already, including Google (Analytics), Yahoo! (Roundtrip and Y! Analytics), Omniture (SiteCatalyst), Mediaplex (Analytics), Compuware/Gomez (RUM), and many others. These services regularly provide collection and transport for this same data and send it upstream, often to a 3rd party (which is worse IMHO). We’re not exposing anything that others are not already doing, we’re just institutionalizing it and giving the user some control. I can certainly see 304’s, 200 (cache) responses, and proxies in that data. Presumably these companies privacy policies already alert the user about all of this, and the user has provided consent by viewing the page. (This isn’t an argument about right or wrong, but about current industry practice.)
> 
>  
> 
> b)      Users can see all of this data already, by pressing F12 or similar, so it’s not concealed from the user and then exposed to others. The data isn’t terribly useful to end users (unless they’re performance geeks) but it’s not secret.
> 
>  
> 
> On the cross-origin issue, I think there’s something I’m not understanding. Why would cross-origin requests not be logged by the client? For this data to be useful we need to know what happened when the page loaded, regardless of the source. If I put an analytics tag in my page, for example,  and it fails for some reason, I need to know about it, and omitting the error codes is the opposite of helping.
> 
>  
> 
> 3rd party calls are very often the source of performance problems on the page, and the client, IMHO, should provide full information about everything that happens in all the HTTP request/response cycles that went into that page’s composition. In today’s world, nearly every page published by any commercial organization is likely to have some 3rd party content.
> 
>  
> 
> The more I think about this the more I think the right path is to provide detailed information for everything and be transparent about it all.
> 
>  
> 
> Regards,
> 
>  
> 
> D-
> 
>  
> 
>  
> 
>  
> 
> From: James Simonsen [mailto:simonjam@google.com] 
> Sent: Wednesday, April 10, 2013 2:58 PM
> To: public-web-perf@w3.org
> Subject: Re: Web Request Status Codes
> 
>  
> 
> Exposing HTTP status codes exposes a lot of information that hasn't been exposed before. For instance, there are codes that explicitly reveal the existence of a proxy and whether or not a resource is cached. We haven't exposed this sort of information before.
> 
>  
> 
> Before getting too far ahead of ourselves, I think we need to have a thorough security and privacy review about whether it's safe to expose this level of information. Otherwise, we're just wasting time discussing this.
> 
>  
> 
> Separately, note that the DNS and TCP (and possibly many HTTP) errors are useless for cross-origin requests, because there's no way to determine if logging is allowed.
> 
>  
> 
> James
> 
>  
> 
> On Mon, Apr 8, 2013 at 3:48 PM, Austin,Daniel <daaustin@paypal-inc.com> wrote:
> 
> Hi Team,
> 
>                 I’ve attached to this email an HTML file with the current list of Web Request Status Codes. This list includes all of the status codes that I’ve been able to track down, with some exceptions. There are a great many of them. Here’s a breakdown of the process and the decisions I made to produce the current list:
> 
> ·         Some status codes were omitted for being ridiculous (418, 420)
> 
> ·         Some status codes returned by existing servers but not part of any RFC are still listed in red – I don’t think they belong here (possibly with the exception of 509) but I’ve left them in for discussion purposes.
> 
> ·         Non-HTTP status codes have been added. There are a lot of them (around 40). Since RFC 2616 clearly specifies that HTTP status codes have 3 digits, I’ve begun the numbering for non-HTTP status codes at 1000. These status codes are broken down by their level in the OSI stack and namespaced accordingly e.g. 1207 SSL: Cipher Error as opposed to 1109 TCP: No route to host. There are four groups of these, namespaced as DNS:, TCP:, SSL:, HTTP:, and Client: . The HTTP: status codes are not currently included in RFC 2616 or any of the other specs, but are common errors seen by clients e.g. 1302 HTTP: Header malformed. Perhaps ‘HTTP server:’ is better?
> 
> ·         I’ve included a key to the different RFCs that contain HTTP status codes. There are 13 (!) of them, and 2 status codes are in draft proposals, linked in the document.
> 
> ·         For any status code not included in RFC 2616, I’ve tried to provide a rationale for its existence.
> 
> ·         Color codes: black = RFC 2616, blue = new for this spec or repurposed from some proprietary list, red = proprietary and doesn’t belong here IMHO
> 
> ·         Sources: RFC 2616, other RFCs and drafts as listed, Wikipedia, Stack Overflow, MSFT sites, Compuware/Gomez, KeyNote, Catchpoint, Nginx, Apache
> 
> ·         For completeness, I’ve included all status codes received by the client, not just the error codes. There are several that are not in RFC 2616.
> 
> ·         I took the liberty of repurposing some existing-but-nonstandard codes and renumbering them for our purposes. I’ve tried to indicate the source e.g. (Nginx)
> 
> Here’s the next steps as I see them:
> 
> ·         Agree on a more-or-less final list of status codes, correct any omissions or duplicates
> 
> ·         Move this table into Jatinder’s spec (or maybe a separate Note?)
> 
> This task took considerably more time and effort than I had expected. Who knew there were so many status codes ?
> 
> Regards,
> 
> D-
> 
>  
> 
>  
> 
> 

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

Received on Thursday, 11 April 2013 23:47:13 UTC