61–70 of 524 posts
Earlier quoted context omitted.
This would be one of the things about IPv6, we'd have lifetime fixed IP addresses (or address ranges at least). Wouldn't we?
DHCP and NAT are perfectly compatible with IPv6.
If you don't pay attention to it you might be surprised how non dynamic your residential internet last mile DHCP assigned IP really is. It's not uncommon to go many months or a year with having it always renew to the same address. That, combined with all the fingerprinting mentioned in the article...
> For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time.
It is interesting that the site can fingerprint individual profiles/dir easily: For example chromium-browser --user-data-dir=/tmp/profile_A chromium-browser --user-data-dir=/tmp/profile_A --incognito chromium-browser --user-data-dir=/tmp/profile_B chromium-browser --user-data-dir=/tmp/profile_B --incognito For each command + its incognito it can detect them as separate profiles. For ultimate privacy one needs to ever…
Earlier quoted context omitted.
It’s a double edged sword you need to walk the edge of. Almost everything they use to fingerprint you has a fully legitimate use case which is why it was added. The more you do to prevent fingerprinting the more you hobble the web as a platform. A lot of restrictions that got placed on the canvas tag to help prevent fingerprinting for instance really limited its functionality. In my opinion a workable solution would…
Most of those APIs should be default closed. Incognito should definitely be default closed.
Unfortunately, much of that signal persists across sessions as well as websites and can therefore be aggregated into a hash that works as a "super cookie". The signal is based on the device, the connection, not so much the HTTP/HTML you're looking at.
The best approach to mitigate is therefore: adding noise: add random gibberish to User-Agent, tunnel IP though VPN/NAT, lie about codecs or screen resolution.
While that degrades user experience, it give no guarantees to actually preventing fingerprinting. So, the good news, if that fingerprinting is hard too, and doesn't work as well as is usually claimed!
Surely if your website collects data using browser fingerprinting this is covered by GDPR and you have to tell your visitors/ask for permission? https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-finge...
I have five different browsers on my smartphone and three on the PC all sans JS and none of them are Chrome. Also, normal operation is to automatically delete all cookies at session's end.
My smartphone and PCs are de-googleized and firewalled and I never see ads in my browsers nor in apps. The apps are mainly from F-Droid and sans ads and the few Playstore ones I use are via Aurora Store and are firewalled from the internet when in use. Honestly, I cannot remember when I last saw an app display an ad, it has to be years back.
In the past I used to go to more extensive measures to stop the spying but I found it was unnecessary as the spy leakage was essentially negligible with much less stringent efforts.
It's pretty easy to render one's online personal data essentially wothlesss if one wants to. On the other hand if you insist on using JS, Gmail, Google search, Facebook etc. then you're fair game and you only have yourself to blame if your personal data is stolen.
Look, forget about threat models. It's relatively trivial these days to avoid fingerprinting attacks if you want to (as a private, web browsing individual). I use fingerprinting actively in enterprise apps as a form of silent 3FA. It's a useful backstop. If I have a user who forgot their password but retrieves it via email, I'll usually let them pass if their fingerprint matches one of their priors; otherwise my soft…