Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-19 Thread Leo Gaspard
On 09/19/2017 02:23 PM, taii...@gmx.com wrote:> It is impossible to have
storage communication between VM's, that would
> be a separate security issue.
> On timing attacks or w/e - you may be able to avoid cross communication
> by putting every AppVM on a separate core of a many core CPU such as an
> Opteron 6386 (16 cores)

Putting every AppVM on a separate core of a many core CPU could help a
bit, but CPU's usually have separate L1, maybe L2 caches, but I don't
know of any CPU with a non-shared-between-cores L3 cache. So basing the
attack on timing the L3 cache may still work.

Then, here we're going pretty far in the sophisticated tracking
strategy, like “things currently being proposed at conferences,” so
maybe it's out of the threat model (or maybe not, depends on your threat
model).

As to browser fingerprinting, I'd personally rather use a distinct
distribution for the “anonymous” part, just to make timing updates (A
upgraded this day and B too and all their upgrades are always on the
same day that is not the one of the release of the distribution, thus
A=B) harder. Then, again it's against someone specifically targeting
you, I don't think qubes is widespread enough to make trackers even try
to perform such deductions (yet). That said this last sentence is just
gut feeling.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a4de7982-66ce-f472-dc48-7c0421efe056%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-19 Thread taii...@gmx.com
Well considering the OP is using gmail I think that this is the least of 
his worries.


If the browsers in two AppVM's are exactly the same then you can easily 
correlate them which is the whole point of browser fingerprinting, they 
will appear exactly the same to an observer.


It is impossible to have storage communication between VM's, that would 
be a separate security issue.
On timing attacks or w/e - you may be able to avoid cross communication 
by putting every AppVM on a separate core of a many core CPU such as an 
Opteron 6386 (16 cores)


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/12c2f07c-85c8-eedd-130b-acf5628a1e18%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-19 Thread rysiek
Dnia Monday, September 18, 2017 8:23:46 PM CEST Ted Brenner pisze:
> Not sure if Chromium is free of Google or not.

Me neither, but this does not build confidence:
https://bugs.chromium.org/p/chromium/issues/detail?id=500922
https://news.ycombinator.com/item?id=9724409

They fixed it soon after it was discovered, but sill.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1764884.RZTnbDx7hM%40lapuntu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread Ted Brenner
I thought I read somewhere that VMs make it harder to fingerprint using the
CPU, graphics card, etc. Did anyone else read that? That would be a feather
in Qubes's hat if true.

Any suggestions for a good anonymizing browser (besides the Tor browser of
course)? I would assume Firefox would have the most interest in that though
perhaps not as good. Not sure if Chromium is free of Google or not.

On Mon, Sep 18, 2017 at 4:47 PM,  wrote:

> Roger that, thank you Leo so it sounds as though Qubes ought to be up to
> snuff for all contemporary ad instustry practices that Google, Facebook,
> Doubleclick etc are liable to try but that Qubes + anonymizing browser is a
> better bet against more sophisticated tracking in case that were a concern.
>
> Great news. :)
>
> On Monday, September 18, 2017 at 2:39:34 PM UTC-7, Leo Gaspard wrote:
> > On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> > > Thank you Micah and Michał, but I am not actually asking about a
> standard as strong as 100% bulletproof anonymity or anything. I really am
> just concerned about whether any of the methods on that list that I linked
> to would be enough to leak cookie-like reference data between two separate
> Qubes security domains.
> >
> > Cookie-like reference data between two separate Qubes security domains
> > cannot happen. This would mean one VM is able to influence the hard disk
> > of another, which would be a vulnerability in Qubes.
> >
> > > Being tracked as I browse around *in* a given security domain is
> entirely my problem of course, and I understand that. My only concern is
> working to ensure that to an outside observer such as webservers and ad
> networks nothing short of the shared IP address (and via Tor or VPN or
> different IPs honestly allocated to different domains perhaps not even
> that) can act as a reliable indicator that web browsing activity in one
> Qubes security domain is "linked" to activity from another security domain
> via any secretly stored cookie-like reference identifiers that get somehow
> leaked across domains.
> >
> > What can however happen is things like hardware fingerprinting through
> > the browser, like CPU frequency measurements.
> >
> > Also, Qubes doesn't guarantee two VMs can't talk together, so if you
> > have at the same time a browser in two VMs in two websites they may be
> > able to talk together using such side channels (timing the cache,
> > ultra-low-level stuff like that).
> >
> > So even though supercookies and the like aren't shared in Qubes, if you
> > use an insufficiently anonymising web browser, a web site may be able to
> > fingerprint your hardware through the browser (Qubes/Xen does nothing to
> > prevent that for performance reasons), and then to link your hardware to
> > different identities you used to browse different pages in different VMs.
> >
> > I don't know of any website that would try to talk to others through
> > side-channels, but I seem to remember articles on hardware
> > fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
> > a few years back, so I guess against state-of-the-art tracking systems
> > Qubes will not be enough.
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/qubes-users/68d78695-e01b-43d8-807d-ca6e7b795531%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sent from my Desktop

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CANKZutxTRqEpj9JMkO0RQoAw3BrAQmXjBD4exUBBk3njkt_Vyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread jesset
Roger that, thank you Leo so it sounds as though Qubes ought to be up to snuff 
for all contemporary ad instustry practices that Google, Facebook, Doubleclick 
etc are liable to try but that Qubes + anonymizing browser is a better bet 
against more sophisticated tracking in case that were a concern.

