4 ms·

Evolution Mail Users Easily Trackable Part 2

26 points by zdw 1y ago

like_any_other 1y ago
Most devs are entirely too casual about making network requests. Do they not share users' expectation that the software won't rat them out to random servers?
deleted 1y ago
[deleted]
drdaeman 1y ago
> Evolution probably does not require any changes whatsoever to fix this. This problem is not specific to Evolution; it very probably affects Balsa and Geary at least, and all other applications using WebKitGTK that wish to audit outgoing HTTP requests. The problem is that WebKitGTK is making HTTP requests that bypass its API for blocking HTTP requests, which Evolution relies on. https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_2500159 https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_...
- mike-cardwell 1y ago
  So, at work, you find out a library you're using is insecure. Do you: 1. Submit a bug report to the library and then do nothing else, for over a year, with no end in sight, and say it's not your problem, you can't fix it, and there's nothing you can do, and you wont tell your users. 2. Address the problem by fixing the library yourself, or getting somebody else to actually fix it, switch to a different library, patch over the problem on your applications side? If number 1 is your answer, you probably shouldn't be distributing software. I'll let Balsa and Geary know about the preconnect problem. Will be interesting to see if they take the same awful approach that Evolution Mail did to addressing it. [edit] - https://gitlab.gnome.org/GNOME/geary/-/issues/1680 https://gitlab.gnome.org/GNOME/geary/-/issues/1680 - https://gitlab.gnome.org/GNOME/balsa/-/issues/99 https://gitlab.gnome.org/GNOME/balsa/-/issues/99
  - mike-cardwell 1y ago
    Andre Klapper went and closed both issues. Presumably he's worried how bad they will look if the devs for either client went and actually addressed this issue instead of passing the buck and doing nothing like Evolution Mail have.
  - brudgers 1y ago
    3. Evaluate the potential risk, the cost of mitigating that risk, competing priorities, the budget, etc. and make an engineering decision.
- mike-cardwell 1y ago
  > it very probably affects Balsa and Geary at least I've just tested, and both fail the link preconnect test but neither fail the dns prefetch test. So the original bug I posted is on the Evolution Mail side, not the Webkit side. If you go back and look at the thread, you'll see they never actually investigated the issue. They just insisted it wasn't their problem. They were wrong. They locked the bug of course, because their feelings are more important than distributing secure software to them, so I have no way of informing them of this. They're just pissed they can't lock my blog and that people are finding out about this issue, outside of their control.
tetromino_ 1y ago
Summary: there is a long-standing bug in Webkit which causes network connection from (probably?) any tag that sets a `rel` attribute to be non-auditable and non-blockable by client code using Webkit. Mike Cardwell stumbled on the manifestation of this bug in Evolution (which uses Webkit for rendering html mail). His proposal was for Evolution to filter html content before passing it to Webkit for rendering. Evolution devs' counterproposal was to ask Mike to write a patch to fix the Webkit bug, so not just Evolution but all other applications built on top of Webkit benefit. Instead of writing a patch for Webkit (or at least further investigating the Webkit bug), Mike responded by writing two blogposts denouncing Evolution devs. Evolution devs responded by locking the bug thread and threatening to ban Mike. TL;DR drama due to cultural difference.
- veeti 1y ago
  This reflects of a failure in security "culture" within the GNOME project. Whether the issue boils down to a bug in WebKit or Evolution code, it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues. Whether that is achieved by changes upstream or in the Evolution project is of no relevance to the end users or general public at large.
  - tetromino_ 1y ago
    > it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues Is it? One could argue that Evolution developers do not ship an end product, and that it's distros - Debian, Fedora, etc. - who ship the end product by combining Evolution at version X with Webkit at version Y, and possibly patching both.
    - mike-cardwell 1y ago
      You use an insecure library in your product, it is your responsibility to deal with that situation yes. You can deal with it by: 1. Fixing the insecure library 2. Getting somebody else to fix the insecure library 3. Switching to a different library that isn't insecure 4. Patching over the problem in your application so that the insecure parts are no longer insecure (Santising and stripping html before passing to Webkit, as many, many other email clients do) 5. Warning the users about the problem (A "do not rely on for privacy" notice next to the feature in the UI, with a link to more info) Evolution Mail wont do any of this. They don't accept any responsbility for the problem. They submitted a bug report to the library and then sat on their hands. If this is still a problem a year from now, they will still accept no responsbility and still claim there is nothing they can do about it, and their users will still be suffering from the problem with absolutely no knowledge about it. I find it astonishing that anybody thinks their approach to this is acceptable, or even normal in the software industry. It's totally bizarre.

