SAMP browser plugin? Re: SAMP and HTTPS workaround?

Zorba, Sonia sonia.zorba at inaf.it
Mon Oct 14 20:48:35 CEST 2019 

Dear all,
it seems that browser vendors are trying to follow a specification in
order to have interoperable browser extensions:
https://browserext.github.io/browserext/
So, in theory, it could be possible to use the same code in different
browsers, if they follow that standard.

However the suggested way to communicate with other applications is
through stdin/stout:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
I didn't tried yet, but I fear that making a http call from an
extension inside a https page could lead to the same problems we are
trying to solve.
Could we define a profile in which messages are exchanged through
stdin/stout instead of http?

In any case I'm available to do some experiments.

Cheers,
Sonia

Il giorno lun 14 ott 2019 alle ore 18:34 Mark Taylor
<M.B.Taylor at bristol.ac.uk> ha scritto:
>
> Thomas et al.,
>
> the browser plugin seems to be a popular suggestion, so maybe
> I've just been asking the wrong question or making the wrong
> assumptions about what a solution would look like.  If a plugin-based
> approach can be made to work (which I'd define as, maybe,
> allowing >=80% of users to interact with SAMP from HTTPS pages?)
> I'd be very happy to see it in use and chuck away all the
> relay/nudge business I was talking about in Groningen.
> I have been a bit scared of the amount of effort required to
> develop and maintain multi-platform browser-specific code to
> support this functionality, but maybe it's not as bad as I feared.
>
> I am pretty ignorant about plugin capabilities.  If they operate
> entirely outside of the browser sandbox then they can interact
> with the Hub using the existing Standard Profile, which I presume
> is what Sebastien's 2010ASPC..434..159D implementation did
> (or maybe Web Profile would be better? because of the different
> security assumptions that the Web Profile makes).
> Either way, hub implementations wouldn't need any change.
> But there would need to be some browser-independent interface:
> a "Plugin Profile" (which I think means a JavaScript API?)
> defining how web applications can communicate with these plugins
> in an browser-independent way.
>
> One possibility for specifying that would be to use the same API
> that the sampjs library currently exposes (though maybe under a
> different namespace to avoid confusion, e.g. samp_plugin.Connector
> rather than samp.Connector).  That would make it easy for web
> applications to migrate from current practice
> (HTTP-only Web SAMP using sampjs library) to use of a future
> HTTPS-capable Plugin Profile.  However, if there's some good
> reason to prefer different methods or names than the ones I chose
> for sampjs, that's fine by me.  The sampjs API is not very explicitly
> documented right now, you have to look at the code and examples
> (http://astrojs.github.io/sampjs/), but I could write it up
> better if required.
>
> I think the only way to take this forward is to experiment and
> try it out, so we'd need some volunteers to try to write plugins
> for different browsers.  Writing browser plugins is far from
> my area of expertise, so I'm not volunteering.  Sonia Zorba
> suggested in Groningen that she might be willing to have a go,
> and Thomas's "quite like the idea of developing a plugin" sounds
> like it could be an offer too...
>
> Mark
>
>
> On Mon, 14 Oct 2019, Thomas Boch wrote:
>
> >
> >
> > Le 14/10/2019 à 14:37, Mark Taylor a écrit :
> > > Hi Hugo,
> > >
> > > thanks for the input.  I didn't go through all the possibilities
> > > in my talk, but yes a browser plugin of some sort might be able to
> > > solve the problem (and historically I think that some SAMP browser
> > > plugins existed before the Web Profile was introduced as an alternative
> > > solution to that problem, but I don't think they got much beyond
> > > the experimental stage).  A couple of other people mentioned this
> > > at the meeting too.
> >
> > I think Sebastien Derriere demonstrated the concept at an earlier ADASS
> > meeting in Japan, in a talk entitled '’SAMP’ling Your Browser for the Semantic
> > Web' (http://adsabs.harvard.edu/abs/2010ASPC..434..159D ).
> >
> > I think I quite like the idea of developing a plugin to overcome Web SAMP
> > issues raised by HTTPS pages.
> >
> > Thomas
> > > I have two main reservations about this option.  First, will users
> > > actually install a browser extension?  And second, the amount of
> > > work involved in writing and maintaining the extension code for
> > > multiple versions of multiple browsers.  I don't have much grasp
> > > of how big a drawback either of those things is though.
> > > If anybody wants to experiment with implementation and report back,
> > > that would be great.
> > >
> > > Mark
> > >
> > >
> > > On Mon, 14 Oct 2019, Hugo Buddelmeijer wrote:
> > >
> > > > Hi all,
> > > >
> > > > Would a SAMP browser plugin be a solution to the https problem?
> > > >
> > > > That is, users install a samp-plugin, the websites connect to the plugin,
> > > > and the plugin connects to the samp-hub. This seems possible:
> > > > https://developer.chrome.com/extensions/nativeMessaging
> > > > https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
> > > >
> > > > Maybe it would be feasible to have this browser plugin to be effectively
> > > > another SAMP hub (that talks to the desktop hub); that is, adding a new
> > > > browser-plugin profile to standard. That way anyone could make a compliant
> > > > plugin so we would not be at the merci of this hypothetical plugin author.
> > > >
> > > > There are only a few browsers (chrome, firefox, safari), so it might be
> > > > less work than the relay-solution.
> > > >
> > > > My experience with browser plugins is very limited (a single experiment
> > > > years ago), so maybe it is not as simple. And maybe installing
> > > > yet-another-browser-plugin for just a single use case is too much overhead
> > > > for some people.
> > > >
> > > > Any thoughts?
> > > >
> > > > Hugo
> > > >
> > > >
> > > >
> > > > On Thu, 22 Aug 2019 at 15:05, Mark Taylor <M.B.Taylor at bristol.ac.uk>
> > > > wrote:
> > > >
> > > > > Dear SAMP users,
> > > > >
> > > > > the problem of Web SAMP and HTTPS has been under discussion
> > > > > for a while now - basically the Web Profile works fine with HTTP
> > > > > but won't work from pages served using HTTPS.  A possible HTTPS-capable
> > > > > profile has been prototyped, but it's pretty nasty.  There is much
> > > > > more information on the topic here:
> > > > >
> > > > >     http://andromeda.star.bristol.ac.uk/websamp/
> > > > >
> > > > > As an alternative to the HTTPS profile, I'm thinking about more
> > > > > lightweight workarounds.  One is just to provide a simple helper
> > > > > application that takes a suitable filename on the command line
> > > > > (VOTable table or FITS image) and sends it to a running SAMP
> > > > > client.  Such an application could be associated in the
> > > > > browser with suitable MIME types (application/x-votable+xml,
> > > > > image/fits), or you could just choose it when the browser
> > > > > asks you what application you want to open a downloaded file with.
> > > > >
> > > > > This is much less flexible than allowing the web page (web application)
> > > > > to interact with the SAMP hub itself, which is what you can do
> > > > > with SAMP+Web Profile.  However, in practice, nearly(?) all Web SAMP
> > > > > pages that I'm aware of just use Web SAMP to allow the user to
> > > > > send a samp.load.votable or image.load.fits message, and that's
> > > > > done nearly as well by the helper application.  It works with
> > > > > rather than against normal browser operations, which makes it
> > > > > much less painful to implement than the HTTPS profile;
> > > > > it works equally with HTTPS or HTTP, and no additional
> > > > > infrastructure is required.  The main downside is that the user has
> > > > > to configure it somehow (install script, tell browser to use it
> > > > > to handle relevant files).
> > > > >
> > > > > I have written such a helper application, and I'd be interested
> > > > > to know if anyone wants to try it out: especially data providers
> > > > > who are using HTTPS and want to allow users to load tables/images
> > > > > using SAMP.  Would this be an acceptable solution?
> > > > >
> > > > > You can find the application here:
> > > > >
> > > > >     http://andromeda.star.bris.ac.uk/websamp/sampload.jar
> > > > >
> > > > > If you run, e.g. "java -jar sampload.jar /tmp/tmpfile.vot"
> > > > > then it will pop up a window asking which VOTable-capable
> > > > > SAMP client you want to send tmpfile.vot to.
> > > > > (It works out what kind of file it is by looking at the content).
> > > > >
> > > > > Unless your OS/browser can execute jar files directly, to use it with
> > > > > a browser you'll need to accompany it with a small shell script or
> > > > > equivalent like
> > > > >
> > > > >     #!/bin/sh
> > > > >     java -jar /path/to/sampload.jar "$@"
> > > > >
> > > > > Any feedback, comments, ideas welcome.
> > > > >
> > > > > 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/
> > > > >
> > > --
> > > 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/
> >
> >
>
> --
> 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/

More information about the apps-samp mailing list