Automatically extend expiration date of a Tip

[grifti]

Tips have an expiration date after which the Tip is deleted. Journalists have the ability to extend this expiration date, but they have and will forget to do that.

It would be nice to have the expiration date extend automatically when journalists are busy with the ticket, i.e. write messages to the whistleblower. You probably don't want to give the whistleblower the same powers. When a journalist isn't busy with a Tip, expiration of the ticket is correct.

[fpietrosanti]

Hey @grifti, do you think that #921 would fix the issue?

In your request, how do you define that "a journalist is busy with a Tip" ?

[evilaliv3]

@fpietrosanti i think that with busy with the tip @grifti means that the expiration countdown period should be resetted on every receiver action. i think that we can do it automatically as suggested when messagese are sent by the Receiver (not by the wb) and to limit the attack surface eventually performed by the receiver itself we can do this only in the case the admin has granted the tip postpone right to the receiver.

@hellais / @vecna sounds reasonable?

[fpietrosanti]

@evilaliv3 Sounds reasonable but: a) There should be a highly-visible counter with clear, BIG, indicator of "missing number of days" b) This indicator should change when the action has been done by the receiver c) The receiver should be given some kind of visual notice that the indicator has changed, once he is operating on the tip (he shall be made aware of the change) d) It shall apply to any action of the receiver on the Tip, including comments, downloading of files, other interactions with the Tip, not just messages e) It shall be available as a dedicated configuration settings, not implicit to the "Receiver can postpone" but something like "Automatic postpone expiration date on Receiver's action"

[vecna]

@evilaliv3 is a good compromise between the needs and the data retention policy, but I'll suggest, if is automatic, at least the extension can not be of the same amount commonly extended (15, 30 days) but a couple of days. until the receiver click on "postpone expiration date" to get another 15.

@grifti our concern is primary due to the "data retention policy", is a security protection for nodes and journalist. This feature can broke that, and may be dangerous in certain environment.

(@grifti to make an analogy, is like our security assessment has suggested to make a password expire once a while, and you are asking to us "can we keep the same password forever and auto login that never expire" ? :) )

[evilaliv3]

@fpietrosanti / @NSkelsey: this is the ticket where to store notes on what we were discussing.

The summary of the latest discussions is:

• tips expiration should be subject to the last update of the ticket; i.e.: every time we mark the last update, the tip expiration should be updated accordingly.
• implementation as for https://github.com/globaleaks/GlobaLeaks/issues/1716 should be edited so that the access by the whistleblower expire not only in relation to the last access by the whistleblower but also in relation to the last update of the ticket.

[marceloomens]

I'd like to second this tip feature request. Would be very useful!

[evilaliv3]

Like what discussed with @elbill and @giorgiofraschini it would be important to implement this ticket also on whistleblowers side to prevent that an update performed by whistleblowers few days before the expiration ot the report will be deleted without anough time for the recipient to read it.

Probably it would be safe to implement that any update of the report from both whistleblowers and recipients shall ensure that the expiration date is set not shorter than 2 weeks from the update.

[evilaliv3]

\cc @maxmois @larrykind @aetdr: what do you think?

[aetdr]

Hi @evilaliv3

2 weeks seem like reasonable time for recipients to react. Ideally, a submission should not be auto-deleted as long as all messages have not been read by at least one recipient.

[evilaliv3]

Thank you for your feedback @aetdr!

I consider we could safely implement a feature of auto-extend of 2 weeks in case the report is expiring.

I would avoid instead to automatically disable expiration if the message has not been read because this would become critical in conditions where recipients are irresponsible. In this case we would make whistleblowers to be exposed for nothing.

[elbill]

@evilaliv3 I do not understand how this would harm and expose the whistleblower. I percieved what @aetdr proposed not as disabling expiration but as a recurring auto extending if no recepient has accessed the report. Anyway this case is very unlikely.

[evilaliv3]

Than you for the question.

While developing globaleaks we always wanted to protect whistleblowers in the following scenario from the fact that time to time recipients could forget to open new or updated reports. In this condition we want the report to expire anyway because we do not want to expose the whistleblower for nothing.

Think to a governamental project where a political change happen, and the new administration may want to look just who were the whistleblowers and go against them. A strict data retention policy like the one we have would at least reduce the impact of such situation.