|
|
|
|
|
|
by mike_hearn
3182 days ago
|
|
|
That idea is suggested in my article, in the paragraph where I suggest forking Chromium to add a new tab type. Effectively you'd have web and newweb tabs side by side. You'd get some of the Chromium infrastructure 'for free', like user switching, the nice tab dragging code and so on. NewWeb tabs would not contain the URL bar, back button, reload button, bookmark star, extension buttons etc. But it might reduce some of the mental overhead of having to switch between 'browser' apps. |
|
|
The "new tab type" idea sounds like it fits. In a way I see the "browser renaissance", that I think (hope) is going to happen within the next decade, is also more than just about sandboxing browser engines. When you follow the line of thought further I think the browser core becomes supported by a set of decoupled libraries which will be reused by different browser engines.
I think the toughest hurdle to this kind of thing is probably abstracting away the details, but still making it possible for end users to make educated / granular decisions so that they can understand more or less what the security implications of certain actions / settings would be. I imagine those 2 things (user knowledge and need for abstraction / shielding users from themselves) will eventually converge to a happy middle ground. But for starters could (for the least knowledgeable users) probably be something like providing a handful of options like "extra safe", "safe", "maybe trouble", "danger zone".
Though to be fair "danger zone" would probably mean something different than it historically would, since the "shell app / meta-browser" hosting the browser engines in theory would prevent an application from escaping its sandbox, but instead could allow an app, within the confines of the user's settings, to do things the user didn't expect.