Google redirect file violating specification?

[Jon Ribbens]

The file:

http://safebrowsing-cache.google.com/safebrowsing/rd/ChRnb29ncHViLXBoaXNoLXNoYXZhchAAGMG5CiCAvAoyLcGcAgD_____________________________________________________AA

includes the following string at position 129800:

a:171516:32:37

A hash prefix length of 32 bytes would appear to be in violation of the API specification. Could someone at Google look into this please? This will presumably break many things.

[Garrett Casto]

I don't see what in the spec this violates. We have had chunks with prefix lengths of 32 bytes since this protocol was deployed. Normally it happens either if we have a 4 byte prefix collision within the list or with a large site. One thing that we don't specify is that if you have all 32 bytes already you don't need to do a request for full length hash, since you already have it. But this is just a matter of convenience not of correctness. I'll see if I can update the spec at some point to clarify this.

 

--
You received this message because you are subscribed to the Google Groups "Google Safe Browsing API" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-safe-browsing-api/-/-MOiccLT7qoJ.
To post to this group, send email to google-safe-...@googlegroups.com.
To unsubscribe from this group, send email to google-safe-browsi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-safe-browsing-api?hl=en.

[Jon Ribbens]

On 11/05/2012 21:32, Garrett Casto wrote:

A hash prefix length of 32 bytes would appear to be in violation of the API specification. Could someone at Google look into this please? This will presumably break many things.

I don't see what in the spec this violates. We have had chunks with prefix lengths of 32 bytes since this protocol was deployed. Normally it happens either if we have a 4 byte prefix collision within the list or with a large site. One thing that we don't specify is that if you have all 32 bytes already you don't need to do a request for full length hash, since you already have it. But this is just a matter of convenience not of correctness. I'll see if I can update the spec at some point to clarify this.

Ah, thanks, it appears you are correct. I was mislead by the client code I examined and the appalling documentation. It might be an idea to add a bit to the section "shavar List Format" to say that prefix lengths can be between 4 and 32 bytes (and, as you say, to mention that it might not indeed be a "prefix" at all if it's 32 bytes).