SAMP from HTTPS is (sometimes) working

[Mark Taylor]

Hi all,

further developments on this long story.  This posting is rather
technical, but it does represent progress.

Felix Stoehr recently reported to me that Web SAMP over HTTPS actually
works out of the box, with no browser extensions, for Google Chrome.
I tested it out, and he's right: using Chromium v78 (on Ubuntu 18.04)
SAMP connections from HTTPS-hosted web pages work perfectly.
You can try it yourself using the working examples listed in the
"Examples" section of https://andromeda.star.bristol.ac.uk/sampjs/.

I was, to put it mildly, surprised by this: it means that the
insurmountable problem I've been bleating about for the last few
years (see http://andromeda.star.bristol.ac.uk/websamp/)
just doesn't exist, at least for some browsers, moreover rather
recent ones.  What's going on?

It turns out that the relevant standards have changed since I last
read them in detail.  XMLHttpRequest accesses to localhost http
services (the hub) from an https context (a Web SAMP client)
is blocked as Mixed Active Content according to the W3C Mixed Content
document https://www.w3.org/TR/2015/CR-mixed-content-20151008/,
and that's what I based my analysis of the problem on in my
presentations in Sydney and Cape Town
(http://wiki.ivoa.net/internal/IVOA/InteropOct2015Applications/samp-https.pdf,
 http://wiki.ivoa.net/internal/IVOA/InterOpMay2016-GWS/tlsamp.pdf).
However, a more recent version of the Mixed Content document
(https://www.w3.org/TR/2016/CR-mixed-content-20160802/)
has updated the definition of an "a priori authenticated URL" to
include "Potentially Trustworthy" URLs.  This in turn via the
W3C Secure Contexts document (https://www.w3.org/TR/secure-contexts)
means that any URL whose host is the loopback address
(127.0.0.1 for IPv4 or ::1 for IPv6) does not count as mixed content.
The latest unpublished draft of the Secure Contexts document
(https://w3c.github.io/webappsec-secure-contexts/, 15 March 2019)
extends this in some cases to use of the hostname "localhost" as well
as the numeric loopback addresses.

That means that under current W3C recommendations, HTTPS web pages
should be able to contact the SAMP hub at http://127.0.0.1:21012/,
and maybe http://localhost:21012/, and thereby use Web SAMP as normal,
without having to jump through any other hoops.

This is great news, since in principle it means we can forget all about
the weird and ugly solutions I was talking about recently in Groningen,
as well as browser extensions.  But it does rely on the browsers people
are using actually implementing the current W3C recommendations.
Do they?

As reported above, it looks like Chromium/Chrome does do this,
apparently since version 53 (2016); see e.g.
e.g. https://chromium.googlesource.com/chromium/src.git/+/130ee686f
At least in v79 it works for "localhost" as well as "127.0.0.1".

My reading about Firefox suggests that it *ought* to work since
version 55 (2017), but it doesn't work for me on version 59 or 70.
The FF mixed content notes at
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
say this:

   Note: Since Firefox 55, the loading of mixed content is allowed on
   http://127.0.0.1/ (see bug 903966). Chrome allows mixed content on
   http://127.0.0.1/ and http://localhost/. Safari does not allow any
   mixed content.

The discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=903966
suggests that maybe this works only for GET but not POST, which
(via XMLHttpRequest) is what SAMP requires, but it's not very clear.
Trying to use SAMP from HTTPS on firefox v70 tells me:

   "Cross-Origin Request Blocked: The Same Origin Policy disallows
   reading the remote resource at http://127.0.0.1:21012/.
   (Reason: CORS request did not succeed).
   https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed

I don't think the problem is to do with CORS though, since there doesn't
appear to be any network activity associated with this error.
If anybody can get to the bottom of this firefox issue I'd really like
to hear.

What now?

Given the above, it looks like just sitting back and waiting might fix
this problem.  If Chrome is implementing the Web-SAMP-over-HTTPS-enabling
changes today, then other browsers may follow suit in future
(Firefox is apparently part-way there).
In the mean time, browser extensions like the one that Sonia has
developed for those browsers that don't yet allow this are a good
sticking plaster, but hopefully won't be a long-term maintenance burden.

I don't think any changes to the SAMP standard are required
(except possibly an erratum to recommend using the loopback address
rather than "localhost" in the well-known Web Profile Hub URL at
sec 5.2.3 and 5.3).
Some minor changes to software could be useful though:

  - samp.js should probably change to contact the hub at the
    numeric loopback address rather than localhost.
    See https://github.com/astrojs/sampjs/issues/7.

  - The JSAMP hub with the minor Origin-checking changes required
    to get Sonia's extension working
    (http://mail.ivoa.net/pipermail/apps-samp/2019-November/001018.html)
    should be released and incorporated into future Hub-containing
    applications (topcat, aladin, ...).  I'll make a new JSAMP release
    some time soon.

  - It would be nice to have some boilerplate that HTTPS-Web SAMP
    pages can incorporate giving user instructions:
    check current browser and advise on necessary action if any,
    e.g. upgrade browser version or install browser extension.

Plus, reports about whether other browsers (IE?) are able to do
Web SAMP from HTTPS (e.g. does
https://andromeda.star.bristol.ac.uk/sampjs/examples/sendlist.html
successfully send a table to e.g. topcat?) would be very useful.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/