Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. I believe those that do, do so because of browser implementation of the W3C Secure Contexts document. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work (see here for long and acrimonious discussion - may change eventually? MarkTaylor - 2024-03-11 )
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work (see here for long and acrimonious discussion - may change eventually? MarkTaylor - 2024-03-11 )
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems

• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

Good solution?

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)

• • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)

• • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
  • Or nothing happens - this means SAMP+HTTPS does not work on your browser.

1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)

• • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)

• • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
  • Or nothing happens - this means SAMP+HTTPS does not work on your browser.

1. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

-- MarkTaylor - 2020-10-13

Web SAMP and HTTPS

Problem

The SAMP Web Profile allows web applications to talk to other SAMP clients, communicating with the Hub using an XMLHttpRequest to a well-known port (21012) on the local host. There are problems with doing this if the web page hosting the web application is served from HTTPS rather than HTTP, since access to the hub URL http://localhost:21012/ counts (at least in some interpretations) as mixed active content, which is generally blocked by browsers. This issue has been known since 2014, but is becoming more pressing as more data providers use HTTPS for service delivery. See Presentation at Sydney Interop (2015) for more details.

Bad solution

A possible solution was proposed that defines a new Profile involving use of an external Relay service and abuse of mixed passive content to bootstrap communications, as described in Taylor presentation at Cape Town Interop (2016). This has been shown to work, e.g. it is currently deployed at ASI-SSDC based on a custom/prototype JSAMP hub, see Verrecchia presentation at Paris Interop (2019). This solution however is not elegant, efficient, robust or nice. There is some more discussion of this as well as alternative bad solutions in https://arxiv.org/abs/1912.00917 (presented by Taylor at ADASS 2019; this paper is now mostly obsolete).

Good solution?

Following discussion at Groningen Interop (2019), some more progress was made that could get HTTPS-based web applications to use the Web Profile as it stands:

• Felix Stoehr pointed out that in recent tests, this just works in some browsers anyway, i.e. the problem has just gone away. This was a surprise, that arises from changes to the various w3c security standards over the last few years (see analysis).
• Sonia Zorba prepared a browser extension samp-browser-extension for browsers that still have problems with this

Current status

We are assessing which browsers now support Web SAMP over HTTPS without making any special arrangements. Thanks to those who have tried out browser/OS combinations following the instructions below. The headline results seem to be:

• Recent versions of Firefox, Chrome, Edge: SAMP over HTTPS works with no problems
• Safari: SAMP over HTTPS doesn't work
• Others: Vivaldi works. Luakit works. Internet Explorer: not sure.
• ... but there are apparently exceptions; I've highlighted these in the table

This looks quite positive; services may decide on that basis that it's worth providing Web SAMP in HTTPS-based services on the basis that they will work for many/most users. Optionally, they could provide the browser extensions for others.

If you use a browser not in the above list, please consider following the instructions below to try it out and add your results into the table (or if you have trouble editing the wiki you can mail m.b.taylor@bristol.ac.uk and I'll add them).

You can try this out using your browser/OS combination(s):

To work out the status of HTTPS+SAMP on your browser/OS, follow these easy instructions:

1. Start a SAMP Hub+client on your machine (e.g. run TOPCAT)
2. Visit this HTTP page. Click the button.
   • A popup should appear asking you to allow SAMP registration from a web application (with an http://... Origin). Accept, and a table should be loaded in TOPCAT. (If this doesn't happen, your problems are not related to HTTPS)
3. Visit this HTTPS page. Click the button.
   • Either as before, you are prompted to allow registration (for a web app with an https://... Origin) and a table is loaded in TOPCAT as before - this means SAMP+HTTPS does work on your browser
   • Or nothing happens - this means SAMP+HTTPS does not work on your browser.
4. Record in the table below whether it did or didn't work ("yes" or "no" in the Works out of the box? column)

(If you want to try some more interesting examples, including 2-way communications, others are available: HTTP / HTTPS. I'm expecting that if HTTPS works/fails for one SAMP example it will be the same for all, but if you find different, please report it).

Results: some anomalous outcomes are highlighted

For more discussion on this topic, see the apps-samp mailing list.

-- MarkTaylor - 2020-10-13