3 ms·

Have you seen Qubes OS [0]? I have never used it, but the video demo [1] looks to have exactly what you want. You define different "security domains" and can op

by neuland 10y ago

Have you seen Qubes OS [0]? I have never used it, but the video demo [1] looks to have exactly what you want. You define different "security domains" and can open applications in each. Each domain has it's own data and can have multiple applications. Like you could download a file from your Google Drive (in your Google domain) and open it. But, that doesn't have any effect on other domains. And, those domains don't see that file. Edit: Just read the other half of your comment. There seems to also be a throwaway domain that you can use that is doesn't persist data after you close it. [0] https://www.qubes-os.org https://www.qubes-os.org [1] https://www.qubes-os.org/video-tours/ https://www.qubes-os.org/video-tours/

x1798DE 10y ago
I specifically meant in a browser. I'm certainly planning on looking into Qubes for an OS, but this is really more of a problem with data leaking within a browser, I don't think the OS has much say in that.
- neuland 10y ago
  Well, you'd ideally create different VMs for where you want barriers to data leak-age via cookies, history, session- + localstorage, and loading assets/scripts/etc from or making requests cross domain to 3rd parties. But to your point, even within a given browser/VM/whatever that I intend on using for a single task. I'd still eventually end up slipping up and going to a site that should have been in a different group or logging into something that I wanted in an ephemeral group. There is a real problem currently with data sharing on the web, where it's pretty much all or nothing. That'll still be true under the scheme you mention, just the goalpost will be moved to within whatever grouping scheme you pick. It seems there isn't a good way to allow sites to do useful things like ajax to lots of services not on the same domain, while preventing the site provider from sharing your data with people you don't want to have it. Ad- and tracker- blockers alleviate some of this by preventing certain undesired code from running and thus sharing data. But, user tracking is still possible (and used to actually happen by) using server-side logging and shipping info to 3rd parties. Ultimately, we are relying on the people or organization behind a site to not share our data. And, yes the tools could get a bit better with grouping/profiles. But, the vast majority of users won't use these tools. And, even if you use them, you have to be diligent in only opening certain sites in certain "groups" and/or managing which group you are logging into your account in. So, features like this always will be niche unless there is a revolutionary shift in users' technical ability and attitude towards data protection / privacy.
  - Jarwain 10y ago
    Maybe visiting a site would locally select the appropriate group that site was assigned to. For example, going to gmail.com would automatically use the "Google" Group. If a site is assigned to multiple groups, prompt the user to select a group. An unassigned site would use a default group, or create its own group for return visits, or create a temporary group.
    - x1798DE 10y ago
      Yes, this is what I was suggesting. Currently I am doing it manually, but if you can assign groups by site domain, it should feel much more seamless.

by neuland 10y ago

x1798DE 10y ago

I specifically meant in a browser. I'm certainly planning on looking into Qubes for an OS, but this is really more of a problem with data leaking within a browser, I don't think the OS has much say in that.

neuland 10y ago
Well, you'd ideally create different VMs for where you want barriers to data leak-age via cookies, history, session- + localstorage, and loading assets/scripts/etc from or making requests cross domain to 3rd parties. But to your point, even within a given browser/VM/whatever that I intend on using for a single task. I'd still eventually end up slipping up and going to a site that should have been in a different group or logging into something that I wanted in an ephemeral group. There is a real problem currently with data sharing on the web, where it's pretty much all or nothing. That'll still be true under the scheme you mention, just the goalpost will be moved to within whatever grouping scheme you pick. It seems there isn't a good way to allow sites to do useful things like ajax to lots of services not on the same domain, while preventing the site provider from sharing your data with people you don't want to have it. Ad- and tracker- blockers alleviate some of this by preventing certain undesired code from running and thus sharing data. But, user tracking is still possible (and used to actually happen by) using server-side logging and shipping info to 3rd parties. Ultimately, we are relying on the people or organization behind a site to not share our data. And, yes the tools could get a bit better with grouping/profiles. But, the vast majority of users won't use these tools. And, even if you use them, you have to be diligent in only opening certain sites in certain "groups" and/or managing which group you are logging into your account in. So, features like this always will be niche unless there is a revolutionary shift in users' technical ability and attitude towards data protection / privacy.
- Jarwain 10y ago
  Maybe visiting a site would locally select the appropriate group that site was assigned to. For example, going to gmail.com would automatically use the "Google" Group. If a site is assigned to multiple groups, prompt the user to select a group. An unassigned site would use a default group, or create its own group for return visits, or create a temporary group.
  - x1798DE 10y ago
    Yes, this is what I was suggesting. Currently I am doing it manually, but if you can assign groups by site domain, it should feel much more seamless.