26 points by zdw 1y ago

Most devs are entirely too casual about making network requests. Do they not share users' expectation that the software won't rat them out to random servers?

deleted 1y ago

[deleted]

drdaeman 1y ago

> Evolution probably does not require any changes whatsoever to fix this. This problem is not specific to Evolution; it very probably affects Balsa and Geary at least, and all other applications using WebKitGTK that wish to audit outgoing HTTP requests. The problem is that WebKitGTK is making HTTP requests that bypass its API for blocking HTTP requests, which Evolution relies on. https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_2500159 https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_...

mike-cardwell 1y ago
So, at work, you find out a library you're using is insecure. Do you: 1. Submit a bug report to the library and then do nothing else, for over a year, with no end in sight, and say it's not your problem, you can't fix it, and there's nothing you can do, and you wont tell your users. 2. Address the problem by fixing the library yourself, or getting somebody else to actually fix it, switch to a different library, patch over the problem on your applications side? If number 1 is your answer, you probably shouldn't be distributing software. I'll let Balsa and Geary know about the preconnect problem. Will be interesting to see if they take the same awful approach that Evolution Mail did to addressing it. [edit] - https://gitlab.gnome.org/GNOME/geary/-/issues/1680 https://gitlab.gnome.org/GNOME/geary/-/issues/1680 - https://gitlab.gnome.org/GNOME/balsa/-/issues/99 https://gitlab.gnome.org/GNOME/balsa/-/issues/99
- mike-cardwell 1y ago
  Andre Klapper went and closed both issues. Presumably he's worried how bad they will look if the devs for either client went and actually addressed this issue instead of passing the buck and doing nothing like Evolution Mail have.
- brudgers 1y ago
  3. Evaluate the potential risk, the cost of mitigating that risk, competing priorities, the budget, etc. and make an engineering decision.
mike-cardwell 1y ago
> it very probably affects Balsa and Geary at least I've just tested, and both fail the link preconnect test but neither fail the dns prefetch test. So the original bug I posted is on the Evolution Mail side, not the Webkit side. If you go back and look at the thread, you'll see they never actually investigated the issue. They just insisted it wasn't their problem. They were wrong. They locked the bug of course, because their feelings are more important than distributing secure software to them, so I have no way of informing them of this. They're just pissed they can't lock my blog and that people are finding out about this issue, outside of their control.

tetromino_ 1y ago

Summary: there is a long-standing bug in Webkit which causes network connection from (probably?) any tag that sets a `rel` attribute to be non-auditable and non-blockable by client code using Webkit. Mike Cardwell stumbled on the manifestation of this bug in Evolution (which uses Webkit for rendering html mail). His proposal was for Evolution to filter html content before passing it to Webkit for rendering. Evolution devs' counterproposal was to ask Mike to write a patch to fix the Webkit bug, so not just Evolution but all other applications built on top of Webkit benefit. Instead of writing a patch for Webkit (or at least further investigating the Webkit bug), Mike responded by writing two blogposts denouncing Evolution devs. Evolution devs responded by locking the bug thread and threatening to ban Mike. TL;DR drama due to cultural difference.

veeti 1y ago
This reflects of a failure in security "culture" within the GNOME project. Whether the issue boils down to a bug in WebKit or Evolution code, it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues. Whether that is achieved by changes upstream or in the Evolution project is of no relevance to the end users or general public at large.
- tetromino_ 1y ago
  > it is ultimately the Evolution developer's responsibility to not ship an end product with known security issues Is it? One could argue that Evolution developers do not ship an end product, and that it's distros - Debian, Fedora, etc. - who ship the end product by combining Evolution at version X with Webkit at version Y, and possibly patching both.
  - mike-cardwell 1y ago
    You use an insecure library in your product, it is your responsibility to deal with that situation yes. You can deal with it by: 1. Fixing the insecure library 2. Getting somebody else to fix the insecure library 3. Switching to a different library that isn't insecure 4. Patching over the problem in your application so that the insecure parts are no longer insecure (Santising and stripping html before passing to Webkit, as many, many other email clients do) 5. Warning the users about the problem (A "do not rely on for privacy" notice next to the feature in the UI, with a link to more info) Evolution Mail wont do any of this. They don't accept any responsbility for the problem. They submitted a bug report to the library and then sat on their hands. If this is still a problem a year from now, they will still accept no responsbility and still claim there is nothing they can do about it, and their users will still be suffering from the problem with absolutely no knowledge about it. I find it astonishing that anybody thinks their approach to this is acceptable, or even normal in the software industry. It's totally bizarre.