Re: Application Hash exchange between client and server

For your suggestion of the server sending hashes to the client, a variant
of this is actually under design right now. See Subresource Integrity
<http://www.w3.org/TR/SRI/> (and the many discussions on this list about
it).

For the client to server hash, this is unlikely to be implemented, for
several reasons:

   - As described, the application could lie to the server, so there would
   be no benefit. A "bad" browser could run Chrome, get the hash it sends,
   copy that hash, and start sending it to the server as if it was its own.
   - Even if some version were to be implemented (using TPMs, for example,
   or even just OS level constructs), this would almost certainly be a
   violation of the Priority of Constituencies
   <http://www.schemehostport.com/2011/10/priority-of-constituencies.html>.
   What you've described is a form of remote attestation
   <https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation>,
   which generally has been rejected on the Web (with notable exceptions
   surrounding DRM). Basically, a user agent *should* be allowed to lie. In
   fact, this is how in browser compatibility traditionally has worked, and
   why every user agent string has the words "Mozilla" and "IE" in it.

--Joel

On Wed, Jul 29, 2015 at 3:29 PM Ahmed Saleh <ahmedzs@live.ca> wrote:

> Hi Sir/Madam,
> It would be a nice feature if we can exchange hashes between server and
> browser. a client as a browser would send clients' browser hash signature
> and the server would send it's application hash signature. This way, as a
> client, I would insure that I am communicating to the right version of
> application I intend (in case if this application is open source) and as a
> server, the server would insure that it's communicating to the right
> clients' browser as intended(that for example, could protect and view my
> data).
> Thank you,
>
>