Language rework

[comradekingu]

Says Python 2 though, not 3. Is that intentional?

[coveralls]

Coverage remained the same at 65.831% when pulling 955abe087dd44f06fc5a0d80fad13a5c0db1fee9 on comradekingu:patch-2 into 21ce9d8379a08c17cbdcc1411e47dfde4c556507 on Ghini:ghini-1.0-dev.

[comradekingu]

@mfrasca Nontheless, it is evident it has been sent, as the response is from someone who wouldnt otherwise be able to.

[mfrasca]

Background information: What happened in the past, I had a user scared by the fact that I was seeing automatic error reports from his machine, and I had identified him, and asked him about the issues. "what else does it send over the network", you know, as if it was a black box and not a completely transparent container. This is why I want to mention our registration service early. We use Sentry, and a Sentry-Handler, so all logging at severity warning or higher gets sent to our Sentry registration service, the same that has received your initial registration. A registration is nothing else than a logging message at severity info, forced its way to the sentry server by a more sensitive sentry handler. If you register, then I know that you own this machine, and I might ask you about the automatic error reports if I see any. I think that mentioning early is better than explain late, even if the current formulation only scratches the surface of the matter. (Sooner or later, we should really have a sentry server at sentry.ghini.me, but before that we need to have a certificate for ghini.me, so the messages can travel encrypted as it is the case now…)

[comradekingu]

@mfrasca You can't have user-identifiable information sent automatically without prior notice. As per EU GDPR laws.

Otherwise I can try to rewrite that, possibly feature it somewhere else?

[mfrasca]

if you would be able to restate that, yes, please. a registered user lets me associate a sentry client to a machine name. unregistered machines can still send information that with some guess-work could be in the end traced back to a user, but I would not call that "user identifiable".

[mfrasca]

actually, the point is more when the user double clicks on the use_sentry_client configuration line. we should really have a callback on that one, that pops up a clearly formulated text, complying with what you mention. now it just toggles True/False. it obviously defaults to False!

def on_prefs_prefs_tv_row_activated(self, tv, path, column):
    global prefs
    modified = False
    key, repr_str, type_str = self.prefs_ls[path]
    if type_str == 'bool':
        self.prefs_ls[path][1] = prefs[key] = not prefs[key]
        modified = True
    if modified:
        prefs.save()

[mfrasca]

we currently have Python docstrings associated to these preferences (particular case), but we don't show them in the user interface, you only get to see them with help(bauble) in python. my preference goes towards the most generic solution, and I'm considering, please give your opinion, we could add in the Python docstring some marker text like "we are required to double check your permission", which, if found in the docstring, will pop the message and undo the change if the user does not confirm.

[mfrasca]

oops, sorry, I made a mistake, by renaming before merging. will be back soon.

[comradekingu]

@mfrasca "We are required" sounds reluctant. Saying why is preferable. "In compliance with EU GDRP laws, access to all user-identifiable information must be explicitly given by you. As a reqister user, you can opt into sending user feedback automatically. This can be used to identify you." How though?

[mfrasca]

well, it's two different things we are talking about:

• I was looking for a generic text that would trigger the software to ask for confirmation, maybe there will be other options that could better have a confirmation pop-up.
• You are now already thinking of the specific text.

Also, the point is that users provide information in two moments: one when they register, and that is the real user-identifiable information they send. two (and counting) if they opt in for automatic feedback, every time there's an issue. only if they provide the initial user-identifiable information, the automatic feedback can be associated to a person, otherwise it's untraceable statistics. (this last part, I am not so absolutely sure, but I can work on it)

about your text, 1) In compliance with EU GDRP laws, access to all user-identifiable information must be explicitly given by you. 2) As a reqister user, you can opt into sending user feedback automatically. 3) This can be used to identify you." 1: perfect, just fine. 2: also not registered users can opt for sending automatic feedback. 3: "automatic feedback is always associated to the name of a workstation. if you send in your registration, you are actively associating your personal data to your workstation. if you do not register, we will not attempt reconstruct the association you did not send us, but be aware that if your name is John Doe and your workstation is called JOHN_DOE_WORKSTATION, then what are you talking about privacy?"

