SlHash Privacy

Aspects detailed in this section are important motions and we invite you to read them carefully.

Visibility on Twitter of my requests.

SlHash leans on Social channels (e.g., Twitter, Facebook) and / or on-line messaging (e.g., Skype, Telegram).

Currently the App Unive, and SlHash system that supports it, only and exclusively uses the Social Twitter channel.

This implies that all exchanges are potentially visible as tweets via Twitter. The adverb "potentially" indicates that is the service owner ( "owner" in SlHash terminology) that defines the level of "privacy" associated with it. This is usually chosen based on the specific nature of the service, or if the request implies data that can be part the sphere of privacy even for extension thereof. The user is still left the choice of using or not (opt-out) the service, according to the privacy level associated to it.

Rephrasing it with an example. Let us suppose that:

Now that you have learned the mechanism, if I'm the Mario Rossi student, I can still choose to use the service according to the visibility rules that have been set by the owner of the service. For each service (more precisely to any correspondence #servic / command ") is an explicit icon that determines the visibility rule: public, a" world map ", privately, a closed padlock.

Safety of the student's credentials for access to University facilities.

For accessing information services made available by the University's back-end, you must be logged in, using a username and password. To avoid requiring username and password each time you access a service, the App stores on the mobile device, in a restricted area, such login information. They shall be forwarded to the back end of SlHash which in turn needs to login [on behalf of the student, but without analysing or store any student information or password] and get a session token that keeps the connection open until the App is running or the user request to logout. The session may shutdown for many reasons, some technical (such as inactivity timeout, or expiration of the back-end authentication cookie University)). If necessary the server will require SlHash forward the credentials to the backend of the University 'and open a new session for the student. Again no password to login the relatively to the University student credentials is preserved from SlHash server side.

To clear the credentials stored on the smart-phone simply delete the app.

If you change your credentials (e.g., change the password) of your login to the University, you will have to set them back, symmetrically, also on the App.

Direct access via Twitter (via Twitter official App and via Twitter Web).

The SlHash system back-end checks whether the user was authenticated by the authentication server of the University, and if it were not, a tweet (@reply) is sent with the URL link to the Web authentication page (University login page), which will then proceed through the mobile browser. The same would happen if the use of Twitter is from the web. The authentication would proceed in the latter case via laptop browser.

In no case the credentials or authentication is saved in the browser (either smartphone or laptop). The connections are maintained active for a defined time period after which are terminated exactly as described previously.

Access to pages (user data generated on the fly starting from the back-end data).

Sometime, depending on the inner content of some replies, data can be, and actually is, generated on the fly. It typically happens within Twitter Card Type objects that simplify the use of data and services via Twitter.

The url of the HTML pages that include Twitter Card tags, are protected from unauthenticated access. This follows the same relation path defined for private services and limited visibility, restricted only to the users who have visibility access to the service (who made the request and who generated the reply). No other user can view the conversation and thus such data.

Twitter Privacy Policy and University Privacy Policy.

SlHash can not operate in conflict with the policy of Twitter. Each user has full control of its user profile on Twitter and therefore can unquestionably change the visibility rules and use of their account or make all his/her Tweet protected. These actions may not enable the use of services across Slhash. Even from the University perspective, SlHash works according to the authentication policy of the University itself.

For the removal of the profile on Twitter, see Twitter.

For the Twitter privacy see: Twitter Privacy Policy.

For the University of privacy rules see: Legal notes and privacy.

Credentials, and tracking information stored on SlHash.

SlHash allows access to services either through Twitter or through SlHash credentials. The latter (SlHash credentials) are stored on the server side along with other information such as generic demographics data that may be useful to create more tailored and more responsive services to the needs expressed or implied of SlHash users, whether "owner" and "end-user." Among the data that SlHash could store there are those of location and positioning. Depending on the type of service, sending the coordinates is done on request and requires specific permissions and user actions. Once positioning is activated, it can remain active even when the application is in the background (see the platform on the App, iOS and Android). Where possible the tweets are sent with geo-location.

All collected data is stored in association with a profile.

For the removal of the profile on SlHash consult

Permissions Android application

From version 2.3.0, we introduced the Radio Ca' Foscari Streaming feature into Ca' Foscari App. For the solely purpose of pausing the radio streaming on incoming or outgoing phone calls, Ca' Foscari App uses the permission to access to the phone state. Ca' Foscari App does not use this permission to get any other data related to your phone.