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 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?

--
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 email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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.

[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

[Florian Apolloner]

On Monday, November 26, 2018 at 10:28:07 AM UTC+1, Mat Gadd wrote:

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.

[René Fleschenberg]

Hey,

I ran into this today. I am reusing the password reset views for user
signup, so it affects me quite heavily :)

No idea if it is going to be of any use, but I sent a report on
https://www.apple.com/feedback/safari.html with links to your ticket and
this discussion.

I will try to get my hands on a Mac for further debugging soon.

Cheers,
René

[Perry Roper]

It would appear that this affects a large number of users. We're also experiencing this in the following configurations.

- Mailgun click tracking enabled + Safari 12.0 on MacOS or any browser in iOS 12

- Clicking the link in the Gmail app or web app (Mailgun click tracking disabled) + Safari 12.0 on MacOS or any browser in iOS 12.

All iOS 12 browsers and MacOS Safari users using the Gmail app, or in any email client if the site they are requesting a password from uses link tracking.

[Mat Gadd]

We're also now seeing Gmail users complain that the password reset links don't work, even after we disabled click tracking. It seems that Google are inserting their own click tracking into users' emails, which is… weird?

The markup of links is transformed to the following (where … is our original URL):

<a href="…" target="_blank" data-saferedirecturl="https://www.google.com/url?q=…">Link text here</a>

Gmail is a *huge* provider of emails, and they make up around 54% of our user base. Anyone using the Gmail web app can no longer reset their password simply by clicking the link in the email. 

[Philip James]

Mat, are you saying you're seeing Safari still blocking, even with click tracking turned off, because GMail itself is inserting a redirect?

PJJ

http://philipjohnjames.com

--

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 email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com.

[Mat Gadd]

Exactly that, yes. We've disabled all click tracking that we can, but Gmail has its own redirect which causes Safari's privacy features to kick in. (Some?) Gmail users are unable to use the password reset emails.

[Mat Gadd]

You can see this in action yourself using Chrome's Dev Tools. Open Dev Tools, then their Settings, and turn on "Auto-open DevTools for popups". Then, click any link in the Gmail web app. You'll see you go via google.com/url?q=original_url_here. Since they're doing this with JavaScript, the links look like they're going to open the real URL, but they don't.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2830288b-6890-4c2f-ac4c-b07a82196619%40googlegroups.com.

[Henrik Ossipoff Hansen]

Just wanted to chime in and say we also experienced this issue. We ended up having to revert the security fix that was added to the view in Django just to avoid the flood of customers reporting they couldn't reset their passwords on our apps anymore - so I'm assuming this affects a lot of users out there.

[Collin Anderson]

I wouldn't mind just rolling back the security fix (or maybe making a straightforward way to enable/disable the behavior). We could instead encourage people to use <a rel="noreferrer"> on any links (from the password rest page) to untrusted urls.

[Curtis Maloney]

On 2/23/19 7:35 AM, Collin Anderson wrote:
> I wouldn't mind just rolling back the security fix (or maybe making a
> straightforward way to enable/disable the behavior). We could instead
> encourage people to use <a rel="noreferrer"> on any links (from the
> password rest page) to untrusted urls.

I don't think it would be controversial to add the rel="noreferrer" part
to the docs no matter what choice we make about the other functionality.

--
Curtis

> On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen
> wrote:
>
> Just wanted to chime in and say we also experienced this issue. We
> ended up having to revert the security fix that was added to the
> view in Django just to avoid the flood of customers reporting they
> couldn't reset their passwords on our apps anymore - so I'm assuming
> this affects a lot of users out there.
>
> torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:
>
> You can see this in action yourself using Chrome's Dev Tools.
> Open Dev Tools, then their Settings, and turn on "Auto-open
> DevTools for popups". Then, click any link in the Gmail web app.
> You'll see you go via google.com/url?q=original_url_here

> <http://google.com/url?q=original_url_here>. Since they're doing

> this with JavaScript, the links look like they're going to open

> the real URL, but they /don't./

> <https://code.djangoproject.com/ticket/29975> regarding

> <https://groups.google.com/group/django-developers>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com

> <https://groups.google.com/d/msgid/django-developers/c10f608f-7f5e-4bba-aa89-4779e37d61f0%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit
> https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> 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 email to django-develop...@googlegroups.com.
> To post to this group, send email to
> django-d...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/django-developers

> <https://groups.google.com/group/django-developers>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/2830288b-6890-4c2f-ac4c-b07a82196619%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2830288b-6890-4c2f-ac4c-b07a82196619%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> 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 email to django-develop...@googlegroups.com

> <mailto:django-develop...@googlegroups.com>.

> To post to this group, send email to django-d...@googlegroups.com

> <mailto:django-d...@googlegroups.com>.

> 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/0abe13ed-f95f-4f87-ba5c-9079f5ad17bf%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0abe13ed-f95f-4f87-ba5c-9079f5ad17bf%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Florian Apolloner]

Hi Collin,

it is not (just) about links, it is mainly about stylesheets/js. But we can set a header on that view: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy This should work for every browser != IE/Edge.

Cheers,

Florian