> Date: Tue, 28 Aug 2012 21:41:02 +0000
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> 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