Great news. :)

On Monday, September 18, 2017 at 2:39:34 PM UTC-7, Leo Gaspard wrote:
> On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> > Thank you Micah and Michał, but I am not actually asking about a standard 
> > as strong as 100% bulletproof anonymity or anything. I really am just 
> > concerned about whether any of the methods on that list that I linked to 
> > would be enough to leak cookie-like reference data between two separate 
> > Qubes security domains.
> 
> Cookie-like reference data between two separate Qubes security domains
> cannot happen. This would mean one VM is able to influence the hard disk
> of another, which would be a vulnerability in Qubes.
> 
> > Being tracked as I browse around *in* a given security domain is entirely 
> > my problem of course, and I understand that. My only concern is working to 
> > ensure that to an outside observer such as webservers and ad networks 
> > nothing short of the shared IP address (and via Tor or VPN or different IPs 
> > honestly allocated to different domains perhaps not even that) can act as a 
> > reliable indicator that web browsing activity in one Qubes security domain 
> > is "linked" to activity from another security domain via any secretly 
> > stored cookie-like reference identifiers that get somehow leaked across 
> > domains.
> 
> What can however happen is things like hardware fingerprinting through
> the browser, like CPU frequency measurements.
> 
> Also, Qubes doesn't guarantee two VMs can't talk together, so if you
> have at the same time a browser in two VMs in two websites they may be
> able to talk together using such side channels (timing the cache,
> ultra-low-level stuff like that).
> 
> So even though supercookies and the like aren't shared in Qubes, if you
> use an insufficiently anonymising web browser, a web site may be able to
> fingerprint your hardware through the browser (Qubes/Xen does nothing to
> prevent that for performance reasons), and then to link your hardware to
> different identities you used to browse different pages in different VMs.
> 
> I don't know of any website that would try to talk to others through
> side-channels, but I seem to remember articles on hardware
> fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
> a few years back, so I guess against state-of-the-art tracking systems
> Qubes will not be enough.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68d78695-e01b-43d8-807d-ca6e7b795531%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread Leo Gaspard
On 09/18/2017 09:27 PM, jes...@gmail.com wrote:
> Thank you Micah and Michał, but I am not actually asking about a standard as 
> strong as 100% bulletproof anonymity or anything. I really am just concerned 
> about whether any of the methods on that list that I linked to would be 
> enough to leak cookie-like reference data between two separate Qubes security 
> domains.

Cookie-like reference data between two separate Qubes security domains
cannot happen. This would mean one VM is able to influence the hard disk
of another, which would be a vulnerability in Qubes.

