SameSite with Clojure Collector

1

Hello Snowplow Community,

I’m sorry if there is already a post for it, but so far I haven’t found anything related.

We are currently trying to find a solution to the SameSite Issue for the snowplow 3rd party cookie that comes with the upcoming Chrome release (link below). We have set up the Clojure collector on AWS Beanstalk and are currently using the javascript tracker.
The collector is running on its own domain and is used by multiple sites of ours.

The Clojure collector sets a 3rd party cookie named sp, which contains the user id, if I’m not mistaken.
But the current chrome version already warns that this won’t work with the upcoming release.

A cookie associated with a cross-site resource at http://our-tracking-domain.com was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at Chrome Platform Status and Chrome Platform Status.

I have tried to find out if we can simply set the SameSite attribute to None, but I have not found any documentation related to it. As far as I have seen there is only an option for the Scala collector that was introduced with R116 (https://snowplowanalytics.com/blog/2019/09/12/snowplow-r116-madara-rider/#cookie-attr).

How can we set the SameSite attribute for the cookie when using Clojure? Is that even possible at this point?
Are there any alternatives to it?

And here is the link for the chrome release: Chromium Blog: Developers: Get Ready for New SameSite=None; Secure Cookie Settings

Thanks a lot!
Philip

2

Hi @wege_philip,

The Clojure collector & the Elastic Beanstalk-backed pipeline are quite old tech now - Amazon are deprecating support for EB in fact, which has led us at Snowplow begin to phase the Clojure collector out of support - there’s a detailed post form Yali here, which might be useful in understanding the associated decisions.

The Scala collector does indeed have these features, but they’re not planned for Clojure collector. I think the best thing to do to handle the changing cookie landscape, and to future-proof your stack, is to look into an upgrade.

There are some people in the community with experience of this kind of upgrade, so I’m optimistic that we’ll be able to help you get your head around that process if it’s the route you do go for!

Best,

3

Amazon aren’t deprecating support for Elastic Beanstalk entirely - just Tomcat 8.0 (which the Clojure collector) on 1st March 2020. There’s a list of the other platforms / versions being deprecated here.

1 Like
4

Thanks for pointing that out, I wasn’t aware of that. I guess we have to look into the setup of the Scala collector then. Are there any upgrade articles or best practices that we can follow through? Or should we simply follow the wiki?

Also maybe it makes sense to put that information into the wiki (https://github.com/snowplow/snowplow/wiki/Setting-up-a-collector) so that people won’t start setting up Clojure anymore.

Thanks for your help!

5

Thanks for the clarification Mike, my bad on that one - the details were hazy but yes, it’s tomcat 8 support that’s the sticking point, & our planned deprecation of batch is the real consideration as to why we’re not evolving the Clojure collector to handle this.

@wege_philip I don’t know of a specific upgrade guide, but Dilyan’s comment here might be helpful for general strategy (it’s for GCP but same principles apply).

Also maybe it makes sense to put that information into the wiki (Setting up a Collector · snowplow/snowplow Wiki · GitHub) so that people won’t start setting up Clojure anymore.

Good point, I’ll raise this, thanks for pointing that out!

6

Hi @wege_philip we’ve just posted a guide with the steps required to perform the upgrade:

1 Like
7

Hi @PaulBoocock, thanks for sharing!
I will look into it.

8

Am I right in thinking that the impact of this will be to break the network_userid (which is set by collector), but domain_userid (which is set by the JS tracker) will continue to function?

9

Hi @iain
That is correct. It will cause the clojure collector to generate a new network_userid for all requests that don’t include the cookie.
So if you are counting users via the network_userid then this number will become inflated once Chrome roll out these changes.