[jumpwah]

Thanks for the response. With browser.html, I think I meant functionally, like isn't it supposed to be marketed as a simple, out-of-box, no configuration browser for those who just want no hassle simple web browsing? (Because otherwise I might be confusing it with something else, although I was sure I saw that Mozilla research was doing something like this.)

Because if it is, I obviously don't want that... I "just" want a free software html/css/js spec compliant browser (obviously without the drm, or an option without that part, because that's not free software), but the catch is that I sort of need it to be quite customisable...

By which I mean something akin to the current firefox, which allows addons, a great powerful addon api, unlike chrome, allows modifying the ui (via userChrome.css), modifying display of web pages themselves (via userContent.css), developer console, setting configuration options via a config file, view page source etc.

This seems off-topic and almost like a personal feature request for Servo or whatever, but my point is that I know my "setup" isn't exactly 'mainstream', hence why I basically require powerful customisation options. For example, I'm on firefox (37), but it looks like this: http://i.imgur.com/L9P8XhC.png. And it's not exactly a whole heap of fragile customisations which are destined to break, it's "just" one userchrome file and one addon, so it's actually fairly reliable too.

I care about the ui in that I want the power to change it to what I like. If I can do that, I don't care what the default ui is. But I don't think browser.html's purpose is to be powerful like current firefox is it?

I guess normal isn't the right word. If anything, you're right, browser.html is normal, but not in the way I've grown accustomed to with the feature-filled firefox. If you're familiar with zsh and the fish shell, I mentally labelled browser.html as the special "fish shell" of browsers the first time I saw it, hence why I was quick to dismiss it as a future option. I should probably go and embed servo in emacs or something.. :)

[Manishearth]

I don't think there's a fixed end goal for browser.html; it's also a research project.

Spec compliance is Servo's problem. Customizability -- well, browser.html should be just as customizable as Firefox once it gets polished. Like I said, browser.html uses HTML, and Firefox uses XUL, both in mostly the same way. Firefox largely uses XUL because HTML wasn't so powerful in the past, but now it is, and technically we could replace a lot of the XUL with HTML5. Which is sort of what browser.html does. Many firefox UI components are slowly being replaced by html variants these days too.

Now with Firefox's addon API, you write addons using XUL/XPCOM. With browser.html it would be HTML/JS, and you'd be able to hook into any part of the chrome[1] you want. Addons would basically be like userscripts, except they would be for the whole browser chrome. So for example you could write a simple CSS addon that colors the location bar yellow, or write a more complex one that moves the tab strip to the side, or whatever.

Of course, since browser.html is still researchy, I don't think there are plans for an addon api yet. I'm just saying that an addon api for browser.html sounds like something that could be done. I haven't worked with browser.html, so I could be very wrong here.

Actually, fwiw you probably can write your own browser UI (right now!) from scratch using the same APIs that browser.html uses. Instead of fixing an existing UI by totally rearranging everything, write your own! Check out https://github.com/glennw/servo-shell to see what APIs work in Servo and how to use them.

Servo has a usable-ish embedding API, you might actually be able to do the emacs thing (it might help if you chat with zmike in the #servo Mozilla IRC room)

[1]: browser chrome = the stuff outside the layout engine; the UI (location bar, bookmarks, history, devtools, etc)

[jumpwah]

Wow thanks for the taking the time for the comprehensive reply! :) Really, my comment turned into a half-rant, and I wasn't expecting such a response!

Well honestly, if it does become "hackable" (i.e. ui, addons), then that invalidates all of what I said. But yes it is still experimental as you say of course, so I understand.

This is a bit off topic, but one thing that's really deterring me from firefox lately is the signed extensions thing. [1] To cut to the point, I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake [2]. (Sort of, I'm twisting the words I think, english actually not my native language, so I still have trouble expressing myself sometimes.)

My comment is just that I hope that servo/browser.html doesn't make the same "mistake". I.e. implement proper addon security, sandboxing etc. Because, if you guys do plan for an addons api, and if you give it the power ("except they would be for the whole browser chrome"), then you should also plan ahead on the security implications of that too, if any. I guess I should watch the servo project for any addon plans and bring it up there! But other than that, I'm not a security guy, so I cannot say what exactly to do.

If you're wondering why... yes extension signing is great of course, just not when only Mozilla has the power to do so imo: [3] (Not my blog, but iirc I think I agree with most of the post.)

And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p

Also, thanks for the irc hint!

