Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Mat Gadd]

Hi all,

I raised a ticket <https://code.djangoproject.com/ticket/29975> regarding
this and was directed here to discuss the topic. The summary is that the
combination of using click-tracking redirects (which are popular with a
variety of email providers) with the Django contrib.auth password reset
views does not work in Safari on macOS and iOS as of the latest major
versions.

It took me quite a long time to work out what was happening, so I wanted to
at least raise a ticket where other people might find it, but was also
hoping to start a discussion around how else the problem could be
mitigated. An option to disable the internal token redirect might be
useful, but that then re-opens the token up to being leaked via the
HTTP_REFERER header.

Regards,
- Mat

[Adam Johnson]

It sounds to me that this your email provider rewriting the link to go
through their tracking site, and Safari now blocks the tracking site. I
don't see how Django can do anything around this - the "internal token
redirect" (which I guess means a Django generated redirect from one page to
another on your site) is going to be after going through the tracking site,
no?

Post by Mat Gadd
Hi all,
I raised a ticket <https://code.djangoproject.com/ticket/29975> regarding
this and was directed here to discuss the topic. The summary is that the
combination of using click-tracking redirects (which are popular with a
variety of email providers) with the Django contrib.auth password reset
views does not work in Safari on macOS and iOS as of the latest major
versions.
It took me quite a long time to work out what was happening, so I wanted
to at least raise a ticket where other people might find it, but was also
hoping to start a discussion around how else the problem could be
mitigated. An option to disable the internal token redirect might be
useful, but that then re-opens the token up to being leaked via the
HTTP_REFERER header.
Regards,
- Mat
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Adam

[Florian Apolloner]

I guess it would help to know how Safari's tracking protection does work (I
do not own a Mac) -- it seems hard to imagine that an internal redirect on
a page triggers the protection. In that sense it seems more like a
ISP-problem like Adam pointed out.

Post by Adam Johnson
It sounds to me that this your email provider rewriting the link to go
through their tracking site, and Safari now blocks the tracking site. I
don't see how Django can do anything around this - the "internal token
redirect" (which I guess means a Django generated redirect from one page to
another on your site) is going to be after going through the tracking site,
no?

Post by Mat Gadd
Hi all,
I raised a ticket <https://code.djangoproject.com/ticket/29975>
regarding this and was directed here to discuss the topic. The summary is
that the combination of using click-tracking redirects (which are popular
with a variety of email providers) with the Django contrib.auth password
reset views does not work in Safari on macOS and iOS as of the latest major
versions.
It took me quite a long time to work out what was happening, so I wanted
to at least raise a ticket where other people might find it, but was also
hoping to start a discussion around how else the problem could be
mitigated. An option to disable the internal token redirect might be
useful, but that then re-opens the token up to being leaked via the
HTTP_REFERER header.
Regards,
- Mat
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Adam

[Mat Gadd]

Hi both,

Adam, you're right that the email provider is rewriting the URLs to point
to their server which then redirects to our site. The contrib.auth module
then performs *another* redirect which appears to cause the privacy feature
to kick in. If Django didn't perform a redirect then it would work as
expected. As-is, the cookie that is attempted to be set before the redirect
is thrown away by Safari and the user sees a message that their token is
invalid.

Florian, it's not strictly an "internal redirect on a page", but the
combination of being bounced from a different domain to our site, and their
our site immediately performing its own redirect. If the links were
directly to our server, I don't believe this issue would occur.

Regards,
- Mat

Post by Florian Apolloner
I guess it would help to know how Safari's tracking protection does work
(I do not own a Mac) -- it seems hard to imagine that an internal redirect
on a page triggers the protection. In that sense it seems more like a
ISP-problem like Adam pointed out.

Post by Adam Johnson
It sounds to me that this your email provider rewriting the link to go
through their tracking site, and Safari now blocks the tracking site. I
don't see how Django can do anything around this - the "internal token
redirect" (which I guess means a Django generated redirect from one page to
another on your site) is going to be after going through the tracking site,
no?

Post by Mat Gadd
Hi all,
I raised a ticket <https://code.djangoproject.com/ticket/29975>
regarding this and was directed here to discuss the topic. The summary is
that the combination of using click-tracking redirects (which are popular
with a variety of email providers) with the Django contrib.auth password
reset views does not work in Safari on macOS and iOS as of the latest major
versions.
It took me quite a long time to work out what was happening, so I wanted
to at least raise a ticket where other people might find it, but was also
hoping to start a discussion around how else the problem could be
mitigated. An option to disable the internal token redirect might be
useful, but that then re-opens the token up to being leaked via the
HTTP_REFERER header.
Regards,
- Mat
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Adam

[Florian Apolloner]

Post by Mat Gadd
Florian, it's not strictly an "internal redirect on a page", but the
combination of being bounced from a different domain to our site, and their
our site immediately performing its own redirect. If the links were
directly to our server, I don't believe this issue would occur.

Interesting, are there any docs on this feature?

[Mat Gadd]

Ah, I forgot to include it here, sorry – it's on the ticket linked in my
original message:

[
] "Protection Against First Party Bounce Trackers" feature of Safari on
macOS and iOS, as ​described on the WebKit blog
<https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/>.

Post by Florian Apolloner

Post by Mat Gadd
Florian, it's not strictly an "internal redirect on a page", but the
combination of being bounced from a different domain to our site, and their
our site immediately performing its own redirect. If the links were
directly to our server, I don't believe this issue would occur.

Interesting, are there any docs on this feature?