Connecting a tablet to a SAMP environment on the desktop

[Mark Taylor]

Hugo,

thanks, I've made the change to the document.

As far as the JSAMP implementation goes, it currently does not permit
the non-local host access you suggest, but I'll consider adding an
option for it in the future, especially if anybody wants to try to
develop a tablet client along these lines.

I take your point about the mobile device view of the world (web-like
clients running in browser-like environments, rather than traditional
style clients, are becoming more common, even outside browsers as such).
Being a bit of an old-technology guy, it's something I hadn't thought
much about, but I expect you're right it is something we're going to
have to keep in mind.

Mark

On Mon, 30 Jan 2012, Hugo Buddelmeijer wrote:

> Hi Mark et al.,
> 
> Thanks for your reply. With HUB-HUB communication it would probably be
> possible to create tablet SAMP clients with the current version of the
> profiles. However, your suggested change of the web profile would make tablet
> clients much more feasible. Therefore, I do think the proposed paragraph would
> be valuable addition to the web profile.
> 
> 
> How it could be done now:
> - Create one HUB-application using the standard profile.
> - This has to be a native application, because it needs to be a server.
> - This costs money for a developer license. However, this only has to be paid
> for the development/distribution of the HUB.
> - Leave it to the tablet owner to ensure that inbound connections to the
> tablet are possible. This can be prohibitively hard.
> - In my case this would require setting up an SSH tunnel, since I do not
> control the firewalls that 'protect' my tablet.
> - Allow webapplications to connect to this HUB.
> 
> With the proposed changes:
> - Allow the HUB to accept external connections on the web profile.
> - Create a tablet web application that connects to the main HUB through the
> web profile.
> 
> 
> Opening the port to the world by default would indeed be a security risk.
> However, making it possible for the user to do so temporarily would be very
> valuable.
> 
> 
> A final note from a more general perspective. It seems that tablet world (and
> computing in general) moves to the paradigm where inbound connections should
> be prevented when at all possible. There is to true need for inbound
> connections to SAMP clients, as the web profile demonstrates. It would
> therefore be useful to take this development into account, irrespective of
> whether we consider this change to be good or bad.
> 
> Greetings,
> Hugo
> 
> 
> On 01/25/2012 11:56 AM, Mark Taylor wrote:
> > Hugo,
> > 
> > On Tue, 24 Jan 2012, Hugo Buddelmeijer wrote:
> > 
> > > Tablets with a touch screen could be a valuable addition in the
> > > interactive
> > > exploration of our data. Therefore, it would be nice to be able to connect
> > > a
> > > tablet (iPad, android) to an existing SAMP setup. That is, to have the
> > > SAMP
> > > HUB and most applications running on the desktop, and run only a simple
> > > interactive visualization tool on the tablet.
> > 
> > I think this is a very interesting idea, and certainly something it
> > would be good to facilitate rather than preclude in the standard.
> > 
> > > However, this seems not to be possible with either the default profile or
> > > the
> > > proposed web profile. What are your ideas on this?
> > > 
> > > - The default profile requires the tablet application to setup an XML-RPC
> > > server. In practice this would often be impossible, for example due to
> > > inbound-blocking firewalls or restrictions in the device itself.
> > 
> > I don't know enough about tablet-like devices to understand the
> > restrictions that a tablet-based application is likely to be
> > operating under, but if as you say they are unable to run an XML-RPC
> > server on a port of their choice then yes the Standard Profile
> > is not suitable for data-consuming clients.
> > 
> > > - The web profile could remove these restrictions. Running a SAMP
> > > application
> > > on a tablet would then simply become loading a web page. However, this
> > > does
> > > not work either because the spec recommends to block connections from
> > > another
> > > device (sec. 5.2.3 and 5.4.2.1).
> > 
> > Done like this (web profile hub connection from an external host)
> > hub discovery is still an issue (as you noted before), each web app
> > would need to know what host the hub resides on.  It could get the
> > user to type it in or something, which would work but be a bit clunky.
> > 
> > To get round the hub discovery issue, the nicest way
> > for tablet SAMP connection to a desktop to work might
> > be for the tablet to run a hub which talks to the desktop hub,
> > and then web apps on the tablet can talk to the tablet hub
> > using the web profile, while the tablet hub bridges connections to
> > the desktop hub.  Then tablet applications can do hub discovery in
> > the usual way, and they also don't need to know whether they are
> > talking cross-host or just locally.  It would require a native
> > application on the tablet (hub + hub-hub bridge) but this only
> > needs to be written once, not for each app.  If the tablet-desktop
> > hub bridging is done using the Standard Profile, this whole scheme
> > could work with the Standard and Web profiles exactly as they stand.
> > If running an XML-RPC server on an application-chosen port is impossible
> > then it would have to use the Web Profile (or possibly some new profile)
> > with the local-host restriction relaxed as you suggest.
> > 
> > > My ideas to remedy this would be one of the following:
> > > - (Optionally) allow external connections in the SAMP web profile?
> > > - Add the long-polling option also to the default SAMP profile?
> > > - A third profile?
> > 
> > Since it's not clear (to me at least) what would be the best way
> > to implement this kind of connection, I agree that it would be
> > good to adjust the standard so as not to preclude the scenario
> > you're talking about, if it can be done without too much disruption.
> > 
> > I think the best thing would be to revise the text slightly to admit
> > your first suggestion.  In fact external connections are not
> > forbidden at the moment, but they are strongly RECOMMENDED against.
> > I suggest addding the following text to the end of section 5.4.2.1:
> > 
> >     There may be circumstances under which it is appropriate to relax this
> >     local host restriction, for instance to enable collaboration with
> >     a known external host not capable of Standard Profile communication,
> >     such as a mobile device operated by the hub user.
> >     However, it is RECOMMENDED that Web Profile implementations at
> >     least restrict access to the local host in their default
> >     configuration, and if access is permitted to external hosts
> >     it is only by explicit user request, and to a named host or
> >     list of hosts.
> >     Opening the well-known Web Profile hub server port to the internet at
> >     large would invite denial of service and perhaps phishing attacks
> >     in which the user is bombarded with unwanted SAMP registration
> >     requests.
> > 
> > plus a couple of extra "under normal circumstances" clauses elsewhere
> > in sections 5.4.2.1 and 5.2.3.
> > 
> > Do you think that's a good way forward?  Anyone else have comments?
> > 
> > Mark
> > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
> 
> 

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