Notification of upcoming Tip Expiry date

[fpietrosanti]

It has been requested by a prospect adopter (amnesty international) to have a procedure to provide notification of upcoming expiration of Tip to receivers part of it.

The notification of tip expiration should be configurable from the receiver, both in term of enabling/disabling the feature, and in terms of timing remaining until expiration when they need to get notified.

That's specifically because some of the researcher are "in office" while some other are often travelling, so they may need very different configuration related to notification of upcoming tip expiry time.

[fpietrosanti]

Same of #921, already requested by 2 adopters

[fpietrosanti]

Requested also to be able to configure a secondary notification email for notification of upcoming expiry of new tip.

[evilaliv3]

@fpietrosanti what is the need for a secondary email?

[fpietrosanti]

@evilaliv3 Because it may happen that the researcher, that's a receiver, is away from office for several weeks and in that case it's "team" need to handle the submissions, but those are not part of the receivers and are using temporarily the researcher's receiver account.

In their workflow each research is always part of a "country team", but only 1 or 2 researcher of each team are part of the context receiving the leaks, so because they cooperate by using "group email / distribution lists", that's a way to integrate within the way they cooperate usually.

[evilaliv3]

mmm ok i understand the reasons but i've some doubts:
configuring a secondary mail without a secondary loaging support unsecure usages where the password is shared among receivers, reducing not only security but a accountability also.

if i'm not concerned with the security behavioure, i'm against a simple solution like the one you are following to not lose the accountability possibility offered by the platform that would be probably fundamental for setups like the ones of a PA.

i think that the good direction would be to implement a more complete solution like the 1) tip invite we have already implemented 2) node invite or something like this eventually associated with the receiver.

[fpietrosanti]

@evilaliv3 but that would not fix the issue, when the researcher is on holiday or in-country, he cannot invite anyone to work on the tip as a receiver, he only have his co-workers team that are backing him during a limited period of time

[evilaliv3]

i agree. but having such a feature and supporting by let say "default" a shared password behaviour makes accountability not possible.

1. who will have the legal responsibility for the actions taken on the platform?
2. the whistleblower will be notified of this temporary change?

sorry if i'm precise in stating this opinions but i think accountability and transparency to the wb as the core components we have and we need eventually to enforce, now to reduce.

[fpietrosanti]

@evilaliv3 in that context of use the WB does not know if he's speaking with Joe or David, he's speaking with the "country team" of country-X of Amnesty, so i don't see any accountability issue?

We're just adapting to the internal organizational need of amnesty, that already works that way with their own in-country sources.
Just by using GL, they want to have few ppl of country-team to work actively on GL, with the "country team group" being able to back them when they are not available.

[evilaliv3]

you are mixing two problems.

1. transparency: from web i see only a transparency problem. we have adopters where receivers are important journalist trusted by the WB. if the platform support that behind the users may be different in time this will disrupt this trust. i agree with your probably anwser to your suggestion "hey giovanni but nothing guarantee who is behind the receiver" but i do not want to implement additional features that support this.
2. accountability: in some PA it's required to have a strong accountability so that every action must be logged and we need to know who (what credentials) has been used to access the platform. if we support a feature like the one you are proposing we have also to implement this as a user right disabled by default and that the admin may enable.

[fpietrosanti]

1. It's not this ticket but Hidden Receiver functionality #735 (so, with Hidden Receiver functionality #735 in place, it doesn't matter anymore)

2. it doesn't matter if there is logging or not, if a user is sharing it's access with someone else, you cannot prevent this from happening (and it's already happening, like with IRPI, sharing a single account in multiple ppl).
   It's not written anywhere that a "globaleaks username = 1 person" but it can represent a "working group", depending on how the organization decide to allocate/user access to the system.

[evilaliv3]

yep i agree with the lack of guarantee, but what i was saying is that i do not want to endorse such a shared usage with a feature of the application or i want to try to minimize the reductuion of the accountability. but from the PA point of view i'm satisfied if we introduce the feature with an enable/disable flag to be set by the admin and default disabled.

[fpietrosanti]

@evilaliv3 i got your point, but i really do not see a reduction of accountability when the "receivers" are represented by an organization that's not publicly exposing the individual users. The whistleblower is always dealing with the "organization" and it's up to the organization to decide autonomously who, within the organization, will take care of which tip and when. In such context i really do not see any accountability issue

[hellais]

I don't fully understand what the problem is.

If the receiver is a shared account then the email will not be the personal email of one person, but it will also be a shared email. In which case why do you need a secondary email?

If that is not the case and the account is the personal account of somebody, then we should not encourage it to be used by others. If you want your account to be shared by many people it should be a shared account and it will have a shared email.

Am I missing something?

[fpietrosanti]

@hellais I don't think that we are encouraging any specific behaviour, is just that if their country team is made up of 6 persons, only 1 usually work on the GL stuff, when that person is away from the office, they want the other people of the team to be able to get notified (on their group email account), so that some of the group (acting as a backup person) can log-in to the system.
To me sounds a reasonable behavior that's not solvable by forcing any person from the country team (that normally don't use GL) to have a dedicated account?

[hellais]

@fpietrosanti but then I don't understand why, for your usecase, they don't just setup the globaleaks account using the shared group email from the start? Why should there be two different emails associated to a globaleaks account?

[fpietrosanti]

@hellais because only one person of the group use globaleaks in a normal condition, but what we trying to manage is when that person is away and another person from the group (nor before defined, that normally don't use globaleaks, that can change depending on the time/period) need to take care of the submissions.

[vecna]

well, for sure, in the notification_sched has to be catch this event, reported in the "activities" and eventually via email #921 I guess is a sub-ticket of this one.

[vecna]

I was checking the status of this issue, and is implemented, the Template are present, the email sent are these:

Dear vecna,

The submission [825] related to context something is going to expire in 48 hours.

Log in and check it out before it's too late!

The submission can be accessed:
via Tor at: ADMIN, CONFIGURE YOUR HIDDEN SERVICE (Advanced configuration)!
via Tor2web at: [Ask to your admin about Tor]

Submission date: Tuesday 05 May 2015 14:35
Expiration date: 06/05/2015

Kind regards,
Development Node

But the bug was preventing the triggering of the condition! Now I guess can be closed ?

[fpietrosanti]

Is it configurable as described in the ticket?
"The notification of tip expiration should be configurable from the receiver, both in term of enabling/disabling the feature, and in terms of timing remaining until expiration when they need to get notified."

[evilaliv3]

nope it's still not configurable, let's wait for that before closing the issue

[vecna]

To make it configurable, has to be updated the DB, I'll create a dedicated branch called database-21 from which I start the new branches, covering some of the feature that require it.

[evilaliv3]

great!

let's avoid working on the integration script.
in general i suggest always to avoid writing it before the moment that the patch is near to be integrated in devel. this will help reducing unneded work.

[fpietrosanti]

@evilaliv3 is this released?

[evilaliv3]

nope, it will be released by this week

[fpietrosanti]

Is this finished?

[vecna]

Yes, closing issue.