Open Bug 1733912 Opened 3 years ago Updated 1 years ago

"Do not send a response" does send response on invitations after selecting Gmail online calendar from `Select Calendar` prompt (vs. local calendar with same email)

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Thunderbird 91
defect

Tracking

(Not tracked)

People

(Reporter: dkniel, Unassigned, NeedInfo)

Details

(Keywords: privacy)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

I get an invitation to an event and choose an action and "Do not reply". Tried on Windows and Linux.

Actual results:

A reply gets sent.

Expected results:

No reply should have been sent.

I am also affected with Thunderbird 78.14.0 on Debian Linux.

Confirming. Crystal ball stuff. After some testing, I can reliably reproduce this on 91.1.2 (64-bit) en-US, Win10 with specific circumstances. For some other scenarios it's wfm. Perhaps not fully reduced yet; I'll include some more details than required in case they might matter.
Sending messages without user's consent is quite bad; we should fix this asap -> P2/S2.

dkniel, fbausch, thank you for reporting this! Can you state if your steps have been similar, especially regarding the Select Calendar prompt after accepting the invite?

STR

To reproduce this, you should have two installations of TB 91.1.2 in different folders with different profiles and different email addresses.

Organizer

  • Create calendar event on local TB Home calendar of foo-@-gmx.de (which happens to be on DE version of 91.1.2, Win10)
  • add an attendee, attendeexxxxxx@gmail.com (with an email not handled by the same Thunderbird install, to prevent potential artifacts from inviting another flavor of yourself)
  • Send invite

Attendee

  • Recipient's = attendee's Thunderbird must have two calendars (in my case, same associated email):
  • Open attendee's invite message (on attendee's Thunderbird)
  • Click dropdown arrow next to Accept | v (or Decline etc.)
  • Choose Do not send a response (!)
    --> Select Calendar prompt pops up (see screenshot below): "Which Calendar do you want to import these items to?"
  • Choose the online Google calendar (important! surprisingly, bug won't happen for the local Home calendar, i.e. if you change nothing in the prompt).

Actual

  • in spite of Do not send a response, confirmation email gets sent to organizer foo-@-gmx.de anyway (privacy violation)

Expected

  • Respect user's privacy and honor Do not send a response by not sending a response.
Severity: -- → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dkniel)
Keywords: privacy
Priority: -- → P2
Summary: "Do not send response" sends response on invitations → "Do not send a response" does send response on invitations after selecting Gmail online calendar from `Select Calendar` prompt (vs. local calendar with same email)

Selecting the gmail online calendar in this prompt appears to trigger the bug for me, whereas leaving Home calendar selected does not. Both calendars associated to the same gmail address.

I just checked it with fbausch in both directions and we can confirm the behavior. Using "Home" calendar everything works as expected. Using the other calendar, the behavior is as reported and mails still get sent.

Flags: needinfo?(dkniel)

Additional information from my side. We just found the following behavior while playing around with accepting invitations into different calendars:

  • I sent an invitation to dkniel.
  • dkniel accepted (without reply) into his Home calendar.
  • I did not receive a reply (as expected).
  • dkniel removed the invitation from his calendar.
  • I received a notification that dkniel declined the invitation.

I'm not sure whether this is expected behavior. But for me, it seems wrong that a notification is sent out after the invitation was first accepted without replying.

Small info update:
dkniel and I reproduced that behavior (Home calendar / not-Home calendar) without Gmail calendars, but with calendars located in SOGo Groupware.

It sounds to me this is a confusion of who (what) is doing what.
For the Home (local) calendar, Thunderbird handles everything since there is no server, so Thunderbird sends - or not - the RSVP reply. For google calendar, even if the user didn't say to send a reply, the server may choose to send a reply.
Check the messages, I bet it's just something the Google calendar generated.

(In reply to Magnus Melin [:mkmelin] from comment #7)

It sounds to me this is a confusion of who (what) is doing what.

Yes, that's quite possible...

For the Home (local) calendar, Thunderbird handles everything since there is no server, so Thunderbird sends - or not - the RSVP reply. For google calendar, even if the user didn't say to send a reply, the server may choose to send a reply.
Check the messages, I bet it's just something the Google calendar generated.

Thanks, excellent technical analysis as usual! Now that you're saying it, I think that's what happens.
I've attached the undesired response message which was sent from the gmail attendee, and iiuc, it does look generated by Google calendar:
Sender: Google Calendar <calendar-notification@google.com>

Perhaps the question still remains if there's anything we can do to improve the UX?
Allowing the user to choose "Do not send a reply" whilst this will have no effect for some/all(?) online calendars (per this bug) is confusing UX. Alex?

  • Do we have any way of knowing and/or controlling if an online calendar will auto-send a reply?
  • Should we disable "Do not send a reply" for online calendars, if they always follow their own rules which we cannot control?
Flags: needinfo?(alessandro)

Uh, that's annoying, you silly Google.

Do we have any way of knowing and/or controlling if an online calendar will auto-send a reply?

I'm not sure, if we could detect that it would be optimal as we can expose this information to the user.

Should we disable "Do not send a reply" for online calendars, if they always follow their own rules which we cannot control?

We might, but that depends on the level of control/knowledge we have.
We could warn the user with a non-intrusive notification that some providers might ignore the "Do not send a reply" request if we detect that the currently used online calendar might do that, rather than disabling the button without an explanation.

The optimal solution would be to check if the calendar does this independently and warn the user about being beyond our control.
Lasana might know something. He's PTO this week, FYI.

Flags: needinfo?(alessandro) → needinfo?(lasana)

This seems out of our control and a google calendar problem to me. Maybe something to add to a FAQ somewhere.

Flags: needinfo?(lasana)

(In reply to fbausch from comment #5)

...
I'm not sure whether this is expected behavior. But for me, it seems wrong that a notification is sent out after the invitation was first accepted without replying.

There should be a prompt asking whether to notify the organizer that you are no longer attending the event.

Coming back to this now that there are more tests. For the remote calendars that send out the response still. Is the "Prefer client-side email scheduling" box checked?

Flags: needinfo?(dkniel)
Flags: needinfo?(bugzilla2007)

(In reply to Lasana Murray from comment #12)

Coming back to this now that there are more tests. For the remote calendars that send out the response still. Is the "Prefer client-side email scheduling" box checked?

No (assuming that the checkbox is always unchecked by default, and knowing that I haven't changed it).

The checkbox lives here:

  • right-click on Calendar in list of calendars > Properties
Flags: needinfo?(bugzilla2007)

I've tried hard, but I'm failing to reproduce this on TB 102.1.2 (64-bit), Win10, with Prefer client side email scheduling unchecked (default), with pretty much the same STR of my comment 2, only using my bmo-gmail address for sending the invite.

fbausch, are you still able to reproduce using my comment 2 (or other steps)?

Flags: needinfo?(fbausch)
Flags: needinfo?(dkniel)
Priority: P2 → --
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: