SAMP Web profile and Private Network Access

[Mark Taylor]

Hi SAMP enthusiasts,

TL;DR: emerging browser security restrictions are squeezing Web SAMP
       some more; I will soon release a new JSAMP version which you
       should use if you're embedding a JSAMP hub in your application

In more detail:

Bogdan Nicula (Royal Observatory of Belgium, JHelioViewer)
has recently brought to my attention an emerging browser compatibility
issue that affects the SAMP Web Profile.
See here for the conversation: https://github.com/mbtaylor/jsamp/pull/5

There is a W3C Community Group Draft Report under development named
Private Network Access (PNA); see
    https://wicg.github.io/private-network-access/
It is intended to address CSRF-related security concerns associated
with certain scenarios including the one where a web page on the WWW
at large wants to talk to a server at http://localhost/.  This is the
scenario that enables the SAMP web profile to work.  The general idea
is that browsers should block such "public to local" accesses
by default.

I can see two implications for the SAMP web profile of the policy 
described by PNA:

  1. Only HTTPS, not HTTP, web pages will be allowed to talk to localhost

  2. The localhost server (SAMP hub) must do some header manipulation
     to explicitly allow such communications

I don't really know what the status of this document is in the W3C
world at large, but it's something that at least Google Chrome is
starting to implement (I think it's effectively a Google initiative).
A chrome developer blog post at
https://developer.chrome.com/blog/private-network-access-update
claims that by Chrome 117 this will be fully implemented,
but that doesn't seem to be the case in my Chrome 122,
so this schedule has at least slipped; however Chrome 122 does
block HTTP->localhost connections as per (1) above, and registers
a security warning when (2) is not done.  So it makes sense to
address it as far as possible in SAMP implementations now, 
to mitigate behaviour in future versions of Chrome and/or other 
browsers that would stop Web SAMP from working.

Regarding (1) above: it seems that HTTP-based pages trying
to do Web SAMP already no longer work from Chrome.
Note this is the opposite of the situation discussed at
https://wiki.ivoa.net/twiki/bin/view/IVOA/WebSampHttps;
for Safari HTTP pages but not HTTPS pages can do Web SAMP,
but for Chrome the opposite is the case.  So it looks like there
is now no way (barring browser-specific acrobatics) that you
can serve a Web SAMP-capable web page that will work with
all common browsers.

It seems that (2) can be addressed by a straightforward modification
of the CORS preflight header handling in the JSAMP hub implementation
(thanks to Bogdan for making this change).  I will therefore issue
a new JSAMP release (probably 1.3.8) in the coming days with this
modification.  I will announce here when that's available.

The purpose of this post is to:

  - Record this technical issue for SAMP implementors

  - Call for any comments or implications that I haven't thought of
    (especially that might need further JSAMP modifications)

  - Warn owners of SAMP-capable HTTP (not HTTPS) pages that they will
    no longer work, at least for some browsers

  - Warn application developers who are bundling the JSAMP hub that
    they should upgrade soon

  - Warn other Web SAMP hub implementors they they should consider
    an similar update

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/