RE: Media Queries and optimizing what data gets transferred

Dear Yoav,

Thank you for the explanation.

I believe there is a fundamental and significant difference between the two approaches.  Keeping the adaptation client-side avoids the user being forced to reveal UA state, whereas the client-hints server-side adaptation requires the user to send device characteristics to the server in order to take advantage of the benefits of adaptation (even if the server does nothing useful for the user with the information).

Given that there are two approaches that can address the same problem then I believe the right choice is the one designed for privacy and security.

Current server-side adaptation should be able to transition to using client side adaptation just as easily as it would transition to using client-hints and in many ways the result would be technically superior.  That the proponents pursue a technically inferior design, and refuse to discuss the issues, leads me to fear that they are trying to push through the client-hints standard to weaken web security and the further erode user privacy to further their own business interests.

The technical problem of image adaptation to suit varying device screen sizes and resolutions needs to be solved urgently.  I do appreciate your contribution to web performance but appeal to you to please consider security and privacy in the architecture of the web.

cheers
Fred

Date: Thu, 31 Jan 2013 10:17:01 +0100
From: yoav@yoav.ws
To: fredandw@live.com
CC: www-style@w3.org
Subject: Re: Media Queries and optimizing what data gets transferred

A technical discussion including input from all stake holders is always welcome. 
An "X vs. Y" debate when X and Y are not mutually exclusive and do not cover all of each other's use cases, is usually counter productive, and quickly degrades to a "Spiderman vs. Superman" type of debate.

IMO, two separate "How to improve {X,Y}"  discussions are usually much more productive.

Specifically, a server side image adaptation solution, while not ideal (mostly because of caching issues), is in many cases the only solution. The first example I can think of is content providers with legacy content stored in a legacy CMS. These content providers often cannot modify their (legacy) markup, even if they wanted to, which they rarely do.

They are deploying server-side based solutions *today*, both proprietary and open-source, based on UA sniffing, device screen size tables, etc. Currently, they simply forgo public caching by using either "Cache-Control: private" or "Vary: User-Agent". The client-Hints proposal would enable these solution to apply *some* public caching, which is better than none. The Client-Hints proposal can possibly be improved, but as I stated earlier, it is better to have that discussion separately.


This is why, while I personally wouldn't recommend a server-side based solution to people creating new content, I believe they have their place. If I had to pick sides, I'd pick client-side solutions, since IMO they are more future friendly. Fortunately, I don't have to.


Yoav




On Thu, Jan 31, 2013 at 1:28 AM, Fred Andrews <fredandw@live.com> wrote:





> With that said, I don't think a "Media Queries vs. Client hints" debate is productive. 

I think standards should not be adopted without at least a technical discussion and input from all stake holders.



> IMO both client-side & server-side solutions have a place, each with its slightly different use-cases and slightly different trade-offs.

Could you please elaborate on why you think the client-hints proposal in particular has a place?


There appear to be two distinct proposals:

1. Client-side adaptation: the server informs the client of the available resources and the client uses the client-side state to make a choice.  Pros: the user can choose the selection algorithm; browser vendors can innovate; the user can keep their state secure at the UA; the server does not have to deal with data collection issues; only a small set of distinct available resources need to be keyed in the cache; new resources only need to be download when one of these distinct choices changes; the UA can reuse a resource already available (such as resizing an image on hand); no changes are required on the server or the CDN; developer tools can help insert and optimized images and resource options into the HTML and then the content can be delivered statically or with less server/CDN complexity.


2. Client-hints based server-side adaptation: the client sends the server a range of client-side state and the server uses a secret algorithm to make a choice. Cons: The input parameter space is large and each combination requires a separate cache key which is more demanding on the cache; any change to the input parameters requires a re-validation request to confirm if a resource choice has changed; the client is not able to make informed decisions to reuse resources on hand if the client-side state changes (for example it can not resize an image on hand); users are required to share potentially private state which creates data collection problems for the server; users who choose not to share their private state are excluded; requires adoption of the client-hints standard; requires sending the resource choices to the client anyway to handle UAs that do not implement or have disabled the client-hints header and this leads to yet more cache duplication.


It is clear that client-side adaptation solves all the technical problems that client-hints based server-side adaptation offers and that client-side adaptation offers no advantages and significant disadvantages.  The proponents have failed to address the issues and some replies are rather arrogant and insulting which leads me to believe they have no answers.


cheers
Fred