4 ms·

> Privacy-wise, base64 encoding can have benefits since it hides the content you access in larger encrypted bundles. Uh, no.

by bdhess 8y ago

zamadatix 8y ago
Based on your selected quote and short comment I think you're reading that differently than the author intended. Note the start of that paragraph (which you left out): > In some instances, base64 encoding might even improve performance, because it avoids the need for distinct server requests. I.e. they are arguing inlining all resources and grabbing them in a single request has a smaller fingerprint. This is probably less true with HTTP/2 or QUIC
- maxk42 8y ago
  Yes, but it's not encrypted. Furthermore the article begins with the premise of using text-only data transfer protocols such as MIME, then goes on to talk about base64-encoding then gzipping data. If he were to continue talking about text-only data transfer, then he should've talked about gzipping, then base64-encoding the data or if he were talking about reducing the size of the data he should've been talking about gzipping instead of base64-encoding the data. Instead he seems to be talking about something which isn't compatible with MIME. So the article doesn't really seem to have a clear direction. If the point was to cut down on a single round-trip to the server then congratulations -- you've increased your page size by 2.5% and added the overhead of compression to the request -- a much higher toll than the cost of a 2nd request for non-trivial assets of the sort gzip would be effective for since it has its own overhead requirements.
  - zamadatix 8y ago
    > Yes, but it's not encrypted. Would your opinion change if you reread the content with the understanding HTTPS is assumed when talking about web privacy in 2019? The author made no claim whatsoever base64 was encrypting the data, just bundling it into one generic request. > Furthermore the article begins with the premise of using text-only data transfer protocols such as MIME, then goes on to talk about base64-encoding then gzipping data... Would your opinion change if you reread the content with the assumption the author means to set "Content-Encoding: gzip" in the server config rather than literally gzipping the content? I think both of these are fair assumptions for the target audience of the article to assume but your disagreements with the article are only true without them.
    - maxk42 8y ago
      > Would your opinion change if you reread the content with the understanding HTTPS is assumed when talking about web privacy in 2019? Well he began by talking about email, so no. If we want to talk about HTTPS and 2019, then let's serve the whole shebang with HTTP/2 and not worry about reducing the number of requests, which seems to be the only advantage offered. > Would your opinion change if you reread the content with the assumption That's the assumption I was forced to make, and the crux of my argument. Content-Encoding: gzip works in most servers by compressing the content on the fly -- not by precompiling. Hence my comment about adding the overhead of compression to the request.
jameshart 8y ago
The author is assuming a certain context here: that we are interested in the specific problem of transferring binary resources to a web browser. I appreciate in isolation this sentence seems incorrect, but if we assume good faith on the part of the author it's clear what they're trying to get at. They are using 'base64 encoded' as a shorthand for 'as an embedded base64 blob inside an HTML page.' - to distinguish it from 'as an individually requested resource'. So what they are referring to is that by embedding resources as base64 blobs inside HTML pages, and transferring those over SSL, an observer sees one large encrypted bundle being requested. If you transfer the resources as separate response entities, then an observer sees the large HTML bundle request, followed by the series of specific resources - and they can infer from the sizes and patterns of those requests some things about the page requested or the resources used. (for example, if I know the size of the HTML and every image on wikipedia, perhaps by observing the set of sizes of resources being downloaded by a client over HTTPS I can determine which wikipedia pages a client is browsing?)

> Privacy-wise, base64 encoding can have benefits since it hides the content you access in larger encrypted bundles. Uh, no.

by bdhess 8y ago

> Privacy-wise, base64 encoding can have benefits since it hides the content you access in larger encrypted bundles. Uh, no.

zamadatix 8y ago

Based on your selected quote and short comment I think you're reading that differently than the author intended. Note the start of that paragraph (which you left out): > In some instances, base64 encoding might even improve performance, because it avoids the need for distinct server requests. I.e. they are arguing inlining all resources and grabbing them in a single request has a smaller fingerprint. This is probably less true with HTTP/2 or QUIC

maxk42 8y ago
Yes, but it's not encrypted. Furthermore the article begins with the premise of using text-only data transfer protocols such as MIME, then goes on to talk about base64-encoding then gzipping data. If he were to continue talking about text-only data transfer, then he should've talked about gzipping, then base64-encoding the data or if he were talking about reducing the size of the data he should've been talking about gzipping instead of base64-encoding the data. Instead he seems to be talking about something which isn't compatible with MIME. So the article doesn't really seem to have a clear direction. If the point was to cut down on a single round-trip to the server then congratulations -- you've increased your page size by 2.5% and added the overhead of compression to the request -- a much higher toll than the cost of a 2nd request for non-trivial assets of the sort gzip would be effective for since it has its own overhead requirements.
- zamadatix 8y ago
  > Yes, but it's not encrypted. Would your opinion change if you reread the content with the understanding HTTPS is assumed when talking about web privacy in 2019? The author made no claim whatsoever base64 was encrypting the data, just bundling it into one generic request. > Furthermore the article begins with the premise of using text-only data transfer protocols such as MIME, then goes on to talk about base64-encoding then gzipping data... Would your opinion change if you reread the content with the assumption the author means to set "Content-Encoding: gzip" in the server config rather than literally gzipping the content? I think both of these are fair assumptions for the target audience of the article to assume but your disagreements with the article are only true without them.
  - maxk42 8y ago
    > Would your opinion change if you reread the content with the understanding HTTPS is assumed when talking about web privacy in 2019? Well he began by talking about email, so no. If we want to talk about HTTPS and 2019, then let's serve the whole shebang with HTTP/2 and not worry about reducing the number of requests, which seems to be the only advantage offered. > Would your opinion change if you reread the content with the assumption That's the assumption I was forced to make, and the crux of my argument. Content-Encoding: gzip works in most servers by compressing the content on the fly -- not by precompiling. Hence my comment about adding the overhead of compression to the request.

jameshart 8y ago

The author is assuming a certain context here: that we are interested in the specific problem of transferring binary resources to a web browser. I appreciate in isolation this sentence seems incorrect, but if we assume good faith on the part of the author it's clear what they're trying to get at. They are using 'base64 encoded' as a shorthand for 'as an embedded base64 blob inside an HTML page.' - to distinguish it from 'as an individually requested resource'. So what they are referring to is that by embedding resources as base64 blobs inside HTML pages, and transferring those over SSL, an observer sees one large encrypted bundle being requested. If you transfer the resources as separate response entities, then an observer sees the large HTML bundle request, followed by the series of specific resources - and they can infer from the sizes and patterns of those requests some things about the page requested or the resources used. (for example, if I know the size of the HTML and every image on wikipedia, perhaps by observing the set of sizes of resources being downloaded by a client over HTTPS I can determine which wikipedia pages a client is browsing?)