Technical Discussion Meeting -- 2014-05-21

  • Present: alisond, carol, jennifer, craig, alastair, roger, toby, neil, kenny bell.

This meeting was to discuss the results from the survey on accessing our systems from mobile devices and to decide on the way forward. The top 5 topics were discussed.

Printing

We need to provide a system that hooks into our existing infrastructure. iOS provide an lprint service, there are various options for android. Purchase a wireless printer. Are there authenticated wireless devices that we could plug into our Xerox MFDs? Can our existing printers take airprint adaptors? Does our existing student web printing interface work for android?

Web

It would appear that the university's move to drupal will solve this issue for the vast majority of websites. Publishers should be encouraged to check their content on mobile devices. Devices are also getting better at dealing with the web.

Authentication

It was difficult to decide exactly what was meant by this and what the users took from the question. ssh - there is documentation available both on computing.help and on IS's pages. weblogin - providing a decent sized log-in box was discussed. It was decided that more usage cases were needed to work out exactly what was required here. Toby will look into authentication on the ipod

VPN/openVPN

This works well on android apart from split tunnelling. There is documentation available both on computing.help and on IS pages. There is openVPN available for iOS7 which Toby will look at, Neil will investigate VPN on android.

AV

Chromecast is a possibility although it would appear that it is limited to hdmi only. Wepresent is currently being used at Farr and Alastair has one on order for the Forum. It can display multiple devices simultaneously and would fit into the podium and use the wireless network. Alison will try out both options.

Reset the Net

From Toby: HSTS (where a web server indicates that clients should only connect via https) - We think this is fairly easily achievable by adding an http header to our servers.

PFS (perfect forward secrecy - essentially that the session key isn't derived from the certificate's private key) - The extent to which we want to support this depends somewhat on our version of apache (apache 2.4 in the best case). However, we can do a lot by setting the cipher suites which apache offers to browsers. Our default (changed in the wake of the beast attack) seems pretty good, but should probably be checked. The danger with setting a restrictive list of cipher suites is that some clients (e.g. older ones) may not be able to connect.

HTTPS-Everywhere - we can't really convert all web-sites to https until we have an automated way of both obtaining and installing "properly-signed" https certificates. Obtaining would be dependent on IS, installing could be done by implementing something using wallet.

Conclusions

We will have a review again in a couple of months to see what we have achieved. The one off questions from the survey should be answered individually.

-- CarolDow - 21 May 2014

Topic revision: r1 - 21 May 2014 - 14:01:07 - CarolDow
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies