[APP][5.0+] FairEmail - Fully featured, open source, privacy oriented email app

Search This thread

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
To HTML gurus: this is my attempt of a custom implementation of "algorithmic darkening" (display messages on a dark background, even though they weren't designed for this) for the original message view on Android before version 10:

https://github.com/M66B/FairEmail/blob/master/patches/invert.html

Result:

https://rawcdn.githack.com/M66B/Fai...097ed999a3e77c56c1b97388c/patches/invert.html

Can this be improved? Are there side effects?
Is it possible to check the original HTML's background brightness before doing this? Because it'd be stupid if an email was already sent with a dark background and a light text, and then inverting the text to dark with a black background 🤔
 
  • Like
Reactions: M66B

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
Is it possible to check the original HTML's background brightness before doing this? Because it'd be stupid if an email was already sent with a dark background and a light text, and then inverting the text to dark with a black background 🤔
That's indeed a potential problem, but I don't know how (yet?).
 

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
That's indeed a potential problem, but I don't know how (yet?).


Apparently there's a while field of science behind the question of what colors are perceived as light / bright. This article is interesting on the topic:


@mkasimd there are no changes needed for "set" background colors, please see the updated example:

https://rawcdn.githack.com/M66B/Fai...aedcdc1448bff3da9879be8cd/patches/invert.html


But this should work too, I think. In the worst case, we can send a few emails with different background colors in a test version before you push an official release. Just to be certain.
 

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
Apparently there's a while field of science behind the question of what colors are perceived as light / bright. This article is interesting on the topic:





But this should work too, I think. In the worst case, we can send a few emails with different background colors in a test version before you push an official release. Just to be certain.
FairEmail already adjusts colors for the reformatted message view, using magic science ;-)

For now I am going to wait what Google says about forcing dark mode. It would be better if the browser did this instead of manipulating the HTML. Maybe I I'll leave it like it is, which means that there will be a message that Google removed dark mode for Android before version 10. Let's say that reviews are not very motivating to workaround Google's decision this problem.
 
Last edited:

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark", in the debug panel, which uses a custom algorithmic dark mode (on all Android versions for now). I would like you to test if this works okay for all messages.

@zinjashike sort on sender will show email addresses and names (if available) with the version.
 
Last edited:

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark", in the debug panel, which uses a custom algorithmic dark mode (on all Android versions for now). I would like you to test if this works okay for all messages.

@zinjashike sort on sender will show email addresses and names (if available) with the version.
Android 12 here. I found some issues with the original message view when the original message has a black background.

The original message view adds white background to the text fields. It looks unnatural. I have attached some screenshots and can also send you the .eml if that helps you.

Edit: seems to invert all colors.
 

Attachments

  • Screenshot_20220705-124501~2.png
    Screenshot_20220705-124501~2.png
    32.9 KB · Views: 29
  • Screenshot_20220705-124508~2.png
    Screenshot_20220705-124508~2.png
    41.3 KB · Views: 29
Version 1.1930 is available on GitHub now.

Changelog/download:
https://github.com/M66B/FairEmail/releases

If you enable debug mode (last option of the miscellaneous settings tab page), it is possible to enable the option "Fake dark",.......
Should I see a difference when being on dark theme already?
Lineage 19.1=A12
Tried it but didn't notice any changes (except of loads of unwanted notices).
 

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
Should I see a difference when being on dark theme already?
Lineage 19.1=A12
Tried it but didn't notice any changes (except of loads of unwanted notices).
If you enable the debug mode and within the debug options the "fake dark" option, you can view the original message in a dark theme. Meaning, you'll have to open the original message view using "[ ]" on a message selected. Also, you might need to enable a dark theme in the Display settings to test this.

____
@M66B, suggestion to improve fake dark:
  1. First check, if a background color is specified
  2. If yes, then convert it into RGB (if not, apply the current "fake dark" and show the message -> the end)
  3. Apply the HSP color model to determine the RGB color's perceived brightness (link below)
  4. If the perceived brightness is below a specific threshold (e.g. 20), then do not change anything and show the original message as is. If the perceived brightness is higher, then apply the already available "fake dark" implementation
This should improve things even if Google re-introducing the method in the Androidx library is definitely the much better option.