> Being tracked as I browse around *in* a given security domain is entirely my 
> problem of course, and I understand that. My only concern is working to 
> ensure that to an outside observer such as webservers and ad networks nothing 
> short of the shared IP address (and via Tor or VPN or different IPs honestly 
> allocated to different domains perhaps not even that) can act as a reliable 
> indicator that web browsing activity in one Qubes security domain is "linked" 
> to activity from another security domain via any secretly stored cookie-like 
> reference identifiers that get somehow leaked across domains.

What can however happen is things like hardware fingerprinting through
the browser, like CPU frequency measurements.

Also, Qubes doesn't guarantee two VMs can't talk together, so if you
have at the same time a browser in two VMs in two websites they may be
able to talk together using such side channels (timing the cache,
ultra-low-level stuff like that).

So even though supercookies and the like aren't shared in Qubes, if you
use an insufficiently anonymising web browser, a web site may be able to
fingerprint your hardware through the browser (Qubes/Xen does nothing to
prevent that for performance reasons), and then to link your hardware to
different identities you used to browse different pages in different VMs.

I don't know of any website that would try to talk to others through
side-channels, but I seem to remember articles on hardware
fingerprinting (esp. the cpu frequency and drift, iirc) through JS from
a few years back, so I guess against state-of-the-art tracking systems
Qubes will not be enough.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1720ec21-6433-8a0c-02bc-aeb17336fb8c%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread rysiek
Hey,

Dnia Monday, September 18, 2017 12:27:21 PM CEST jes...@gmail.com pisze:
> My only concern is working to ensure that to an outside observer such as
> webservers and ad networks nothing short of the shared IP address (and via
> Tor or VPN or different IPs honestly allocated to different domains perhaps
> not even that) can act as a reliable indicator that web browsing activity in
> one Qubes security domain is "linked" to activity from another security
> domain via any secretly stored cookie-like reference identifiers that get
> somehow leaked across domains.

Right.

> For example: if I browse to a Flash or Silverlight website using Browser X
> in my [untrusted] domain, would those plugins be able to store any kinds of
> LSOs or HTML5 local storage or cached E-tags or anything else deep enough
> into the system backend that they could pull them back out again in my
> [work] domain when I browse back to that same site again?
> (...)

As far as I understand, the answer for Qubes is "this should absolutely not 
happen", but the Qubes developers should probably weigh-in on that. I for one 
would find a "how deep does the rabbit-hole get here" discussion on this very 
informative.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3904660.0aLW21G1cK%40lapuntu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread jesset
Thank you Micah and Michał, but I am not actually asking about a standard as 
strong as 100% bulletproof anonymity or anything. I really am just concerned 
about whether any of the methods on that list that I linked to would be enough 
to leak cookie-like reference data between two separate Qubes security domains.

Being tracked as I browse around *in* a given security domain is entirely my 
problem of course, and I understand that. My only concern is working to ensure 
that to an outside observer such as webservers and ad networks nothing short of 
the shared IP address (and via Tor or VPN or different IPs honestly allocated 
to different domains perhaps not even that) can act as a reliable indicator 
that web browsing activity in one Qubes security domain is "linked" to activity 
from another security domain via any secretly stored cookie-like reference 
identifiers that get somehow leaked across domains.

For example: if I browse to a Flash or Silverlight website using Browser X in 
my [untrusted] domain, would those plugins be able to store any kinds of LSOs 
or HTML5 local storage or cached E-tags or anything else deep enough into the 
system backend that they could pull them back out again in my [work] domain 
when I browse back to that same site again?

>From a differential diagnostic perspective, I know that running two COMPLETELY 
>separate VMs via XenServer et al with completely separate OSen and completely 
>separate installs of the same browser and Flash plugin — where they don't even 
>view a single shred of the same filesystem — should be safe from any industry 
>standard client tracking data (EG, short of malware like Bluepill or direct 
>exploits against the incumbent hypervisor) leaking between said domains.

However two different browsers on the same computer/OS combo, such as Firefox 
and Opera, might get Flash installed via the same process which gives the Flash 
plugin on both browsers access to the same LSO store squirreled away somewhere.

So I'm just trying to confirm how close to case 1 Qubes security domains rate, 
even when you are still only installing the OS, the browser, and the Flash 
plugin once for use by both light VMs.

