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

[Ian Hickson]

On Wed, 29 Aug 2012, Fred Andrews wrote:
> From: ian at hixie.ch
> > 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.

Do you think adding this would increase the number of browsers that let 
you change the user agent string? On what do you base your answer?

As far as I can tell, browsers and extension writers have not needed the 
spec to say anything like this to implement such features.

(In any case, User-Agent is an HTTP feature, so out of scope for HTML.)


> '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]

What do you think adding this to the spec would do?


> '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.'

The spec already says things to this effect. Browsers already support 
disabling script and pretty much all of them, including the mainstream 
ones, have elaborate debuggers built-in. What effect do you think adding 
the paragraph above would have?


> '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.'

This seems to be something for the JavaScript spec (or the JS MIME type 
spec), not the HTML spec.


> '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.'

This is elaborately described in the spec already. What would saying it 
even more do?


> '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]

Not sure what "cloud service many implement a browser" means, but if you 
mean that a server can download an MPEG file, strip its video, and return 
just the audio, then sure, but I don't see what that's got to do with 
HTML. Heck, HTML supports that natively, just point <audio> at a video 
file and it'll strip the video.


> '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.'

What effect do you think saying this in the HTML spec would have? Are you 
saying that if the spec _doesn't_ say it, people are going to avoid 
writing proxy servers, caching servers, format-shifting programs, or 
time-shiting devices? This seems unlikely, since there are entire 
industries built around these concepts.


> '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 seems like a restatement of some of the earlier points. Again, what 
software do you think is _not_ being created today that _would_ be created 
if the spec added this statement in addition to the ones already in the 
spec that say basically the same thing?


> 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.

I assure you that such people aren't getting much of a say in the WHATWG 
and in the HTML spec.


> 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.

If you have concrete suggestions, please propose them.


On Wed, 29 Aug 2012, Mark Callow wrote:
> >
> > 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?
>
> We don't. We have to raise awareness of the issues and the level of 
> concern to the point where browser vendors will find acceding to the 
> demands for privacy, and by corollary the ability to fully control one's 
> own devices, the lesser cost option.

I think this makes a huge assumption, which is that "the demands for 
privacy" are obviously the right way to go. In practice, I think that is 
at best arguable. The ultimate in privacy, e.g. having all network traffic 
be completely anonymous and untraceable, is incompatible with things that 
are obviously good for consumers, like emergency services. (How can you 
get an ambulance to your apartment if the ambulance service can't ever 
figure out who you are?)

It has to be a balance, and it's not at all obvious where the balance 
lies, or even that the balance is too far to the side of "public".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'