New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable tracking cookie? #40

Open
ziburski opened this Issue May 25, 2018 · 16 comments

Comments

Projects
None yet
@ziburski
Copy link

ziburski commented May 25, 2018

Hi,

is there a way to disable the tracking cookie completely? I’m not really interested in the returning visitor metric and would prefer to avoid tracking users completely.

Generally, with privacy being a focus for Fathom, it might be nice to have a list (or even a choice) of what exactly is tracked, how it is tracked, and for how long it is stored.

Cheers!

@dannyvankooten

This comment has been minimized.

Copy link
Collaborator

dannyvankooten commented May 28, 2018

Hey @ziburski,

That list is definitely on the list - but let me quickly summarise it here right now too as not much is tracked at all:

  • No personally identifiable information is tracked.
  • Each pageview entry is stored for a theoretical maximum of 30 minutes, but nothing is stored that could lead back to the visitor generating that entry.

The pageviews table looks like this:

id hostname page new_visitor new_session unique_pageview bounce referrer timestamp
abc http://site.com /about 0 0 1 0 2018-07-11 12:49:04
def http://site.com /about 0 0 0 0 2018-07-11 12:49:04
ghi http://site.com / 0 0 1 1 2018-07-11 12:49:04
  • When you visitor more than one page on a site that uses Fathom, data about the previous pageview is removed within 1 minute.
  • When you don't visit any more pages, data about your pageview is removed after 30 minutes.

Now the interesting part is that Fathom can only store this little information about your visitors because of the "tracking" cookie. Basically we use the visitor's browser as a storage for all visitor-specific information so that we don't have to store it on your server.

I think we may be able to offer the option to not use the tracking cookie but besides slightly simplifying your cookie policy, I'm not too sure on the actual benefits of this to be honest.

@ziburski

This comment has been minimized.

Copy link
Author

ziburski commented May 31, 2018

Thanks for the thorough explanation, that sounds very reasonable.

Ultimately, I would just love a solution where you don’t need any cookie notices, user consent, or opt-out buttons. The trade-off in UX and effort just isn’t worth it to me, especially for small websites with no existing cookie policy. For users, it’s hard to tell the difference between cookies that protect your privacy and ones that sell you out.

GDPR shouldn’t be a problem for Fathom since it doesn’t track personal data. But the EU cookie law still applies right now, doesn’t it?

@psykzz

This comment has been minimized.

Copy link

psykzz commented Jun 12, 2018

EU's Cookie policy requires giving users the option to opt out of cookies that are use for analytical /
advertising / social tracking individually.

@da2x

This comment has been minimized.

Copy link
Contributor

da2x commented Jun 13, 2018

I'm not a lawyer. This isn't legal advice.

There is no "EU cookie law". The ePrivacy Directive has been interpreted and implemented completely differently by every member state. Some require opt-in before any use of cookies, some require that users are presented with an opt-out, some say that browser settings are enough, ... . You have to comply with the local regulation where your business is based.

The current drat of the ePrivacy Regulation, expected in 2018-Q3, streamlines all of this and say websites must comply with the GDPR (no personal data without opt-in), provide information about cookies, and then align every country with the "browser settings interpretation". Fathom already supports the Do-Not-Track setting and related APIs for site-specific exceptions. Fathom already supports cookie settings as set in the browser. Website publishers just need to document cookie usage and avoid recording any personal data (including username in URLs, etc.).

@dannyvankooten maybe add a FAQ section on usefathom.com?

@ckluis

This comment has been minimized.

Copy link

ckluis commented Jun 13, 2018

Adding a "cookie notice" directly into fathom would allow for a single script inclusion instead of wrapping fathom inside another cookie notice inclusion script. The do-not-track setting doesn't remove the need to request consent from users.

@da2x

This comment has been minimized.

Copy link
Contributor

da2x commented Jun 13, 2018

Not a lawyer. Not legal advice.

Wouldn’t that lead to duplicate cookie-notice-notices?

There is no single cookie notice that covers all the different local interpretations of the ePrivacy Directive. E.g. in Norway, you don’t even need to display a cookie notice at all! You just need to have all the details in a human-readable way in your privacy policy. For what it’s worth, the current draft for the upcoming ePrivacy Regulation removes ambiguity and uses the Norway-interpretation everywhere. So there won’t be any reason to include a cookie notice anymore. Data collection and sharing about individuals (something Fathom doesn’t do) will still require opt-in consent (and not just a notice) to comply with the General Data Protection Regulation.

While we wait for the ePrivacy Regulation, websites have to comply with their local laws which are based on local adaptations of the ePrivacy Directive. Requirements varies greatly from country to country. There is no single notice that works for every European country. So, … the best thing for Fathom to do is to sit and wait on the ePrivacy Regulation.

In summary:

  • websites must update their privacy policies, display notices, provide opt-out, or require explicit opt-ins as required by local laws.

Fathom’s job in all of this is to inform publishers what data is collected and how, so that publishers know what to include in their privacy policies and notification mechanisms (when required).

@ckluis

This comment has been minimized.

Copy link

ckluis commented Jun 14, 2018

