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

On Wed, 1 Feb 2012, Bronislav KluÄ~Mka wrote:
> On 1.2.2012 1:36, Ian Hickson wrote:
> > > 
> > > I am not interested in the argument that "It is just too dangerous". 
> > > Browsers already allow people to download executables with a couple 
> > > clicks, not to mention install privileged browser add-ons. Enough 
> > > said.
> >
> > Well, in all fairness, browsers and operating systems are going out of 
> > their way to make this harder and harder. Some (e.g. iOS, ChromeOS) 
> > make it essentially impossible now, others (e.g. Android) require you 
> > to explicitly opt-in to an obscure developer mode feature before 
> > allowing it, others (e.g. MacOS, Windows) keep track of where files 
> > were obtained from and give dire warnings before running apps from the 
> > Web.
> 
> And you have apparently no idea how annoying this is, I cannot even 
> imagine a car being built with this constant paranoia in mind. It would 
> take 3 hours to start an engine... Or maybe it would be impossible all 
> together... because, well, you might get killed in car... so no one will 
> ever drive in a car anymore... Let people have their own responsibility 
> for what they do! This is like the lamest reasoning ever, the approach 
> of "we will protect you even against your will"... man this sounds like 
> really scary politicians out there... I understand the need for 
> protecting users... fine by me, but by limiting developers?

I'm not making a judgement here, I'm just letting you know how things 
stand. As far as the spec goes, I have to spec what will get implemented. 
If browser vendors feel a particular style of feature is too dangerous, 
there's no point me speccing it.


On Wed, 1 Feb 2012, Bronislav Kluèka wrote:
> 
> My dream is to actually have a high level application platform being 
> able to run "anywhere". Yeah, I know about Java, .NET/Mono, Object 
> Pascal... I actually do write multiplatform applications in .NET/Mono, 
> and Object Pascal... fine as languages, but considering the 
> multiplatform feature... all pretty much a failure (do not get me wrong, 
> it can be done in those platforms, but given the potential here)... 
> Still I'm being drawn to this little language called ECMAScript, 
> presentation/definition potentials of CSS/HTML... Imagine how much fun 
> this could be with web technologies... you just run browser of your 
> choice anywhere you want, you run an application of your choosing (and 
> anywhere you are, always the same), you can manage your remote data, if 
> you want them remote, you can manage local data, if you want them local 
> (that is the very point of everything I wrote so far)... It would be so 
> easy and we are so close.... Java Applets suck it :).

The Web pretty much is what you describe here, yes. The way it limits 
application developers to prevent them from doing things that are 
user-hostile is a huge part of the reason for its success.


On Wed, 1 Feb 2012, Brett Zamir wrote:
> On 2/1/2012 8:36 AM, Ian Hickson wrote:
> > On Sat, 17 Dec 2011, Brett Zamir wrote:
> > >
> > > What is the reason you won't let us make our own 
> > > browsers-in-a-browser?
> >
> > What is the use case for browser-in-a-browser?
> > 
> > If you have a browser... then you have a browser. Why would you want 
> > to run another one inside your browser?
> 
> It would let anyone with web skills to have full creative control over 
> the browser UI which they can in turn easily share with others 
> regardless of the host browser those people are using, and without the 
> hassle of building and packaging browser-specific add-ons or 
> executables, or forcing users to manage these executables.

That doesn't seem like a particularly compelling use case.


> The facility of allowing such a tool to be written in a standard 
> cross-browser language would encourage experimentation and choice, and 
> ultimately, I believe, better and more tailored user experience.

I think there's plenty of opportunity for experimentation and choice today 
already, with browsers written as native apps.


> I think such a recommendation as this also goes hand-in-hand with my 
> earlier recommendation for the easy creation of shared databases which 
> presumably unlike Shared Workers can persist outside of and be 
> independent of the original application, and would allow extensibility 
> for these browser-in-browsers (which we might call "bibs")--as well as 
> new life for "Open Data".

You can share data today using an iframe and postMessage() to a common 
database provider.


> One could store the browsing history, for example, in such a shared 
> database, which could in turn be accessed by other alternative bibs. 
> Especially with experimentation on shared database formats, this could 
> build confidence among users that the histories, bookmarks, cookies, 
> data or documents saved for fast or aggregated local querying, or other 
> personal data they are building would remain accessible to them on their 
> machine even if they later chose another bib.

It's not clear to me that making any site be able to access my browsing 
history would be a win.


> > > I'm not talking about some module you have to build yourself in 
> > > order to distribute a browser as an executable. I'm talking about 
> > > visiting a (secure/signed?) page on the web and being asked 
> > > permission to give it any or all powers including the ability to 
> > > visit and display other non-cross-domain-enabled sites, with the 
> > > long-term possibility of browsers becoming a mostly bare shell for 
> > > installing full-featured browsers (utilizing the possibility for 
> > > APIs for these "browsers" to themselves accept, integrate, and 
> > > offline-cache add-on code from other websites, emulating their own 
> > > add-on system).
> >
> > How do you help users who have no idea what that means and grant a 
> > hostile Web site claiming to be a browser access to everything?
>
> How do you help users who are told "Download this zip file and click 
> this "exe" file"?

iOS prevents it by preventing downloads altogether. ChromeOS and Android 
prevent it by preventing the user from executing arbitrary code. Mac OS 
and Windows display prominent warnings about the danger of such actions -- 
and that's not enough; witness the frequent malware attacks.


> Or, how do you help users who visit a site allowing malicious add-ons? 
> No one has yet to explain the supposed difference to me in any 
> satisfactory manner.

There is no difference, IMHO. You'll notice I haven't specified add-ons 
nor required that browsers implement the ability for the user to execute 
arbitrary code from the network with their user privileges.


> > > I am not interested in the argument that "It is just too dangerous". 
> > > Browsers already allow people to download executables with a couple 
> > > clicks, not to mention install privileged browser add-ons. Enough 
> > > said.
> >
> > Well, in all fairness, browsers and operating systems are going out of 
> > their way to make this harder and harder. Some (e.g. iOS, ChromeOS) 
> > make it essentially impossible now, others (e.g. Android) require you 
> > to explicitly opt-in to an obscure developer mode feature before 
> > allowing it, others (e.g. MacOS, Windows) keep track of where files 
> > were obtained from and give dire warnings before running apps from the 
> > Web.
>
> Is giving a dire warning only conceivable and potentially intelligible 
> to users of web apps, yet not for this proposal?

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.

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