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

[Brett Zamir]

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

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.

A more limited application of this idea would be for the earlier idea I 
shared for iframes to allow independent navigation controls. A web app 
could propose itself as the view for such iframes.

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

Brett