[1]: https://blog.mozilla.org/addons/2015/02/10/extension-signing...

[2]: https://twitter.com/dveditz/status/591996675100545024

[3]: http://blog.rubbingalcoholic.com/post/110743007958/mozillas-...

[Manishearth]

Preface: I am not a Mozilla employee -- I'm a volunteer and don't speak for Mozilla. I also haven't ever written a Firefox addon, though I have contributed to Firefox in the past and roughly understand how addons work.

> I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake

Yeah, dveditz is calling it a mistake (and I have great respect for his opinions -- he's very frank about them and is very thorough when it comes to security matters). I believe he is calling the original design of addons (years ago) to be the mistake, though.

I personally wouldn't call it a mistake though. Not exactly. There are many options, and each would cause significant backlash. The blog post talks of the sandboxing that Chrome and Safari provide; but Chrome's extension API is very limited (I've used it). It's basically a userscript API with a small number of hooks.

A large chunk of Firefox's user base uses Firefox just because of the power of addons. There are many addons that would just not be possible in other browsers. Restricting the addon API would irreplacably break all these addons and many users would leave because their favorite addon just isn't possible anymore.

A proper permission based sandbox that exposes all the original features sounds easy, but isn't. The blog post seems to oversimplify things. The original API was to simply expose all the browser internals to the addons (with a bunch of extra utility methods). Creating a well-structured, sandboxed addon API with the same capabilities is a really, really hard problem. We can't just selectively expose functions -- browser internals were not designed to be secure in such usage, so we need to provide a whole new shim over the internals and take a lot of security things into consideration. This is a lot of work, and cannot be done in a reasonable timeframe. In the meantime, people are getting their browsers hijacked by rogue addons, which is much worse.

Same thing goes for transparency. You need a proper shim to get that, otherwise you need to turn on logging for the whole of the browser -- there's no way to tell if a request originated from a method call by a browser internal, or a method call by an addon (except for a direct request). There might not even always be a clear distinction!

The review experience could be improved; but Mozilla has limited resources and with reviewers mostly being volunteers, this is also very nontrivial.

Sideloading will always be possible unless addons are encrypted with the user's master password. Firefox's source code is public, so the format of the user data dir is public, so anyone can add stuff. Master password encryption for the full data dir is an interesting idea (it might already happen actually; never tried it), but I don't think it will fix the bulk of the problem which has to do with non-security-aware people getting their browsers filled with crap.

Making code signing optional -- It's a tossup here. I was quite annoyed when Chrome did that for their addons since it made it hard for me to share userscripts. But the sad thing is that people will just write instructions to flick that switch. I personally think that we should draw the line there, really[1] -- if we can't stop users from clicking through warningy warnings it's mostly a lost cause. Besides, attacks can always be through direct exe downloads in that case. I personally hope that Mozilla adds the option to bypass this in the future like Chrome did, but I don't think that's going to really solve the larger problem.

I think the best way to handle this would be to use signing as a stopgap measure, and slowly roll out a permission-based sandbox API that has limited functionality but doesn't need signing. It can start out with a Chrome-like API with the most commonly used features, and expand a bit into more APIs until eventually mostly everything is covered. I do believe that it was a mistake to not plan to do this, however note that this solution is still possible.

But overall I find it to be a case of "you can't please everyone" here.

> yes extension signing is great of course, just not when only Mozilla has the power to do so imo

FWIW the reviewers are volunteers, so it's not as closed a situation as it's made out to be. Still not perfect though.

> My comment is just that I hope that servo/browser.html doesn't make the same "mistake"

We don't plan to. No idea about browser.html, but Servo plans to have proper sandboxing and other things. See [2] for a library Patrick wrote to help for this (i nfact its use cases in Servo extend beyond plugin sandboxing). Plugins are on our mind, and sometimes come up during meetings/discussions, though we haven't done anything about them yet (no immediate plans either). Too many other priorities :)

Of course, servo plugins would be for stuff like Flash (ick) which need to interface with the browser engine itself. I'm not sure how browser.html plugins could pan out. It should be possible to provide a sandboxed API via the mozbrowser extensions, but I'm not sure.

> And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p

:D

[1]: See http://inpursuitoflaziness.blogspot.in/2014/04/the-battle-ag... and http://incompleteness.me/blog/2014/04/24/combatting-self-xss... for some work I've done in the past in a similar situation.

[2]: https://github.com/pcwalton/gaol