but all this text in a pop-up ... ? maybe better: 2) As a user, you can opt into sending user feedback automatically. 3) Such automatic information can and will be associated to you if you are a registered user. It is otherwise anonymous.

(but I still need to check if I can anonymize the workstation name)

[comradekingu]

@mfrasca I think confirmation has to be given once you enter the details, that would make the most sense anyhow. And you have to see the whole thing, and click to comply. Ive been getting some retroactive info on how my data is used from some services i'm registered with.

"In compliance with EU GDRP laws, access to all user-identifiable information must be explicitly given by you. Registered or not, you can opt into sending user feedback automatically. This can be used to identify you because the username you pick could possibly be the same, or similar to, the name of your computer/workstation. No attempt will however be made to reconstruct this association, and it is not stored"

Questions, 1 Why not anonymize workstation usernames, or don't record them 2 Is the information sent encrypted or not? 3 How long is what stored for 4 What exactly is it used for

[mfrasca]

1) I'm not sure how hard that would be, but yes, that's what I was also considering. 2) I quite think so, but I don't remember checking. 3) until either sentry.io or a developer deletes it, it can be up to 4 months. 4) debugging.

point (1) could be sufficient indeed, just hash the server_name before formatting the logging record. so if the user registers, they're identifiable. unregistered users would be anonymized.

[mfrasca]

1. how to hash the client name:

       logger.debug('registering sentry client')
       sentry_client = Client('https://<key1>:<key2>@'
                              'app.getsentry.com/45704')
       sentry_client.name = hex(hash(sentry_client.name) + 2**64)[2:-1]
       handler = SentryHandler(sentry_client)
       logging.getLogger().addHandler(handler)
       handler.setLevel(logging.WARNING)

it stays (probabilistically) unique, we can't revert the hashing, and if the user does register, then it's the user explicitly telling us.

2. this also answers "is it encrypted": yes.

[mfrasca]

so you're suggesting we add a pop-up to the 'register' button, where extra confirmation is required, and what about this:

"In compliance with EU GDRP laws, access to all user-identifiable information must be explicitly given by you. Registering comes down to the same as sending an email to ghini@anche.no and telling us who you are. We will reply to you, and we will occasionally send you news, possibly once or twice a year. Registered or not, you can opt into automatic bug reporting, which alerts us of error conditions in the software. Such automatic user feedback is not associated to you unless you register. We don't do user-profiling, we don't share any information with third parties, we only care for software quality."

[comradekingu]

"Telling us who you are" in what capacity? Who is "us"?

Don't muddle it in with a newslist, make that a different thing to explicitly click. If I want one thing, I get one thing, If i want two things, I get two. No one thing has to be accepted to get another.

[mfrasca]

what about this then? -»We will reply to you, and we will occasionally send you news, possibly once or twice a year« +»A developer will respond, to acknowledge your registration.« and dropping the last sentence.

currently I don't do anything close to user registration as done by companies, I just receive registrations, send an acknowledgement, and delete the registration, since the info is now in my email system. there isn't any database, except the one for automatic bug report, and that is anonymised now.

[comradekingu]

It is turning into a unclear block of text, try:

"Registered or not, you can opt into sending user feedback automatically.

Send anonymous user feedback [ ]

The following information will be collected 1 Info about your use of Ghini, specifically ?

In compliance with EU GDRP laws, access to all user-identifiable information must be explicitly given by you.

Sign up for newsletter [ ]

The following information will be collected 1 Your e-mail address 2 Your account

It is sent to you unencrypted, so your interest in Ghini can be tracked to your e-mail account.

Register as a user on Ghini to de-anonymize user feedback [ ]

The following information will be collected, and not shared with anyone 1 2

This is sent encrypted, and can be used to identify you because the username you pick could possibly be the same, or similar to, the name of your computer/workstation. No attempt will however be made to reconstruct this association, and it is not stored beyond ?"

[mfrasca]

just to fix ideas: when we're talking of registering, it's this dialog window I'm thinking:

