Remote Debugging Chrome & SameSite cookies with Chrome DevTools

When developing and delivering use-cases for Android or iOS devices, remotely debugging and inspecting how content is rendered in Google Chrome can be challenging. In the last few years, Chrome introduced a very useful feature that allows remote debugging. This functionality became infinitely useful when working on a use case that leverages cookies in a third-party context. In this blog post, we'll cover why cookies can be a headache (for all platforms), and how Chrome DevTools can be used to isolate issues on mobile devices.

Requirements:

  • Android OS with Developer Options enabled
    • USB Debugging enabled
  • USB-C Cable
    • To connect Android device to macOS / Windows device
  • Google Chrome (mobile)
  • Google Chrome (macOS / Windows device)




Context:
A use case I am involved in hosts content internally on a private cloud using VMware Tanzu (formerly Pivotal Cloud Foundry). This private cloud has its own unique domain. So while the user might be authenticating and viewing content on www.myLearning.WS1inHawaii.com, the video content displayed in an iFrame would be streaming from a different domain, like www.cdn.myHawaiiCloud.net. 

Sounds neat, right? We save on public cloud data egress costs by hosting the video content on our private cloud. Then to provide the responsive web-site for users, we host it on a provider that is more performant across all geographies - like CloudFlare or Amazon Web Services. 

The Problem
Each cookie issued by a service has a key/value pair that identifies how the cookie can be used. There are first party cookies, and third party cookies. In 2020, Google and Apple (and all browsers based on Chromium and Webkit) introduced a secure by default model for cookies used in a 3rd party context. This secure by default model protects 3rd party cookies from external access unless otherwise specified in the 'SameSite' key/value pair.

What this meant for the business is content in an iFrame would suddenly not render. On Chrome version 80 and above, all cookies without SameSite attributes will be treated as if they have 'SameSite=lax' specified. With this secure by default model, if the SameSite attribute value is set to 'lax' and is from a 3rd party, it will be blocked. When the 3rd party cookie is blocked, it will cause content from that 3rd party to not render. 

In our case, the 3rd party service internally developed did not serialize cookies with the SameSite value set. This impacted iOS, macOS, Android and Windows devices, but only devices that had newer browsers. 

It is important to note that we needed a permanent, secure, solution that works on all platforms. Google has settings temporarily available to exempt cookies from this new secure by default model. These settings are scheduled to be deprecated in late 2021 / 2022. Enabling these would be considered less secure, as it introduces a cross site request forgery attack vector. In addition, these settings are not available on all platforms (iOS is currently excluded). In our use case, the most secure solution will come by introducing a CNAME DNS record that points to our A record for the CDN hosted on Tanzu. The next most secure solution would be to serialize the cookie with the SameSite values specified as:

'SameSite=None; Secure'

Finally the least secure option would be to use Workspace ONE to introduce a client side fix with Chrome, which would allow cookies to be sent with all cross-site requests. Since this service was developed on a wrapper over Spring Boot (a popular Java framework), the codebase could be updated to serialize the cookies with the SameSite attribute set. This ultimately solved the issue on all platforms and browsers. 

So how do you even know if something like this is impacting you, especially on a mobile device? Remote Debugging with Chrome, that's how.


Remote Debugging Chrome Mobile on Android with Chrome DevTools
  1. On the Android device, enable Developer options
  2. Enable USB Debugging in Developer options
  3. Connect the Android device to your macOS / Windows host
  4. Open Chrome on the Android device
  5. Open Chrome on the macOS / Windows host
  6. On the macOS / Windows host, navigate to the URL:
    chrome://inspect/#devices
  7. On the macOS / Windows host, you should see something like this:
    The SM-T830 device has developer options enabled, and Chrome open. On the mobile device, every Chrome tab, including Chrome custom tabs, will be displayed here.


  8. Click inspect on the mobile site browser tab that you wish to inspect
  9. On the mobile device, navigate to the website that fails to render content
    • If the web browser is newer than Chrome 80, open the Google Play store and uninstall the Chrome browser. While you cannot uninstall the browser, you can downgrade the browser to the version shipped with the device. The screenshot you see below will only display on Chrome browser versions 79 or lower.  
  10. Click the 'Console' tab in Chrome DevTools. If you see references to a cross-site resource with SameSite cookies attributes properly set; the cookies serialized by the service are not sent with the values;
    'SameSite=none; Secure'

  11. To see the cookie key/value data, click 'Network', followed by 'Cookies'. Make sure 'show filtered out request cookies' is checked, in addition to 'Has blocked cookies'

    If you hover your mouse over the cookie, it will warn you about the SameSite attributes 

If you open a new browser tab on the mobile device, and you wish to inspect it; you will need to close 'DevTools' and click 'Inspect' on the new tab you opened.

To highlight how Remote Debugging works, I created this short video. In this video you see how to inspect browser tabs on remote devices, and use DevTools much like you would on a non-mobile device.



The goal of this blog post is to share the value of using Chrome DevTools to inspect how content is rendered on a mobile device. Prior to DevTools supporting remote debugging, it was much more difficult to obtain this kind of data. When DevTools is combined with Fiddler and a tool to troubleshoot AuthN/AuthZ (e.g. rcFederation), you can tackle nearly any issue.

If you are interested in learning more about Remote Debugging with Chrome DevTools, or SameSite cookies - check out some of the links below.

https://www.youtube.com/watch?v=GPz7onXjP_4

https://developers.google.com/web/tools/chrome-devtools/remote-debugging

https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure

https://www.chromestatus.com/feature/5633521622188032

https://www.chromestatus.com/feature/5088147346030592

https://web.dev/samesite-cookies-explained/


Comments

Post a Comment

Popular posts from this blog

How to use Square's OkHttp Java library to access Workspace ONE UEM API's

Image
Digital workspace solutions often require consuming other services. When doing so, you may work with things like; REST API endpoints, Webhooks, gRPC, GraphQL - the list goes on. You can interact with these in a number of ways, but one way I've come to appreciate is with Java. It has been especially helpful when I've wanted to work with libraries like Appium, Selenium, OKHttp, or the Workspace ONE UEM SDK in a workflow. With that, I thought it would be helpful to share how to work with Workspace ONE UEM API's using Java. In this blog post, we will cover; Basics of JetBrain's IntelliJ IDE, touching on Apache Maven Using  Square's OkHttp   library  to call Workspace ONE UEM API's Why Java? Java is used by many and supported by most (Docker, Kubernetes, static code analysis tools, cloud service providers, Android, Windows, macOS, Tanzu Application Service, etc). Many languages compile to j ava
Read more

How to use Powershell with the Workspace ONE UEM API to search for users

Image
Using API's has been infinitely helpful in integrating Workspace ONE UEM with other enterprise services and applications. A question was asked recently about forming the correct HTTP header using Powershell, and returning the users in the users. Below is an example Powershell script I was able to create for this example. Make sure to include base64 encoded credentials in a folder (c:\creds\b64.txt in the example), and to update the $apiKey variable with an API key. #Workspace ONE UEM Environment Address / Authentication  $addy   =   "https://ws1.molokaibank.com" $b64   =   Get-Content   -Path   "c:\creds\b64.txt" $apiKey   =   "apikey" $b64EncodedAuth   =   " $b64 " # Header $content   =   "application/json"   $authHeader   =   "Basic "   +   $b64EncodedAuth $header   =  @{ "Authorization"   =   $authHeader ;  "aw-tenant-code"   =   $apiKey ;  "Accept"   =   $content ; 
Read more