Now link to the HSP color model (color palette with the calculated brightness results in the attachment, taken from nbdtech.com)


Basically:

Code:
brightness  =  squareRootOf( .299 * R^2 + .587 * G^2 + .114 * B^2 )

Addendum: a threshold of 20 is an okayish estimate because the material.io dark theme color results in ≈ 18,27 HSP. But then #191919 results in ≈ 25,37 HSP, and #191a19 in ≈ 25,96 HSP. Meaning something between 25 and 30 might be a better estimate. Or an HSL lightness of 0 - 10 %. Both methods can be valid.
 

Attachments

  • AllColors.png
    AllColors.png
    91 KB · Views: 27
Last edited:
  • Like
Reactions: O_DoC and topcaser

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
If you enable the debug mode and within the debug options the "fake dark" option, you can view the original message in a dark theme. Meaning, you'll have to open the original message view using "[ ]" on a message selected. Also, you might need to enable a dark theme in the Display settings to test this.

____
@M66B, suggestion to improve fake dark:
  1. First check, if a background color is specified
  2. If yes, then convert it into RGB (if not, apply the current "fake dark" and show the message -> the end)
  3. Apply the HSP color model to determine the RGB color's perceived brightness (link below)
  4. If the perceived brightness is below a specific threshold (e.g. 20), then do not change anything and show the original message as is. If the perceived brightness is higher, then apply the already available "fake dark" implementation
This should improve things even if Google re-introducing the method in the Androidx library is definitely the much better option.

Now link to the HSP color model (color palette with the calculated brightness results in the attachment, taken from nbdtech.com)


Basically:

Code:
brightness  =  squareRootOf( .299 * R^2 + .587 * G^2 + .114 * B^2 )

Addendum: a threshold of 20 is an okayish estimate because the material.io dark theme color results in ≈ 18,27 HSP. But then #191919 results in ≈ 25,37 HSP, and #191a19 in ≈ 25,96 HSP. Meaning something between 25 and 30 might be a better estimate. Or an HSL lightness of 0 - 10 %. Both methods can be valid.
The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.
 

nadir husain

Senior Member
Aug 31, 2019
325
382
The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.
Strength and prayers. We will all also pray. Best wishes
 
  • Like
Reactions: mkasimd

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
The challenge is to put this in CSS because modifying a message is not an option because there will be many edge cases because CSS/HTML is pretty complex. The reformatted messages view as it is now was months of work and it is still not perfect and will never be because that would mean developing a browser.

At this moment I will keep everything as simple as possible having heard today that the average life expectancy of my mother is one month. Intensive chemo therapies might help (30% chance) and radio therapy is being investigated out of normal treatment strategies. I am feel pretty down right now.
Of course, you should be with your mother. Me suggesting something doesn't mean I expect you to commit something the next hour. Your own life has a higher priority than your projects, and it's completely fine if you do not push any commits for the next month.

But generally speaking, you do not need to implement the logic part through CSS. The conditions when to place the "fake dark" can be set via Java first, thus only inserting "fake Dark CSS" if the conditions are met.

Of course, that comes with complexity as well as increasing the possibility of bugs. It also won't be 100 % correct. It is a "feasible estimate", or an heuristic approach if one wants to call it that way.

That also means that there are valid reasons to not implement it at all. Especially taking in consideration the amount of time you have to put into implementing a near-complete "fake dark" which won't be used anymore if Google updates their Androidx library to include the original method back again (hopefully).

In corporate language, we'd call it "it's not feasible to invest more time and resources in this, so it won't be implemented". Which is fine. As a "product owner", that's up to your judgement :)

P.S.: I hope the chemo helps. With a family friend of mine, it helped her and she has gotten rid of cancer. So, it's not always as "useless" as the probability rate suggests. Stay strong!
 
  • Like
Reactions: O_DoC and 30jp

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
Of course, you should be with your mother. Me suggesting something doesn't mean I expect you to commit something the next hour. Your own life has a higher priority than your projects, and it's completely fine if you do not push any commits for the next month.

But generally speaking, you do not need to implement the logic part through CSS. The conditions when to place the "fake dark" can be set via Java first, thus only inserting "fake Dark CSS" if the conditions are met.