I can add a confirmation window to the 'register' button, and the text in this new window should explain that by registering, the anonymized workstation name will be de-anonymized. Registered users will receive a welcoming email, when a developer has the time to write one, and that's it. The information you write in the dialog box is the information sent to the registration service. You can choose what to write, what not to write. You can also decide to register, and then to fill in the rest of the data.

I would drop the whole story about the newsletter. there isn't any, it's just from time to time writing to stay in contact with people who registered. if you have better ideas, I'm all ears. we could also invite registered users to a mailing list. Would that would solve anything? or would it complicate things?

the other one is the one I just anonymized. I would not call it user feedback, it's more »automatic anonymous bug reporting«. there is no personal information in it, none. It's not good practice, putting personal information in the logs and I do not put any in Warning and Error. But still, it is information being sent. it is encrypted, solely for debugging purposes, not retained beyond bug solving, and is not associated to a named user, unless the user registers. So if you register, and you choose to send automatic bug reporting, this bug reporting isn't anonymous any more, and a developer might contact you if they consider it helpful, or possibly just to tell you that the problem you were experiencing has been resolved.

[comradekingu]

@mfrasca

I guess the * is required. Which would make everything else optional, and I think that covers it. The idea of "what is a registered user?" is a bad arbitration.

Mouseovers can explain things more clearly.

I think maybe a divider here and then the tech contact and additional questions below it would be good, because now it looks like one registers contact email.

Edit: One of the e-mails I got was:

On May 25th, GDPR laws come in to effect providing you with more rights and control over the way in which your data is used. As a result, in order to continue sending you our special offers and product news we need you to confirm that you are happy for us to do so. If you are happy to continue receiving our newsletters please click the link below and follow the instructions.

Which suggest detailing the info sent and confirming it explicitly is important for newsletters.

[mfrasca]

formatting the table, we are within Gtk+, and use glade files. you probably want to have a look at the sources for this dialog window (bauble/plugins/garden/institution.glade). doing it in columns as you suggest, one would need split in no less than 8 homogeneous columns, something like this: which is definitely possible, it's just again more work. :scream:

when we move to gtk3, then we will have a map widget, which will allow uses enter the coordinates by clicking on a dynamic map.

I'm not so sure why tooltips are in the code (py) and not in the interface definition (glade). but we do have tooltips and that lets us keep labels short enough. no need for lengthy stuff like "contact info for developer communication".

institution name is "compulsory" in the sense that if you don't fill this in, the dialog window will show up again next time you start ghini. there's a text explaining this.

email address is currently next to registration button (and I want to keep it like that) because if the user gives an email address, then registration is possible, otherwise the button stays dormant.

I don't really want to mention "ghini newsletter" because I'm afraid I can't make expectations come true. I write from time to time, when I have time, when I get news related to the garden in question, but there's no newsletter. the thing coming closest to a newsletter could the RSS feed, at https://ghini.github.io/feed.xml and yes, maybe we could advertise it here, or add the link to the help menu.

registering on the public map, that we could indeed offer straight away in this dialog box.

I'll think about it, thank you for all this constructive feedback!

have you checked the letters? they are online, I'll make sure they are offered for translation.

[comradekingu]

@mfrasca Translated. Could you make me an admin on Weblate? Then I can upload screenshots, add the plugins and so on. It would be really nice to edit the source directly on there.

[mfrasca]

Hi @comradekingu , what is it that you can't do without being admin on weblate? screenshots, I already had someone mentioning them as an expected help, but I do not have the time for this too. what about plugins? and the so no? anyhow, you are admin now. what source you cannot edit directly where? I tend to keep everything open, I'm only (very) stiff on architectural design, on that I need the last word, so please, big changes call, discuss, and ask again 24h later, to check if I am still of the same advise.

[comradekingu]

@mfrasca There are some plugins you can turn on to have strings remain fuzzy when replaced and so on. I know it is possible to have a setup where "English" is just a branch that edits the upstream source files. I don't do anything drastic like that, but it is really nice to have permission for smaller things.

[mfrasca]

a setup where "English" is just a branch that edits the upstream source files

I'm all ears, but it's night time here, just elaborate, explain, sounds interesting.