[Cryptography] nytimes.com switches to https

[Christian Huitema]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, January 12, 2017 1:22 PM, Ray Dillinger wrote:
> ...
> A standard I've seen applied elsewhere is "a power of two, optionally
> multiplied by three."  It gives the usual sequence of "Computer Science
> round numbers"  ie, 1,2,3,4,6,8,12,16,24,32,48,64.....
>
> Maximum overhead is 50%.  I think that's in the "reasonable" range for
> most purposes.

The "optionally multiplied by 3" series is an approximation. The fractional power equivalent is "Ceiling(2^(N/2))", which gives the same numbers up to 64, but differs slightly after that: 64, 91, 128, 182, 256, 363, 512, etc., versus 64, 96, 128, 192, 256, 384, 512, etc. Padding with the 2^(N/2) series has an overhead of (sqrt(2) - 1), about 40% instead of 50% for the multiply by 3 approximation.

> But size-padding schemes aren't enough to narrow down the identity
> of the article accessed, unless the request/response is condensed into
> a single entity with all text and graphics embedded in one response.
> There's an obvious difference, to a traffic analyst, between a page that
> triggers further requests for 20 different images and a page that
> triggers further requests for 21 different images.  If you add in
> image sizes, whether padded to a "round number" or not, the whole thing
> is quite transparent.

Yes, that's quite true. I could not find the statistics about page size, number of images, etc., at https://en.wikipedia.org/wiki/Wikipedia:Statistics. Looks like an interesting project that would give a good basis for the discussions. 

> So what you need is a server-side plugin that packages all the stuff
> that's supposed to be on a page into a single http response, and a
> browser plugin that unpacks these mini-archives and displays them
> correctly. I think this is standard methodology for IPN protocol,
> because it minimizes roundtrips and IPN is all about minimizing
> roundtrips.  But there are no web browsers and damned few servers
> that speak IPN, and so far it hasn't been applied to IP networks.

Very good point. It might be possible to do something like that with HTTP2, and even better with QUIC. Multiplex several streams over the transport connection, and use the prefetching features to get the images without showing separate bursts. Instead of padding with noise, pad with data that you may want to cache. That might even be quite efficient!

- -- Christian Huitema
-----BEGIN PGP SIGNATURE-----
Comment: Using gpg4o v5.0.7.7563 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJYeCpHAAoJELba05IUOHVQffYH/Aypz7v8MSL6KBVaMpIOXTfC
gmDBO8DmcQ7w+aZ6wOUL77Sun958gwizVtFw6C96Sc+FIY0pNSLzMAfIpiPeix+i
8KGPm7CA2bkRgj7oiKofon+3GB0hKpY7n6gBZmiWNsRbsDth7qn+ehLQ9Ns84d90
A8A7yRO7nTCMFNT7b3uFUutJD85maD1sOaki4RLgLnMIF2Yel3YggvtgqX7PZ1c/
gd36I3dnG9Ok0EEXpkhYJKujKv2z/el8qZ0ZG/jq4OdTv5VGITyzuHnAa4WMguIL
nNGCApKwsgI7p8zdsoqFUzI2Ac1DvzoQh0+KDWx2zVlS6KdDIprvZFo1BmijOQA=
=BzcW
-----END PGP SIGNATURE-----