I hope this helps to clarify my inquiry, thank you!

- - Jesse

On Monday, September 18, 2017 at 11:02:31 AM UTC-7, rysiek wrote:
> Dnia Monday, September 18, 2017 10:56:33 AM CEST Micah Lee pisze:
> > Qubes security domains don't necessarily help solve this problem because
> > really the problem is how your web browsers are configured.
> > 
> > So a tracking company can't link your browsing activity between Qubes
> > domains -- your "personal" traffic and "work" traffic might look like
> > two separate people -- but within one of those domains, they can still
> > track you, and do all of those tricks.
> > 
> > If you want web privacy, you'll have to configure your browser within
> > Qubes the same way you have to outside of Qubes. Or, you can do all of
> > your browser in DisposableVMs. Or use Tor Browser, which has taken many
> > steps to prevent browser tracker as a design goal.
> 
> Damn, beat me to it!
> 
> -- 
> Pozdrawiam,
> Michał "rysiek" Woźniak
> 
> Zmieniam klucz GPG :: http://rys.io/pl/147
> GPG Key Transition :: http://rys.io/en/147

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/299c63e1-3e81-408b-a0cb-7c4fedfc7843%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread rysiek
Dnia Monday, September 18, 2017 10:56:33 AM CEST Micah Lee pisze:
> Qubes security domains don't necessarily help solve this problem because
> really the problem is how your web browsers are configured.
> 
> So a tracking company can't link your browsing activity between Qubes
> domains -- your "personal" traffic and "work" traffic might look like
> two separate people -- but within one of those domains, they can still
> track you, and do all of those tricks.
> 
> If you want web privacy, you'll have to configure your browser within
> Qubes the same way you have to outside of Qubes. Or, you can do all of
> your browser in DisposableVMs. Or use Tor Browser, which has taken many
> steps to prevent browser tracker as a design goal.

Damn, beat me to it!

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2241560.q67QAilk6l%40lapuntu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread rysiek
Hey,

Dnia Monday, September 18, 2017 9:43:15 AM CEST jes...@gmail.com pisze:
> In the past I have used a Firefox plugin called "Better Privacy" to try to
> push back against multi-front user fingerprinting and analysis mechanisms
> such as the kind used by large advertising and user demographics companies
> which include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et
> al to confirm that the same user is browsing along a website or a
> distributed ad network even when they "clear private data" or use incognito
> mode, even when they switch to different browsers installed on the same
> machine, even if they're using coffee shop wifi or VPNs so that they appear
> from different IP addresses, etc.
> (...)

O..k. Straight from the bat, why not Incognito/Private window?

I mean, on my non-Qubes system I have a "work" browser (a normal Firefox 
window, keeping sessions, accepting cookies, etc); and a "fun" browser 
(Chromium Incognito) for everything that I am concerned might track me.

On Qubes, the disposable VM is probably what you're after. But remember, even 
in an incognito window or in a disposable VM, you can be tracked as long as 
the session lasts (i.e. until you close the browser, or reboot the VM).

> So I am curious to what extent Qubes security domains may be sufficiently
> complete as to defeat potentially all of these mechanisms simultaneously?
> Especially if end-user configures one or more domains to pipe all network
> traffic over a VPN or tor to additionally differentiate their IP address?

Most of these mechanisms are browser-bound. Use the browser in your disposable 
VM. Using it through a VPN or Tor is a good idea too.

> I am especially interested to hear about how Qubes security domains interact
> with Flash LSOs, and .. whatever-it-is that Silverlight and other
> multi-browser plugins do, and whether *that* data leaks between domains. :/

Think of each AppVM as a separate machine yoiu're running stuff on. Flash/
Silverlight/etc do not have a way to break out of a VM.

> Thank you for any insight you guys may have on this matter, as it sounds
> like it speaks directly to Qubes primary mission goals of security by
> compartmentalization. :D

Compartmentalization does not do much for anonymity. As in, you can use Qubes, 
and be tracked through each of your AppVMs. You'll have three "identities", 
but all of them will be tracked, since regular AppVMs keep state (including 
browser cookies, etc, unles sthe browser is explicitly configured otherwise).