Of course, that comes with complexity as well as increasing the possibility of bugs. It also won't be 100 % correct. It is a "feasible estimate", or an heuristic approach if one wants to call it that way.

That also means that there are valid reasons to not implement it at all. Especially taking in consideration the amount of time you have to put into implementing a near-complete "fake dark" which won't be used anymore if Google updates their Androidx library to include the original method back again (hopefully).

In corporate language, we'd call it "it's not feasible to invest more time and resources in this, so it won't be implemented". Which is fine. As a "product owner", that's up to your judgement :)

P.S.: I hope the chemo helps. With a family friend of mine, it helped her and she has gotten rid of cancer. So, it's not always as "useless" as the probability rate suggests. Stay strong!
We still have some hope. The possibility of radio therapy was a positive surprise.

I would like to implement a "fake dark" for Android before version 10, but I am afraid it will be hit and miss. Setting conditions in Java means parsing and evaluating both CCS and HTML, in other words this will be rather complex (like a browser).
 
  • Like
Reactions: mkasimd

mkasimd

Senior Member
Apr 7, 2021
215
435
Düsseldorf
We still have some hope. The possibility of radio therapy was a positive surprise.

I would like to implement a "fake dark" for Android before version 10, but I am afraid it will be hit and miss. Setting conditions in Java means parsing and evaluating both CCS and HTML, in other words this will be rather complex (like a browser).
True that. If the sender applied the background on the body Tag only, it'd be somewhat manageable to check the HTML and CSS for the background's value, but it's also quite possible that the sender used various div or span levels, and the background styling within the div or span or within the CSS for the div or span. Looking into the various levels of div and span to determine whether it virtually covers most parts of the message will be very complex.

But without doing that, it'd be a solution that somewhat works sometimes, but won't work properly many other times. Or you'd have to parse the HTML and CSS similarly to how a browser does, as you rightly describe.

You coded a great mobile alternative to Thunderbird, but no need to compete with Mozilla on the browser front as well, right? 😉

