cesine
commented
9 years ago Yeah, we need to fix that privacy policy page which came from a social sharing website. We did clean it up for the psycholing dashboard, because psycholing dashboard needs a real privacy policy if we have to support real schools. Maybe we should bring that one over for the time being, to get rid of the oddities in the current one. Take a look and see what you think: http://get.example.ca/en/connexion/confidentialite/
The only real privacy policy we really have for the project is very simple. Its in the top grey box, which is what new developers/support team members must agree to. This states clearly that we can't provide any private data (neither affiliations nor language of private corpora).
Privacy policy & disclaimer:
Your data is your data. In the spirit of transparency we provide you with these templates of standard social web app privacy policies and terms of service to fully explain the data involved in Example.org. There are two types:
- data which is typical data that most social websites use to make sure their app is user friendly and to let users trust each other and collaborate, and
- data which is your fieldlinguistics data (your "Corpus") In both cases, we don't use your private data, and we have no partnerships with third parties. In fact, we try to avoid collecting any sensitive private data about you. We would also be happy to give you your private data, just request it.
However : we are a team of Open Source volunteers, as such we have no legal team, no customer support team and we want you to know that Example.org and the software that runs on it is provided AS IS, WITH NO WARENTEE, NO FORMAL SUPPORT AND NO GUARENTEE THAT IT WILL OR WILL NOT DO ANYTHING. If you are worried about these things, we prefer that you set up your own private server so that we don't have to worry about the legal implications of hosting your data.
We are still waiting for the advisory board to meet and draw up a constitution, which includes handleing the details of things like this... but also what will we do with users who violate the app, for example use it as an illicit video/image sharing platform! so far it hasn't happened but it might...
Applying the privacy policy
I know that tracing this down to the whitepaper and confidentiality discussions won't tell you exactly that "affiliations and language of private corpora are private." Instead you should try to apply the above paragraph, in simple words, everything is in the system private. Each corpus and user has a public profile which they can edit which is shown on their page, these are what they choose to show to the general public/search engines about their project.
By default it just shows their username, and "Private Corpus" and if you hover over their link, you can see the pouchname (which is how i figured out what language the field methods groups are working on. This is a violation of privacy too, and its not supposed to be there but it is because the corpus pages implementation wasn't finished correctly yet so it still needs the pouchname in the url in order to open the corpus page). They have to explicitly edit it for it show anything more (currently using the prototype, but in the future they will be able to do it on the corpus page itself).
But for a more clear understanding applying the division of private and public corpus data works like this:
- The CouchDB manages permissions.
- All databases are private, all of them.
- Some databases have been shared with the public user, those databases can be queried by the public user.
- Those are "public" databases in the sense that computational linguists or scripts, or apps can view the contents of those databases (unless the data is encrypted=confidential in the database).
- Each database has 2 docs in it which are for the public eye
- One is the public mask of their team, which contains the team's name, research interests, affiliation etc.
- One is pubic mask of the corpus, which contains details about their project (terms, license, conditions, description, title) which the team wants to be shown on their corpus page
The division of private and public activity data works like this:
- The CouchDB manages permissions
- All activity databases are private, all of them.
- Only logged in members of the team can see the actual contents of activities, which we have deemed helps make users able to trust each other and collaborate. This means team members can see eachothers private activities on that corpus, since htey are not really private but affect the corpus.
- We have an activity heatmap which can display aggregated activity by type in a corpus, which we have deemed helps make users able to trust the app, trust each other and collaborate. This means anyone can see if a corpus is busy or not, which helps understand if anyone is using the app, and what parts of the app they like, it also is a measure of data quality on a corpus so you might only request access to a corpus which was active and is "finished" or was and still is active... depending on what you expect from that project (ie they might have imported a completed project from a previous grant)
I still think this level of implementation detail is irrelevant and probably not useful for users to know since it is a rather common pattern in any social sharing website. Its easier to remember this: Everything is private by default. If the user chooses to make it public, then it's public.
See Emmy's Impulsatives corpus for an example of the team profile, and the corpus profile. Here we can see that the corpus is
- on Quechua, Finnish, Albanian, Bulgarian and
- it's affiliation is University of Delaware. https://www.example.org/mecathcart/impulsatives/mecathcart-impulsatives
from hisako: Do we have an explicit privacy policy written somewhere besides the privacy policy page? The content of the privacy policy page is partly customized to the project, but still largely a template of a generic policy statement. I am afraid that this may confuse people so I didn't refer to it in my reply. I looked at the White Paper and other docs but in terms of confidentiality, we are mostly concerned with the actual linguistic data points (utterances) and consultants' identity; we don't explicitly say language #1767 and affiliation #1766 info are private (by default). Should we maybe update the policy (e.g. removing phrases like "business transactions")?