To combat tracking, I would use the Incognito/Private mode in your browser, or 
a browser in a disposable VM in Qubes. Or both.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3563889.KxQ3rpsauL%40lapuntu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part.


Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread Micah Lee
Qubes security domains don't necessarily help solve this problem because
really the problem is how your web browsers are configured.

So a tracking company can't link your browsing activity between Qubes
domains -- your "personal" traffic and "work" traffic might look like
two separate people -- but within one of those domains, they can still
track you, and do all of those tricks.

If you want web privacy, you'll have to configure your browser within
Qubes the same way you have to outside of Qubes. Or, you can do all of
your browser in DisposableVMs. Or use Tor Browser, which has taken many
steps to prevent browser tracker as a design goal.


On 09/18/2017 09:43 AM, jes...@gmail.com wrote:
> In the past I have used a Firefox plugin called "Better Privacy" to try to 
> push back against multi-front user fingerprinting and analysis mechanisms 
> such as the kind used by large advertising and user demographics companies 
> which include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et 
> al to confirm that the same user is browsing along a website or a distributed 
> ad network even when they "clear private data" or use incognito mode, even 
> when they switch to different browsers installed on the same machine, even if 
> they're using coffee shop wifi or VPNs so that they appear from different IP 
> addresses, etc.
> 
> The take home being that it only takes one (1) fingerprint hit through one 
> (1) of the avenues available to tracking organizations to confirm that they 
> are dealing with the same end-user (or household unit, or something close 
> enough to pad their toxic dossier with) and thus to link every cookie 
> fingerprint that they know for this user across both domains under the same 
> umbrella.
> 
> A pretty thorough look at all of the strategies that I am at least aware of 
> can be had at this url: 
> https://www.chromium.org/Home/chromium-security/client-identification-mechanisms
> 
> So I am curious to what extent Qubes security domains may be sufficiently 
> complete as to defeat potentially all of these mechanisms simultaneously? 
> Especially if end-user configures one or more domains to pipe all network 
> traffic over a VPN or tor to additionally differentiate their IP address?
> 
> I am especially interested to hear about how Qubes security domains interact 
> with Flash LSOs, and .. whatever-it-is that Silverlight and other 
> multi-browser plugins do, and whether *that* data leaks between domains. :/
> 
> Thank you for any insight you guys may have on this matter, as it sounds like 
> it speaks directly to Qubes primary mission goals of security by 
> compartmentalization. :D
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3e9cdccf-488c-fa1e-2bf0-b70c835108c5%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this

2017-09-18 Thread jesset
In the past I have used a Firefox plugin called "Better Privacy" to try to push 
back against multi-front user fingerprinting and analysis mechanisms such as 
the kind used by large advertising and user demographics companies which 
include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et al to 
confirm that the same user is browsing along a website or a distributed ad 
network even when they "clear private data" or use incognito mode, even when 
they switch to different browsers installed on the same machine, even if 
they're using coffee shop wifi or VPNs so that they appear from different IP 
addresses, etc.

The take home being that it only takes one (1) fingerprint hit through one (1) 
of the avenues available to tracking organizations to confirm that they are 
dealing with the same end-user (or household unit, or something close enough to 
pad their toxic dossier with) and thus to link every cookie fingerprint that 
they know for this user across both domains under the same umbrella.

A pretty thorough look at all of the strategies that I am at least aware of can 
be had at this url: 
https://www.chromium.org/Home/chromium-security/client-identification-mechanisms

So I am curious to what extent Qubes security domains may be sufficiently 
complete as to defeat potentially all of these mechanisms simultaneously? 
Especially if end-user configures one or more domains to pipe all network 
traffic over a VPN or tor to additionally differentiate their IP address?

I am especially interested to hear about how Qubes security domains interact 
with Flash LSOs, and .. whatever-it-is that Silverlight and other multi-browser 
plugins do, and whether *that* data leaks between domains. :/

Thank you for any insight you guys may have on this matter, as it sounds like 
it speaks directly to Qubes primary mission goals of security by 
compartmentalization. :D

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2c1d96d1-14f9-4522-b4e1-169da312e756%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.