Jokes aside, browsers indeed are highly complex pieces of software. Perhaps you could add an FAQ pointing to this XDA thread showing why the dark mode doesn't work in the original message view for Android 9 and lower as well as why you cannot just implement an own alternative to it. That would at least answer:
  • Why doesn't it work? (Google removed the required method from the Androidx libraries, so the dark mode is only available within the libraries available since Android 10 now)
  • Why can't you re-implement it? (You'd have to virtually parse the entire HTML & CSS for this to work properly. That's rather complex, similar to a browser. So, it's just not feasible to implement it)
  • Will Google re-introduce the removed method? (You have asked Google about it and hope they will, but it's not likely to happen if the removal was intentional)
Maybe even just un-crossing FAQ #81 and writing it there? 🤔

P.S: I can also add it into the FAQ and send a pull request, if you can't do it in the next few days.
 
  • Like
Reactions: O_DoC

M66B

Recognized Developer
Aug 1, 2010
26,281
56,706
True that. If the sender applied the background on the body Tag only, it'd be somewhat manageable to check the HTML and CSS for the background's value, but it's also quite possible that the sender used various div or span levels, and the background styling within the div or span or within the CSS for the div or span. Looking into the various levels of div and span to determine whether it virtually covers most parts of the message will be very complex.

But without doing that, it'd be a solution that somewhat works sometimes, but won't work properly many other times. Or you'd have to parse the HTML and CSS similarly to how a browser does, as you rightly describe.

You coded a great mobile alternative to Thunderbird, but no need to compete with Mozilla on the browser front as well, right? 😉

Jokes aside, browsers indeed are highly complex pieces of software. Perhaps you could add an FAQ pointing to this XDA thread showing why the dark mode doesn't work in the original message view for Android 9 and lower as well as why you cannot just implement an own alternative to it. That would at least answer:
  • Why doesn't it work? (Google removed the required method from the Androidx libraries, so the dark mode is only available within the libraries available since Android 10 now)
  • Why can't you re-implement it? (You'd have to virtually parse the entire HTML & CSS for this to work properly. That's rather complex, similar to a browser. So, it's just not feasible to implement it)
  • Will Google re-introduce the removed method? (You have asked Google about it and hope they will, but it's not likely to happen if the removal was intentional)
Maybe even just un-crossing FAQ #81 and writing it there? 🤔

P.S: I can also add it into the FAQ and send a pull request, if you can't do it in the next few days.


Updated FAQ:

https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq81

The fake dark option keeps being available though (edit: default disabled).
 
Last edited:
  • Like
Reactions: mkasimd

Top Liked Posts

  • 8
    So, I can safely ignore reviews like this and also any improvement requests, agreed?
    Of course you can do that. You don't need to add any more features, Marcel. Fixing bugs is more than sufficient and highly appreciated.

    Focus on what's more important for yourself.
    5
    Version 1.1948 is available on GitHub now

    Changelog/download:
    https://github.com/M66B/FairEmail/releases

    Edit: this version will be available in the Play store test program too after Google's approval.
    5
    The problem is that the average Play store rating is constantly decreasing and that this is demotivating. For example:
    As I said, I only see the US Playstore where that is certainly not true. 4.7 and steady still today. So maybe the rating is 3.9 and dropping in the German store, I don't know. I would be surprised if that was the case though. In the US store, very few apps get a better rating than Fairemail.

    You have some unfortunate situations for sure in your life right now and we empathize with that. We appreciate the work you put into this app and also your responsiveness to questions, etc. However, some of us would just hope you could see that positive side and good wishes and not focus on the trolls and the few bad reviews, (most of which are the trolls). The trolls see that they get under your skin and that just encourages them.

    Please try to see the glass as half full and not half empty. No scratch that. In the case of the US Playstore rating, the glass really is 94% full. Try not to focus on it being 6% empty.

    Edit: waiting for the next death threat now ...

    Of course, that should not be happening. I would think it is a matter for law enforcement but maybe that is naive of me to think they will or even can do anything.
    3
    Marcel - Please just post links to all the other negative Playstores you refer to. Then maybe we will understand. For now all I see in the playstore is an incredibly excellent rating and almost nothing but people who love the app.
    You may not understand it. And it's okay to not understand everything.

    People have feelings. Marcel does have feelings as well. And you cannot rationalize feelings. You have to respect them the way they are.

    I think we should end this discussion and just respect Marcel's choices.
    3
    Version 1.1948 has an experimental keyword feature: if you enable debug mode in the miscellaneous settings (the last option), you can define global keywords, which will always be available for all folders and for which also a small button will be added just below the message actions.
  • 20
    QUESTION ABOUT FAIR EMAIL OPTIONS:
    Assuming the starting point of no on-device Google Account...

    Q: Which of these Fair Email Google mail server options is "most" private?

    1. 2SV/2FA (using any of a half dozen secondary methods), or,
    2. What Fair Email terms "GMail (Android)", or,
    3. What Fair Email terms "GMail (OAuth)".

    Note Marcel knows the answer, so he can instantly nip this tangent in the bud by answering that question in a single word... (where I suspect the answer is undoubtably #3 but others strongly think it's #1 apparently, so I could be wrong - but it's NEVER gonna be #2.

    The desired single word answer is "none". Google scans all your messages and you can only hope that the gathered information isn't used in an un-private way. Option 1 (assumed to be app passwords) and option 3 do not send extra information to Google. Option 2 requires an on-device Google account. You can control the sync options of a Google account via the Android settings. If these options work as expected and are turned off, no information should be sent to Google. This applies to all other Google services and apps, like Maps and Drive, too. You'll need to go into the settings and turn things off and trust that Google honors this.

    I expect to see no more messages about this subject anymore, with no exceptions for anyone. If you want to continue discussing about this, you should create a new XDA thread for this.
    16
    The next version will have optionally VirusTotal integration, so you can check attachments easily:

    Screenshot_20220723-102554.png
    13
    That guy really needs his email. I wonder who he thinks will maintain the app after he killed you 🤔
    Given the messages I just received I am pretty sure this guy is reading here.

    To this guy: I am doing my best to hold this project together and what you are doing isn't helping, on the contrary. Instead, if the app is dear to you, you can better help and complain to the right people, mainly Google.
    13
    Version 1.1941 is available on GitHub now.

    Changelog/download:
    https://github.com/M66B/FairEmail/releases

    Besides a series of small improvements and minor bug fixes, VirusTotal Integration was added. Please see this FAQ for more information about configuring and using this new feature:

    (181) How do I use VirusTotal?

    Note that the app hasn't been restored in the Play store yet. For the latest status updates, please see here:

    13
    Using a Gmail account in FairEmail will inevitably leak your IP address, and thus your rough location, but nothing else, except the obvious: the messages you receive and sent and their meta data (sender, receiver, subject, etc).

    Note that it is not a good idea to use a VPN to hide your IP address because you'll probably run into "Please log in via your web browser" at an inconvenient moment.

    For HOTP and TOTP I recommend FreeOTP+.

    I think enough has been said about the privacy aspects of a Google account now. Whether a Google account on your device is a privacy concern or not is off-topic here. If you want to keep discussing about this, please create another XDA thread for this. You can leave a link to the created thread here if you wish.
  • 241
    ic_launcher.png

    FairEmail
    Open source, privacy friendly email app for Android

    banner7_long.png


    See here for a description:
    https://github.com/M66B/open-source-email/

    See here for screenshots:
    https://email.faircode.eu/#screenshots

    Downloads:
    https://github.com/M66B/open-source-email#user-content-downloads

    Frequently asked questions:
    https://github.com/M66B/open-source-email/blob/master/FAQ.md

    Please read this before requesting a new feature:
    https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-get-support

    This XDA thread is about using the latest version of FairEmail.

    For support on authorizing an account you should consult the documentation of your provider, see also here.

    Off topic comments are allowed as long they are related to FairEmail and are in the general interest of the followers of this thread.

    Discussion of purchases is not allowed here, please contact me via here instead.
    69
    How was the call with Google today, Marcel?

    Google was pretty friendly and cooperative and told me the favicons are indeed the problem, and it can/should be fixed by updating in the privacy policy to "disclose how your app accesses, collects, uses, and shares user data":

    Privacy Policy​

    All apps must post a privacy policy in both the designated field in Play Console and within the app itself. The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app accesses, collects, uses, and shares user data, not limited by the data disclosed in the Data Safety section. This must include:
    • developer information and a privacy point of contact or a mechanism to submit inquiries
    • disclosing the types of personal and sensitive user data your app accesses, collects, uses, and shares; and any parties with which any personal or sensitive user data is shared
    • secure data handling procedures for personal and sensitive user data
    • the developer’s data retention and deletion policy
    • clear labeling as a privacy policy (e.g., listed as “privacy policy” in title)
    The entity (e.g., developer, company) named in the app’s Google Play listing must appear in the privacy policy or the app must be named in the privacy policy. Apps that do not access any personal and sensitive user data must still submit a privacy policy.

    Please make sure your privacy policy is available on an active URL (no PDFs) and is non-editable.

    So, I have updated the privacy policy and added this new table:

    https://github.com/M66B/FairEmail/blob/master/PRIVACY.md#summary-of-shared-data

    I am not sure if it covers everything, so feedback is more than welcome. @mkasimd maybe you can take a look?

    Note that I have also enabled BIMI, Gravatars, Libravatars and favicons for the Play store version again.

    The short term goal is to release a Play store test version (and associated GitHub version) and to get the update approved. I will think about the next steps after this has been accomplished. Given the huge number of supportive messages I received (much appreciated!) the project will be continued in some form in any case.
    50
    Version 1.1900 is available on GitHub now and in the Play store test program after Google's approval (which is the main goal of this release).

    Changelog/download:
    https://github.com/M66B/FairEmail/releases

    My girlfriend is slowly recovering too :)
    47
    It is time for a new, modern, open source, privacy friendly email client for Android.

    I have just released a first alpha version for feedback on the design and features.

    Not for production use yet!

    Most of the stuff basically works, but be prepared for crashes and error notifications.


    Safe email is a working name, but it is for several reasons not a convenient name, so suggestions for a name are welcome.
    37
    I have just released alpha version 0.15

    Changelog/download:
    https://github.com/M66B/open-source-email/releases

    With a bit of luck the next version can be a beta version.

    I am putting a lot of effort into this project, so thanks are appreciated.