1547905 - slideshare - A Download window is opened when accessing the site

Status: RESOLVED FIXED

(Web Compatibility :: Privacy: Site Reports, defect, P1)

Description

[Karl Dubost💡 :karlcow]

1. Navigate to: https://www.slideshare.net/

Expected Behavior:
The site is opened.

Actual Behavior:
The site is opened and a Download window is opened.

The issue is not reproducible on Chrome.

After running mozregression we get
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a48759a33738d8b5f4ad4659115e8bbd1e608c31&tochange=3e2b52df8b24f0faf0b1a1f7a32cd8040e53e240

I wonder if it depends on Bug 1499442 or Bug 1492563

If I deactivate Content Blocking for the site I get the right behavior.
Ah Maybe it is Bug 1492563

Let's see.

Comment 1

[Daniel Veditz [:dveditz]]

Karl: I can't reproduce it in Nightly (68), neither can :jkt, but apparently he can reproduce in 66. Do we need to figure out what fixed this an uplift to a last minute Beta or is that good enough? It's probably too late to fix anything non-urgent in 67 anyway.

Comment 2

[Karl Dubost💡 :karlcow]

Attachment: browser window with the save dialog

Daniel, I still can reproduce in Firefox Nightly 68.0a1 (2019-04-30) (64-bit) on macos.

1. With a Fresh profile in Nightly (I really mean fresh here)
2. Go to https://www.slideshare.net/

Actual:
The browser proposes open/save a dtag 20 bytes document from https://linkedin.com

Comment 3

[Jonathan Kingston [:jkt] he/him]

Oh I can too with a brand new profile, is this something you know about :baku?

Comment 4

[Daniel Veditz [:dveditz]]

According to devtools we're loading the linkedin content in an iframe. The initial URL redirects to an ad server (secure.adnxs.com) that eventually redirects back to linkedIn's dtag with different parameters.

In Release with cookies all over the place I get an ad frame (the 3rd box labeled "Advertisement" in the Features SlideShares row). The ad image I get is served from linkedIn itself so I guess it only went to adnxs.com for tracking and not to get an actual ad.

In Nightly with cleared cookies steps are the same except no cookies on any of these (devtools says they're known trackers). The final redirect back to www.linkedin.com/dtag? is the same except the last parameter. In the broken one it's appnexusuid=0 and in the working one it's a 19 digit appnexusuid (this URL is supplied by adnxs.com). In the broken version there's no content-type header and the content-length is 20 bytes. Despite the content-length header (which is repeated on the save dialog) there's no content downloaded (0 bytes) and devtools concurs ("No response data available for this request").

Because there's no content-type we assume binary and offer to download it rather than display it in the iframe. Even if we were tempted to guess based on content it's served with a nosniff header insisting that we don't. We couldn't guess much from 0 bytes anyway. Sending a response without a content-type is a wrong thing for the server to be doing and linkedin should fix it. Sending the wrong content-length is also a bug on their part.

They are no doubt confused by the lack of cookies. If I load the URL at a top-level page after clearing cookies (or at least linkedin.com cookies) I also get the download. Then when I reload the page (now with the cookies I got from the first attempt) I get the ad document.

https://www.linkedin.com/tscp-serving/dtag?sz=300x250&dc_ref=https://www.slideshare.net/&ti=1&z=slideshare&p=5&pk=slideshare_desktop_homepage_loggedout&_rx=;adsense=t;dc_ref=https://www.slideshare.net/;$DCOPT;ord=$ORD&appnexusuid=0

If LinkedIn changes this to serve a valid content-type header that would solve the problem. Of course if they figure that out they'd probably want to send us the valid ad content rather than leave a blank panel on their client's page.

The only thing Firefox could do to "fix" this is to take linkedin off the tracking list. We shouldn't because what they are doing here is ABSOLUTELY tracking (in partnership with adnxs.com).

Comment 5

[Steven Englehardt [:englehardt]]

Thanks for the detailed description Dan! I can reproduce the download dialog on Nightly 68 build 20190506130308 with Content Blocking. I also tried disabling content blocking and loading https://www.slideshare.net/ with a fresh profile and did not observe the download dialog.

LinkedIn is on the basic tracking protection list.

stpeter, do we have any contacts at LinkedIn who can fix this? From Dan's description, it seems like an issue on their end.

Comment 6

[Karl Dubost💡 :karlcow]

We have a list to discuss these issues. I will contact them.
Thanks a lot Daniel for the parts I had missed.

Comment 7

[Karl Dubost💡 :karlcow]

I just contacted them on the partner mailing list.

Comment 8

[Karl Dubost💡 :karlcow]

Thanks for the detailed bug report, including steps to reproduce and path to resolution.

Comment 9

[(no longer active)]

Just to make sure the status of this bug is clear to everyone, it affects 67 for users who have ETP turned on (for example as part of our ongoing shield study on the release branch). It will also affect new users on 67.0.5.

Comment 10

[Pascal Chevrel:pascalc]

Bumping to P1 since it affects 67.0.5 which is an incoming release. Baku can we get this investigated as soon as possible? Thanks

Comment 11

[(no longer active)]

The investigation has already happened in comment 4. Someone needs to contact LinkedIn and ask them to fix their code (and comment 7 suggests that is in progress already).

Moving to the component which I think is the new "tech evangelism" component?

Comment 12

[(no longer active)]

(Sigh, not sure how get the tracking flags back. I cannot use Bugzilla any more. Can someone help?)

Comment 13

[Mike Taylor [:miketaylr]]

I've filed an internal ticket to track this issue and the team will review.

Just a note that LinkedIn acknowledged Karl's message after he sent it.

Comment 14

[Mike Taylor [:miketaylr]]

I just re-pinged the thread to ask for an update. Still reproduces.

Comment 15

[Pascal Chevrel:pascalc]

I am marking as wontfix for 67 as this is not something we can fix on Firefox side and the webcompat team already contacted Linkedin about it.

Comment 16

[Mike Taylor [:miketaylr]]

I repinged the thread since it still reproduces.

Comment 17

[(no longer active)]

Any updates? I can still reproduce this...

Comment 18

[Mike Taylor [:miketaylr]]

No updates from LinkedIn mailing list. We should probably try alternate avenues...

Comment 19

[Mike Taylor [:miketaylr]]

Trying contact via LinkedIn to a SlideShare engineer.

Comment 20

[Jim Mathies [:jimm]]

checking back in...

Comment 21

[Mike Taylor [:miketaylr]]

I didn't get a reply from SlideShare engineer I found, but just asked a follow-up question to a LinkedIn person off-thread.

Comment 22

[Ksenia Berezina [:ksenia]]

Added an intervention in https://bugzilla.mozilla.org/show_bug.cgi?id=1577870

Comment 23

[Marcia Knous [:marcia]]

Discussed during triage - did the intervention resolve the issue? Thanks.

Comment 24

[Mike Taylor [:miketaylr]]

Yeah, we can close this. If/when the site fixes itself, we will remove the intervention (QA does monthly tests to verify if we still need them).

Comment 25

[Mike Taylor [:miketaylr]]

(In reply to Mike Taylor [:miketaylr] from comment #24)

Yeah, we can close this. If/when the site fixes itself, we will remove the intervention (QA does monthly tests to verify if we still need them).

Looks like they've done that, so this intervention will be removed for the next version.