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

[Brett Zamir]

On 12/17/2011 3:27 PM, Andreas Gal wrote:
> We are working on an API to allow implementing a web browser as an HTML5 application. It is going to take quite a while to get the API and security model right, but we are definitely interested in the topic.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=693515
Cool, thanks for this---I really think this needs to work from within a 
real browser for now, in order to win converts who aren't yet ready to 
let go of the built-in goodness of the likes of Firefox while they 
experiment with or co-exist with alternatives they may find on the web.

While this may allow the browser to become more stripped down as far as 
built-in UI controls, I hope this may simultaneously encourage adding 
back the broader built-in functionality made available to the likes of 
Seamonkey (e.g., to allow handling client-side email from a webapp in a 
non-proprietary manner as well).

Also, please while it is early enough in the process, do not assume that 
a browser will only want to allow one privileged frame nor ignore the 
potentially powerful capability of individual otherwise non-privileged 
websites having iframes with their own independent navigation controls 
(https://bugzilla.mozilla.org/show_bug.cgi?id=618354 ).

Best wishes,
Brett


> Best regards,
>
> Andreas
>
> On Dec 16, 2011, at 11:16 PM, Brett Zamir wrote:
>
>> What is the reason you won't let us make our own browsers-in-a-browser?
>>
>> 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).
>>
>> Of course there are security risks, but a standardized, cross-platform, re-envisioned and expanded equivalent of ActiveX, which can work well with Firewalls, does not add to the risks already inherent in the web.
>>
>> 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. There is absolutely no real difference between these and what I am proposing, except that executables offer the added inconvenience of being non-cross-platform and awkward for requiring a separate, non-readily-unifiable means of managing installations. Otherwise, please someone tell me what is the /insurmountable/ difference?
>>
>> I am not really interested in a prolonged technical discussion or debate about the limitations of existing technologies. I am asking at a higher level why bright people can't help us move to a web like this. As per Ian's signature, "Things that are impossible just take longer", I see no logical reason why such a web can't be envisioned and built.
>>
>>  From the resistance I have seen to the idea among otherwise bright people, I can only reach the conclusion that there must be some ulterior motives behind the resistance. The main browsers would not be able to corner the market as easily anymore if such a thing happened. Because as long as there are these oligopolic fiefdoms requiring a separate set of JavaScript API standards for run-of-the-mill web developers to be able to develop privileged applications easily---or for them to be unable to interact in a privileged fashion with other such applications, there is less competition and sadly, the world won't see competitive and collective innovations leading to better privileged browsers.  Rather we are stuck with a centralized model whereby, the main browsers remain the gate-keepers of innovation.
>>
>> The dream of "Write once, run anywhere" is thankfully becoming more realized with HTML5, though there is still a need for an expanded dream, something along the lines of "Write once, run anywhere, access any functionality desired", and the current albeit highly skilled custodians of the web seem to sadly lack the vision at the moment to at least point us in that direction, let alone have plans to achieve it. I would really like to know why others seem not to have seen this problem or reacted to it...
>>
>> Admittedly, such a concept could, if the existing browser add-on systems adequately expose such high privileges to their add-ons, be initially implemented itself as an add-on, allowing a cross-browser API initiated from websites to trigger the add-on to ask for the granting of website privileges, but in order to be well-designed, I would think that this effort should fall under the umbrella of a wider, representative, consultative, and capable effort, which is supported in principle by the browsers so that at the very least they will not end up curtailing privileges to their add-ons down the line on which the effort depends.
>>
>> Best wishes,
>> Brett
>>