Closed Bug 1511753 Opened 6 years ago Closed 5 years ago

BBCAMERICA livetv cable provider verification does not work, unable to sign into cable provider and watch live tv

Categories

(Core :: Privacy: Anti-Tracking, defect)

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
63 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox63 --- affected
firefox64 --- affected
firefox65 --- affected
firefox66 --- affected

People

(Reporter: chris.skipper3, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [privacy65][triage])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: go to bbcamerica website and click live tv. It will ask to sign in to your cable account to verify that you have access to bbc america. Actual results: Forced to retry logging in an infinite amount of times with cable company because it is not validating the login Expected results: it should return to the video player and allow you to play the live tv stream
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 (20181206214149) I was able to reproduce the mentioned behavior on Windows 10 x64 using the latest Nightly and Fx release builds. When using my DirectTV account credentials I`m forced to repeat this step infinite amount of time, hence the LiveTV does not start. The same behavior is not reproducible in the competitor browsers. Browser console output when trying to login: Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.[Learn More] livestream [AccessEnablerProxy.js][info] Version: 3.4.2-3ff3b09 RELEASE AccessEnablerProxy.js:1:17229 Request to access cookie or storage on “https://sp.auth.adobe.com/entitlement/js/AccessEnablerProxy.html?925f2c3d39000521e496#http%3A%2F%2Fwww.bbcamerica.com%2Flivestream” was blocked because it came from a tracker and content blocking is enabled. I will move this issue to Core:Networking::HTTP. However, please change if this is not the correct component.
Status: UNCONFIRMED → NEW
status-firefox63: --- → affected
status-firefox64: --- → affected
status-firefox65: --- → affected
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Product: Firefox → Core
Moving to Tracking Protection according to comment 1
Component: Networking: HTTP → Tracking Protection
Product: Core → Firefox
Sign-in breakage with cookie restrictions...
Flags: needinfo?(tanvi)
Whiteboard: [privacy65][triage]
I can reproduce this with Standard settings. Looking into it more.
Any updates here, Tanvi?
Blocks: etp-breakage
Please capture a log with MOZ_LOG=AntiTracking:5 if possible. Thanks!
I tested this today, and here is what I've found out so far. The origin that gets blocked and causes problems here is https://sp.auth.adobe.com. Upon logging in, the user clicks on an image from the first-party document, so there is no chance for our heuristic to get engaged. The main page has a display:none iframe with src set to https://sp.auth.adobe.com/entitlement/v4/AccessEnablerProxy.... When you click on the provider icon (e.g. Dish) you get sent to this URL as the first party: https://sp.auth.adobe.com/adobe-services/authenticate/saml?reg_code=SEHJJX4&noflash=true&mso_id=Dish&requestor_id=BBCA&no_iframe=false&domain_name=adobe.com&redirect_url=http://www.bbcamerica.com/livestream It gives you the following HTML: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <body onload="document.forms[0].submit()"> <noscript> <p> <strong>Note:</strong> Since your browser does not support JavaScript, you must press the Continue button once to proceed. </p> </noscript> <p>Please wait while we send you to your provider to log in...</p><br/> <form action="https&#x3a;&#x2f;&#x2f;identity1.dishnetwork.com&#x2f;saml&#x2f;saml2&#x2f;idp&#x2f;SSOService.php" method="post"> <div> <input type="hidden" name="RelayState" value="base64-encoded-blob"/> <input type="hidden" name="SAMLRequest" value="base64-encoded-blob"/> </div> <noscript> <div> <input type="submit" value="Continue"/> </div> </noscript> </form> </body> </html> From there through a bunch of redirects you get to the login page: https://identity1.dishnetwork.com/saml/module.php/sociallogin/login.php?AuthState=longstringhere There is no sign of sp.auth.adobe.com on the page where you enter your password. After you do that and press submit, through a redirect chain you end up on https://sp.auth.adobe.com/sp/saml/SAMLAssertionConsumer which redirects you back to http://www.bbcamerica.com/livestream. The disturbing thing is that on one of the pages in this redirect chain there is a pixel with this URL: <https://synacor.112.2o7.net/b/ss/synacortveauth/1/H.24.4/s81816974326677?AQB=1&ndh=1&t=20/11/2018 19:25:17 4 300&ce=UTF-8&ns=synacor&pageName=Federated Login&g=https://identity1.dishnetwork.com/saml/module.php/sociallogin/login.php?AuthState=longstringhere&r=https://identity1.dishnetwork.com/saml/module.php/authbypass/firstbookend.php?AuthState=longstringhere&cc=USD&c1=DISH&c3=https://saml.sp.auth.adobe.com&c4=https://identity1.dishnetwork.com/saml/saml2/idp/metadata.php&c6=Federated Login&c7=409e3efea04e3f464da5c2e973ab027c&s=1920x1080&c=24&j=1.6&v=N&k=Y&bw=1280&bh=872&AQE=1> and it seems this is how the two SSO systems are syncing their login states! Then on the livestream page the adobe.com iframe tries to access its cookies, and that fails, and the login fails with this message: "You do not have a subscription to view the requested content. To upgrade your programming go to mydish.com/programming and then log back in to view content." Right now, I can't imagine us being able to design a heuristic which would be able to handle this in a generic way. :-(
Hi Chris, Can you tell us what Firefox version number and release you were using? Firefox 63 release? It would be super helpful if you could type about:config in your url bar and search for "urlclassifier.trackingAnnotationTable" and tell us the value of that preference. Thank you!
Flags: needinfo?(chris.skipper3)

With some help, I have an account I can test with!

Positive results (login works and I can view the content):

  • Blocking Tracking Cookies from the basic Disconnect list, I can login via directtv and view live content.
  • Blocking Tracking Cookies from the strict Disconnect list, I can login via directtv and view live content.
  • Blocking All third party cookies, I can also login via directtv and view live content.
  • Blocking Tracking Cookies from the basic Disconnect list AND Blocking Trackers from the basic Disconnect list, I can login via directtv and view live content.

Negative results (login does not work):

  • Blocking Tracking Cookies from the basic Disconnect list AND Blocking Trackers from the strict Disconnect list, I don't even see an option to login via DirectTV.

We know that blocking trackers from the strict list from loading entirely causes breakage, so I'm not worried about the negative result, and I don't think those were the settings this bug was initially tested with when this bug was reported.

Maybe bbcamerica has changed their site? Stefan, can you test one more time to see if you still see an issue here?

Flags: needinfo?(stefan.georgiev)

I've just tested the simple log in and content playing on Windows 10 using the latest Nightly (20190110093854), Beta 65.0b9 and Fx release 64.0.2. I`m able to log in and play the video without any issue.

Flags: needinfo?(stefan.georgiev)
Component: Tracking Protection → Privacy: Anti-Tracking
Product: Firefox → Core

adobe.com is in the content category, so this will break when we switch to the strict list. However, it looks like the breakage has been fixed. Tanvi, can you confirm and close if that's correct?

Blocks: etp-level-2-list

I have a followup to test this with dishnetwork instead of directtv, but I no longer have an account to do that with.

Flags: needinfo?(tanvi)

This bug isn't actionable any more. I'm going to close it as INCOMPLETE. Please reopen if new steps to reproduce emerge in the future. Thanks!

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.