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
