According to reported customer issue, to be able to comply with upcoming changes to BDSG (german Federal data protection act) we need to be able to tell http response cache to not be marked as public and somehow just cache it in HTTP Cache but not other places after that (Browsers, ISP proxies, ..)

As in:
1. eZ Platform depends on being able to use HTTP Cache (Varnish,..)

• it's its native view cache system with close integration to purge whenever content expires

2. Currently only way to cache content is to mark it as public

• Making it is cached in HTTP Cache (Varnish,..) and also in Browsers and ISP proxies

The last bit is what might violate the upcoming privacy rules, as it effectively means for the length of the configured global ttl (cache Time To Live), all cached content, including those that might be sensitive (including example from original report: Users with email and user names in REST response) will be cached across Varnish, ISP Proxy and Browsers. If the ttl is set to a high number which is what we will start recommending soon (ezplatform-http-cache multi tagging is aiming for this), then the issue is made worse.

Some possible ways this could be solved:

• Content model support for marking content types as being sensitive, and use that during building the response so that Varnish will adjust http headers
• Change our VCL to always mark responses that vary on user hash as private, missing out on browser cache when that might be ok to cache
• Introduce some setting for toggling the previous option