4 ms·

Basically it comes down to this. Many webservers use gzip to compress data. Gzip creates a header which has a date field in it. Most webservers fill this date f

Basically it comes down to this. Many webservers use gzip to compress data. Gzip creates a header which has a date field in it. Most webservers fill this date field with zeros, about 10% use the actual date, including the timezone, which can reveal the location of the server. Tor is not to blame here, and gzip or most webservers probably neither. It's an unforseen side effect by a combination of tools. The article provides a script to test if a server reveals the date and timezone or not.

bentronic 11y ago
Those servers are out of spec, then. The RFC says it's supposed to be POSIX time, i.e., always in UTC. https://tools.ietf.org/html/rfc1952 https://tools.ietf.org/html/rfc1952
- joosters 11y ago
  Perhaps those servers are running Windows, where the time is local time and the server doesn't want to spend the effort to do the conversion?
  - MichaelBurge 11y ago
    The spec predicted in 1996 that this would happen: "(Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.)"
  - nbevans 11y ago
    Are you seriously suggesting Windows doesn't know the concept of UTC time? And secondly suggesting that fiddling with timezone offsets is an expensive conversion?
    - throwaway2048 11y ago
      the system clock on windows is not UTC, it is local time. On Unix the clock is always UTC and is converted to local time for display purposes.
      - nbevans 11y ago
        That is the same as Windows. Where are you getting your information?
        feld 11y ago
        No, there was a time when Windows stored local time -- also synced to BIOS clock. I don't think that's true anymore, though.
        throwaway2048 11y ago
        it remains true in windows 10, although it can be changed via some registry fudging.
Houshalter 11y ago
I think you can blame gzip. Tools shouldn't insert unnecessary metadata into files. At least not without asking or warning. What does putting a timestamp into gzip add? Or the operating system, for that matter?
- deleted 11y ago
  [deleted]
- masklinn 11y ago
  > What does putting a timestamp into gzip add? Roundtripping the file's mtime through compression/decompression is convenient. Same reason why the original filename can be stored (roundtrip it in case the filename is truncated at one point e.g. by having the gzip archive move through an msdos system). Here's how the spec defines it: MTIME (Modification TIME) This gives the most recent modification time of the original file being compressed. Sadly the spec then goes on to recommend leaking the compression date: The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.) If the compressed data did not come from a file, MTIME is set to the time at which compression started. MTIME = 0 means no time stamp is available. However note that the spec recommends a unix timestamp, which is ~UTC, and doesn't include the space for a timezone. Reading the POC[0] it apparently assumes any non-zero mtime is immediate (ignoring cached assets) and local. [0] https://github.com/jcarlosn/gzip-http-time/blob/master/time.php#L29 https://github.com/jcarlosn/gzip-http-time/blob/master/time....
masklinn 11y ago
> Most webservers fill this date field with zeros, about 10% use the actual date, including the timezone They can't include the timezone since the field is a unix timestamp, there's no room for the timezone. Apparently the script just assumes whichever date is stored in the mtime field is a local date (when the spec suggests UTC/GMT): https://github.com/jcarlosn/gzip-http-time/blob/master/time.php#L29 https://github.com/jcarlosn/gzip-http-time/blob/master/time....

bentronic 11y ago

Those servers are out of spec, then. The RFC says it's supposed to be POSIX time, i.e., always in UTC. https://tools.ietf.org/html/rfc1952 https://tools.ietf.org/html/rfc1952

joosters 11y ago
Perhaps those servers are running Windows, where the time is local time and the server doesn't want to spend the effort to do the conversion?
- MichaelBurge 11y ago
  The spec predicted in 1996 that this would happen: "(Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.)"
- nbevans 11y ago
  Are you seriously suggesting Windows doesn't know the concept of UTC time? And secondly suggesting that fiddling with timezone offsets is an expensive conversion?
  - throwaway2048 11y ago
    the system clock on windows is not UTC, it is local time. On Unix the clock is always UTC and is converted to local time for display purposes.
    - nbevans 11y ago
      That is the same as Windows. Where are you getting your information?
      - feld 11y ago
        No, there was a time when Windows stored local time -- also synced to BIOS clock. I don't think that's true anymore, though.
        throwaway2048 11y ago
        it remains true in windows 10, although it can be changed via some registry fudging.

Houshalter 11y ago

I think you can blame gzip. Tools shouldn't insert unnecessary metadata into files. At least not without asking or warning. What does putting a timestamp into gzip add? Or the operating system, for that matter?

deleted 11y ago
[deleted]
masklinn 11y ago
> What does putting a timestamp into gzip add? Roundtripping the file's mtime through compression/decompression is convenient. Same reason why the original filename can be stored (roundtrip it in case the filename is truncated at one point e.g. by having the gzip archive move through an msdos system). Here's how the spec defines it: MTIME (Modification TIME) This gives the most recent modification time of the original file being compressed. Sadly the spec then goes on to recommend leaking the compression date: The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.) If the compressed data did not come from a file, MTIME is set to the time at which compression started. MTIME = 0 means no time stamp is available. However note that the spec recommends a unix timestamp, which is ~UTC, and doesn't include the space for a timezone. Reading the POC[0] it apparently assumes any non-zero mtime is immediate (ignoring cached assets) and local. [0] https://github.com/jcarlosn/gzip-http-time/blob/master/time.php#L29 https://github.com/jcarlosn/gzip-http-time/blob/master/time....

masklinn 11y ago

> Most webservers fill this date field with zeros, about 10% use the actual date, including the timezone They can't include the timezone since the field is a unix timestamp, there's no room for the timezone. Apparently the script just assumes whichever date is stored in the mtime field is a local date (when the spec suggests UTC/GMT): https://github.com/jcarlosn/gzip-http-time/blob/master/time.php#L29 https://github.com/jcarlosn/gzip-http-time/blob/master/time....