I think you could increase adoption dramatically if you provided the cookie notification tracking directly. Don't get me wrong - I'll probably use something like https://github.com/snipsco/yett and put the two together, but at the very least providing an integrated solution could be a "Pro" or "Subscription" tier if you want to go down that route.

@ziburski

This comment has been minimized.

Copy link
Author

ziburski commented Jun 14, 2018

All the discussion about what constitutes a proper cookie notice seems to validate my suggestion of having the option to remove cookies from Fathom completely.

If Fathom makes tracking simple, I shouldn’t have to read through legal documents from different countries so that I can write a privacy policy that may or may not hold up. I just want to track page views, without making the experience worse for me or my users.

@dannyvankooten

This comment has been minimized.

Copy link
Collaborator

dannyvankooten commented Jul 4, 2018

Agree, but we should also not rule out an entire (and valid) technology and actually go against the intent of the law by making privacy worse.

Without the cookie, Fathom would have to store a whole lot more information about your visitors to get to the data we actually care about. In this case, a cookie (and the same applies to other client-side storage mechanisms) is the most privacy friendly option out there and probably therefore the easiest method to comply with the law.

That all said, we are drafting up an article explaining our stance and what clarifying what is needed to install Fathom on your own site. I'll be updating this issue as soon as we have done some proper research.

@driv3r

This comment has been minimized.

Copy link

driv3r commented Oct 9, 2018

just an idea - what if it would be possible to make the cookie storage as an adapter? I was thinking, and have a working draft, that you could just store the information in the global variable, which will then hold the info during single real "page view". Today when most of the websites are SPAs, or static pages using tools like turbolinks, the page is never reloaded, thus you can see if user is browsing through the website, within single "page view".

I think it's a good compromise between privacy notices, counts of returning visits and keeping tracking js simple. WDYS?

@laander

This comment has been minimized.

Copy link

laander commented Jan 29, 2019

@driv3r Good suggestion, but without any type of session tracking between reloads (client or server side), a browser reload would track as a new visitor.

In some cases, for SPAs, that might be acceptable, but for classic websites you'd end up with an extremely inflated visitors count. The option could be provided as an optional flag though, but I still don't think the trade-off is worth it.

@jlelse

This comment has been minimized.

Copy link

jlelse commented Jan 31, 2019

Currently Fathom shows information about page views, unique visitors and referrers. Without cookies page views and referrers should be possible and losing information about unique visitors is probably worth out when you just want to see which pages are most visited.

@jhabdas

This comment has been minimized.

Copy link

jhabdas commented Feb 2, 2019

I don't believe there should be an adapter here—there simply shouldn't be a cookie.

Cookies are sent with all requests to the origin, so images etc will be collected once the cookie is placed – that could be a problem if a proxy or MitM (read: CloudFlare) is used to secretly scrape and send data to DoubleClick et al.

Instead I'd suggest fathom use sessionStorage and please remove cookies at priority.

@dannyvankooten I saw the wontfix tag added to this issue. I read your explainer and feel you're trying to justify an architectural mistake. No offense, but if you don't intend to resolve this issue I'm confident someone else will—though GoAccess seems much more enticing to me know.


<iframe sandbox="allow-scripts allow-same-origin" title="Fathom Analytics Demo" width="100%" height="600" src="https://stats.usefathom.com/"></iframe>

Above is the minimum necessary for the fathom demo to function in a sandboxed iframe, at least from a display perspective. I have not tested or considered it (yet) extensively but I noticed – at least from demo – their CDN provider is setting cookies as well so that is something to take into account if you're iframing the demo and tell your users you're not using cookies on your site:

screen shot 2019-02-02 at 1 59 25 pm

(Note Gooogle Analytics used to be called Urchin and UTM stands for Urchin Tag Manager IIRC)

Note on the <iframe> tokens there's a setting allow-storage-access-by-user-activation which should allow cookies in a sandboxed iframe but it's not widely supported by browsers at the moment.


Further reading on why you shouldn't trust even the best of justifications for known intrusions:

@JackEllis

This comment has been minimized.

Copy link
Collaborator

JackEllis commented Feb 3, 2019

@jhabdas I don't think sessionStorage is a realistic solution here, as it empties as soon as you close the tab. This doesn't help with tracking unique visitors since each new tab would be a fresh sessionStorage. Personally, I'd rather not send the cookies on each request and I understand where you're coming from. I think that something like localStorage may end up being useful for this in the future.

@jhabdas

This comment has been minimized.

Copy link

jhabdas commented Feb 4, 2019

I think that something like localStorage may end up being useful for this in the future.

I'd settle for localStorage. There's just too much CloudFlare et al. can do with cookies these days despite our best attempts or good intentions. For instance, I just saw today the old Ledger Manager extension was doing a sidecar cookie off-domain for anyone visiting DevDocs.io (proof). Ugh.

If repeat visitor data is important to Fathom it would be nice to offer an cookie-free option for those of us who really want a privacy-focused analytics solution until HTTP3 starts tracking us at the protocol layer—as the OP dutifully requested during the GDPR rollout.

@EricKit

This comment has been minimized.

Copy link

EricKit commented Feb 9, 2019

Another reason for localStorage is for those using platforms such as Ionic on an iPhone where Safari runs in the app. Cookies are not stored so each page view is a new user and a new session.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment