On 2015-01-23 4:38 AM, Andrea Marchesini wrote:
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.
Indeed, appId as currently stands is not suitable for _shipping_
something based on. It is however suitable for building a prototype on,
but there will be these types of issues in the prototype (which is
probably fine.)
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.
This is mostly a UX choice, but there will be implementation concerns
with having a tab based container, as then we'd need to handle the cases
where a tab changes what container it loads content is.
Based on my experience with the private browsing feature (which is of
course not exactly the same) it can be very hard to fix all of those
edge cases.
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
<http://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.
I think all of these can be implemented with an approach based on
Windows as well.
>
> - 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?
Yeah, the assumption that more processes means more memory is not
necessarily true.
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy
