Cannot load DevTools frontend from an untrusted origin

2,000 views
Skip to first unread message

Davis Ford

unread,
Feb 27, 2014, 12:41:49 PM2/27/14
to chromi...@chromium.org
Hi, I have a custom Android build on custom hardware, and running our own Chromium build as well.  Normally I develop on rooted tablets, and use chrome devtools and enable remote-debugging-raw-usb via the following on Android:

shell@android:/ $ echo chrome --remote-debugging-raw-usb > /data/local/tmp/content-shell-command-line

This always works great on the tablets we have, and then we connect Chrome DevTools to the Android target running Chromium.  

However, when I try this on the new hardware, I am getting this error when I try to launch the inspect link shown under Devices in the ADB extension:

Cannot load DevTools frontend from an untrusted origin

So, i have toggled on --disable-web-security but that does not seem to help.

I have root access everywhere, so I can change anything I need to, just wondering how I can get past this one?

Thanks in advance,
Davis

Davis Ford

unread,
Feb 27, 2014, 3:03:35 PM2/27/14
to chromi...@chromium.org
So, there isn't much out there about this except the source, and inspecting that https://chromium.googlesource.com/experimental/chromium/src/+/git-svn/chrome/browser/ui/webui/devtools_ui.cc

It appears to end up in this condition if either the url isn't valid, or if the frontend domain doesn't match chrome-devtools-frontend.appspot.com
  1. const char kRemoteFrontendDomain[] = "chrome-devtools-frontend.appspot.com";

  1. #if defined(DEBUG_DEVTOOLS)
  2. // Local frontend url provided by InspectUI.
  3. const char kFallbackFrontendURL[] =
  4.     "chrome-devtools://devtools/bundled/devtools.html";
  5. #else
  6. // URL causing the DevTools window to display a plain text warning.
  7. const char kFallbackFrontendURL[] =
  8.     "data:text/plain,Cannot load DevTools frontend from an untrusted origin";
  9. #endif  // defined(DEBUG_DEVTOOLS)

  1. GURL DevToolsUI::GetProxyURL(const std::string& frontend_url) {
  2.   GURL url(frontend_url);
  3.   if (!url.is_valid() || url.host() != kRemoteFrontendDomain) {
  4.     return GURL(kFallbackFrontendURL);
  5.   }

Just to clarify, I downloaded Chrome .deb direct from Google for Linux x64 on the host/dev machine, so I'm not sure why the frontend_url wouldn't be valid, this was not a custom build of Chrome.  

Vladislav Kaznacheev

unread,
Feb 28, 2014, 4:56:36 AM2/28/14
to Davis Ford, chromium-dev
Hi, the author of the above lines here.

First, I am pretty sure that  --remote-debugging-raw-usb flag does not do anything. This is for two reasons:
1. This flag has been removed from Chromium code last October (https://src.chromium.org/viewvc/chrome?revision=227275&view=revision).
2. Even when it existed it controlled the behavior of desktop-side Chrome, not the one running on Android.

Now about the reason you are getting the message. This is not about user privileges or web security.

When you use desktop Chrome to debug a page on Android Chrome the desktop Chrome must know where to get the debugger frontend code (a bunch of html/javascript/css that makes up the DevTools window UI). 
This only seems trivial:
1. We cannot use the version of the frontend code bundled with the desktop Chrome because it can be different from the one on the Android side (and DevTools would break in unexpected ways)
2. We cannot download the frontend code from the Android Chrome because there is no DevTools frontend code bundled with Android Chrome (this decision is made in order to avoid inflating the apk file size).
3. What we are doing instead is having the Android Chrome tell us what version it is an download the appropriate version of DevTools frontend from a special server on the Web (http://chrome-devtools-frontend.appspot.com/). And it works quite nicely.

The fact that you are getting this message is telling me that you are probably doing something creative with the debugging infrastructure. Are you customizing DevToolsHttpHandler/DevToolsHttpHandlerDelegate somehow?

Best regards,

  Vlad
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

Davis Ford

unread,
Feb 28, 2014, 10:33:14 AM2/28/14
to chromi...@chromium.org, Davis Ford
Thanks for the prompt reply Vlad

What you're saying makes total sense to me, but I didn't modify anything related to the DevTool* code at all.  It appears the answer is much simpler.  Getting networking to work on this board is a bit of a hassle, requiring me to setup Internet sharing on my mac book pro to serve DHCP, and manually configuring DNS, etc. on the device.  It so happens that while I was attempting to use remote DevTools, the networking was only half-configured -- which is why I believe it was failing.  As you said the content shell would try to go out and fetch the frontend, b/c you don't bundle it, and it just couldn't reach it.  After I read your explanation, I suspected that might be the case, and I tried it again (with networking properly setup) and indeed it works.

Thanks again for the great explanation!

Mikhail Naganov

unread,
Feb 28, 2014, 11:22:37 AM2/28/14
to Davis Ford, Chromium-dev
Hi Davis,

I would like to make a small clarification, you say:

> As you said the content shell would try to go out and fetch the frontend, b/c you don't bundle it, and it just couldn't reach it. 

It's not how it actually happens. Chrome on your desktop asks the mobile browser (in your case content shell) to provide the url for the remote devtools frontend. The important bit of information in that url is the revision of Blink. Desktop Chrome also ensures, that the url starts with 'https://chrome-devtools-frontend.appspot.com', afterwards it opens a browser window with extended privileges and navigates to the url provided.

I'm still not sure what kind of a problem do you have, but in general, remote debugging of content shell should work via chrome://inspect. Just make sure you are using the most recent version of Chrome on desktop. You can try continuous builds from http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html to stay on the bleeding edge.


--

Davis Ford

unread,
Mar 17, 2014, 12:58:36 PM3/17/14
to chromi...@chromium.org, Davis Ford, mnag...@chromium.org
Hello Mikhail / Vlad,

Brief follow-up on this.  I have now updated my Android Chromium apks (I build all three: android-webview, content-shell, and chrome-shell), and they are running nicely.  The version I am at is:

Date:   Thu Mar 13 10:01:36 2014 -0700
LKGR w/ DEPS up to revision 256789

I'm also running Chrome Desktop version Version 33.0.1750.152

However, when I try to debug by going to chrome://inspect on Desktop, it discovers the processes on the tablet, and shows them as inspect targets, but if I click on inspect, it pops up a blank window.  Showing the JS console, there are a few errors which may be indicative of what the problem is?  The URL 

See screenshot here: http://i.imgur.com/Fcns6qC.png

Any idea on what I need to do to resolve this?

Thanks in advance

Mikhail Naganov

unread,
Mar 17, 2014, 1:02:00 PM3/17/14
to Davis Ford, Chromium-dev
Use a newer desktop Chrome version: Dev channel or a continuous build from http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html

Using an older desktop Chrome for debugging newer mobile targets is generally not supported.
Reply all
Reply to author
Forward
0 new messages