[whatwg] Why won't you let us make our own HTML5 browsers?

[Fred Andrews]

> Date: Tue, 28 Aug 2012 21:41:02 +0000
> From: ian at hixie.ch
> To: callow_mark at hicorp.co.jp
> CC: whatwg at whatwg.org
> Subject: Re: [whatwg] Why won't you let us make our own HTML5 browsers?
> 
> On Fri, 8 Jun 2012, Mark Callow wrote:
> > On 08/06/2012 06:09, Ian Hickson wrote:
> > > The dire warning doesn't work. I'm just saying that's the direction 
> > > that operating system vendors have been going in; that disallowing it 
> > > in the browser case is not a different direction, it's consistent with 
> > > the industry's direction as a whole.
> >
> > The platform providers want control so they can extract money from 
> > application developers; they do it under the guise of safety & security 
> > so people will go along with it. Governments get control over people in 
> > the same way.
> > 
> > In both cases it is an existential threat to freedom and civil 
> > liberties.
> 
> If one works from these assumptions, why would we assume that it is 
> nonetheless possible for us to specify something that works against these 
> motivations? Putting something in the spec doesn't magically make it 
> appear in browsers.

Some statements in the spec could help defend privacy and freedom even if these are only implemented in a limited number of browser or even only as add-ons.

Some examples:

'The user-agent is not intended to accurately identify the browser and is user selectable and could well be set to a known common browser user-agent string to help preserve user privacy and prevent fingerprinting.   Further using a trademark in a user-agent gives everyone the right to use the trademark within their user-agent.'  If this language is not acceptable then we just need to remove the user-agent from the spec.

'Web browser clients may well be implemented 'in the cloud' as a service, and this could well mean that an IP address does not correspond to a user but rather the cloud service host.'
[Defend Opera Mini and other innovations]

'The execution of Javascript in the browser and thus the interpretation of any algorithms are at the discretion of the user.  The user may disable Javascript or modify the interpretation of Javascript code to suit their consumption and may use proxies to answer or filter communication from the browser.  Specifically the web browser platform is not intended for the implementation of any effective DRM measures.'

'Javascript is delivered in source form so it is not intended to provide protection from being disassembled.  Since browsers interpret Javascript as a natural part of presenting content and since they may well need to understand the code to implement control mechanisms it is specially not intended to provide protection from reverse engineering.'

'The presentation of web content is at the discretion of the user and their browser may selectively present content, transform the content, or augment the content as part of the private consumption and presentation process.'

'For example a cloud service many implement a browser that presents only the audio from videos.'
[Google seem to have already taken down some such sites]

'A web browser may well be implemented as distributed services, transforming and caching content for consumption at a time and place chosen by the user.  For example a 'cloud browser' may transform a website video and deliver it to a remote mobile device for presentation at a later time.'

'The manner in which a web browser presents content or interprets Javascript are a private matter of the user and the web browser may well implement measures to maintain privacy and block any attempts to detect the presentation and consumption methods.'

This approach could be continued to all browser privacy and freedom matters.

Those that want to turn the browser platform into a managed content consumption and spyware platform should just take their project elsewhere and start their own new platform.

We should also consider new computation approaches for use within web content that gives the users better control.  Javascript is just too general a programming language for easy management and is heading in the direction of Java.  For example a lot could be done with data-flow computations.    This could implement equations for layout, and simple event processing, that would meet the needs of many websites without the need to even enable 'Javascript'. More advanced data-flow blocks could well be managed by the user, much like apps, and may run managed Javascript.  General Javascript code execution needs to be separated from the web content - the two have become confused.

cheers
Fred