[idea] use Push API to inform sender when the download is complete

[dannycoates]

This might actually be a nice use case for Push!

https://developer.mozilla.org/en-US/docs/Web/API/Push_API

[AyoAlfonso]

Is this issue still open? Have you found a solution to this ?

[pdehaan]

@AyoAlfonso I believe @abhinadduri has a work-in-progress PR for this at #379; "WIP: added web push notifications for download completion".

[ehuggett]

Has any thought been given to how this feature could be abused if the file receiver is not asked for permission to do so? I think it should be completely optional, like an email read receipt. From a quick read of the pull request it looks like it's triggered by the download of the file itself, not the page that displays the download link, so could the receiver's client signal their desire to opt-in with the request they use to retrieve it? ( ie something like send.firefox.com/assets/download/de7ec7ab1e?notify_sender=true ).

Does this rely upon the service knowing the name of the encrypted file? (n.b. I have objected to this in #417) I'm wondering if it could be achieved with only the fileid being sent in the push notification from the server to the sender. The sender would have to keep a local record of previously uploaded fileid/filename(s) (i assume this does not happen already?) and use this data in the displayed notification.

There would still be some potential problems with this, but they might be acceptable in this context as its unavoidable that the service can compromise the security of the transfer when it is being sent or received (as the users browser will execute whatever JavaScript is sent to it, stealing the encryption key etc) but it should at least be possible to ensure that this cannot happen after it has been completed.

Its probably unavoidable that the sender would store the metadata after the download has been completed. The push notification could perhaps trigger the deletion of it, but it may not be received. The best that would probably be achievable is if it could expire after 24 hours (as it can't be downloaded after that point anyway), limiting the risk to the 24 hour period after the upload. But if the expiry is not handled by the browser (like a cookie, i presume local Storage has an expiry and works the same?) then it could still potentially be available the next time the user uses the service (days, weeks etc later).

[ehuggett]

Notifying the file sender that the file was not downloaded might be of interest to you, Its a lot less revealing and could be done either as an alternative or in addition to the on-download notification.

I think this would be acceptable, despite it being impossible to ask the intended receiver as I outlined above and it still "tattling" on them as it seems to me like a reasonable trade off between privacy and usability on a service that actually deletes you data after 24 hours as a feature, but I'm sure it wouldn't be too hard to find someone that would disagree so no promises 😄

[himanish-star]

@ehuggett ,@dannycoates , If this issue is still up, May I work on it ?

[dannycoates]

@himanish-star I think we still have some UX design things to work out before we start writing code

[himanish-star]

Ok, cool.