I still don't have a strong opinion between profiles vs container. But here
my feedback to the discussion.

> It does make the implementation a lot more challenging, since I suspect
> > very strongly that the existing appId support will not be enough.
> >
>
> ... but a good start and good enough for a prototype to get feedback.
>

Correct. The current limitation I see are:

1. window.open() fails. This because the current window.open checks some
permissions based on the app having the docShell.appId.
But just setting the appId in the docshell (this is what I do in priv8) I
just abuse of appid technologies because technically I don't have a real
app, fully installed.

So, window.open using nsIAppService will try to retrieve the
mozIApplication object from the appId. This fails and window.open throws an
exception.

Nothing impossible to fix, but there is some work to do.

I discussed a lot with sicking and bent about how to improve the appId
system and we all agree that would be nice, in the long run, to switch to
some kind of 'prefix' and split the app feature from the prefix
(container?) feature. This seems the perfect solution to the container
approach.

2. Some other function fails too: canvas.toDataURI... but I'm not 100% sure
about this. But I guess the reason is similar to point 1.


> But you still have to go through the steps of creating a new profile. A
> contained window would be fewer clicks. Unless, of course, we had a single
> click option for a disposable profile.
>

Indeed. I guess we should also decide if we want to have this feature
window based on tab based.
Personally, the reason why I love priv8 (appId) more than switchy
(profiles) is that with priv8 I can have sandboxed tabs. This is literally
awesome for how I use the browser. I don't like to have multiple windows,
but tons of tabs.

Plus, if we have this feature based on tabs, we can do magic tricks like:

- sandboxes per origin - any time I open gmail or facebook or twitter, put
it in the container X...

- help the user to switch to the right container with a new UX.

- security analysis based on the browser history: I'm thinking about: "this
website is considered dangerous for some privacy concern, do you want me
(firefox) sandbox it?"

- one more thing would be: sandbox switching: I sandbox 'facebook.com'. One
day I do a mistake and I log-in on facebook in the default container (no
app). I can open some settings panel and do: "switch my facebook history
from the default container to the facebook container. And magically I
restore the division between containers.


> >
> >  - a new Firefox process is started per profile
> >>
> >
> > Why is this a bad thing?
>
>
> Increased memory usage.
>

We are already starting tons of new processes with e10s, right?

b
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy

Reply via email to