fix python lint errors
receive pre-mesages, start with changes to imap loop.
refactor: move download code from `scheduler.rs` to `download.rs`, also
move `get_msg_id_by_rfc724_mid` to `MsgId::get_by_rfc724_mid`
`MAX_FETCH_MSG_SIZE` is no longer unused
Parse if it is a pre-message or full-message
start with receiving logic
get rid of `MsgId::get_by_rfc724_mid` because it was a duplicate of
`message::rfc724_mid_exists`
docs: add hint to `MimeMessage::from_bytes` stating that it has
side-effects.
receiving full message
send and receive `attachment_size` and set viewtype to text in
pre_message
metadata as struct in pre-message in header. And fill params that we can
already fill from the metadata. Also add a new api to check what
viewtype the message will have once downloaded.
api: jsonrpc: add `full_message_view_type` to `Message` and
`MessageInfo`
make PreMsgMetadata.to_header_value not consume self/PreMsgMetadata
add api to merge params
on download full message: merge new params into old params and remove
full-message metadata params
move tests to `src/tests/pre_messages.rs`
dynamically allocate test attachment bytes
fix detection of pre-messages. (it looked for the ChatFullMessageId
header in the unencrypted headers before)
fix setting dl state to avaiable on pre-messages
fix: save pre message with rfc724_mid of full message als disable
replacement for full messages
add some receiving tests and update test todo for premessage metadata
test: process full message before pre-message
test receive normal message
some serialization tests for PreMsgMetadata
remove outdated todo comment
test that pre-message contains message text
PreMsgMetadata: test_build_from_file_msg and test_build_from_file_msg
test: test_receive_pre_message_image
Test receiving the full message after receiving an edit after receiving
the pre-message
test_reaction_on_pre_message
test_full_download_after_trashed
test_webxdc_update_for_not_downloaded_instance
simplify fake webxdc generation in
test_webxdc_update_for_not_downloaded_instance
test_markseen_pre_msg
test_pre_msg_can_start_chat and test_full_msg_can_start_chat
test_download_later_keeps_message_order
test_chatlist_event_on_full_msg_download
fix download not working
log splitting into pre-message
add pre-message info to text when loading from db. this can be disabled
with config key `hide_pre_message_metadata_text` if ui wants to display
it in a prettier way.
update `download_limit` documentation
more logging: log size of pre and post messages
rename full message to Post-Message
split up the pre-message tests into multiple files
dedup test code by extracting code to create test messages into util
methods
remove post_message_view_type from api, now it is only used internally
for tests
remove `hide_pre_message_metadata_text` config option, as there
currently is no way to get the full message viewtype anymore
Update src/download.rs
resolve comment
use `parse_message_id` instead of removing `<>`parenthesis it manually
fix available_post_msgs gets no entries
handle forwarding and add a test for it.
convert comment to log warning event on unexpected download failure
add doc comment to `simple_imap_loop`
more logging
handle saving pre-message to self messages and test.
This way, the statistics / self-reporting bot will be made into an
opt-in regular sending of statistics, where you enable the setting once
and then they will be sent automatically. The statistics will be sent to
a bot, so that the user can see exactly which data is being sent, and
how often. The chat will be archived and muted by default, so that it
doesn't disturb the user.
The collected statistics will focus on the public-key-verification that
is performed while scanning a QR code. Later on, we can add more
statistics to collect.
**Context:**
_This is just to give a rough idea; I would need to write a lot more
than a few paragraphs in order to fully explain all the context here_.
End-to-end encrypted messengers are generally susceptible to MitM
attacks. In order to mitigate against this, messengers offer some way of
verifying the chat partner's public key. However, numerous studies found
that most popular messengers implement this public-key-verification in a
way that is not understood by users, and therefore ineffective - [a 2021
"State of Knowledge" paper
concludes:](https://dl.acm.org/doi/pdf/10.1145/3558482.3581773)
> Based on our evaluation, we have determined that all current E2EE
apps, particularly when operating in opportunistic E2EE mode, are
incapable of repelling active man-in-the-middle (MitM) attacks. In
addition, we find that none of the current E2EE apps provide better and
more usable [public key verification] ceremonies, resulting in insecure
E2EE communications against active MitM attacks.
This is why Delta Chat tries to go a different route: When the user
scans a QR code (regardless of whether the QR code creates a 1:1 chat,
invites to a group, or subscribes to a broadcast channel), a
public-key-verification is performed in the background, without the user
even having to know about this.
The statistics collected here are supposed to tell us whether Delta Chat
succeeds to nudge the users into using QR codes in a way that is secure
against MitM attacks.
**Plan for statistics-sending:**
- [x] Get this PR reviewed and merged (but don't make it available in
the UI yet; if Android wants to make a release in the meantime, I will
create a PR that removes the option there)
- [x] Set the interval to 1 week again (right now, it's 1 minute for
testing)
- [ ] Write something for people who are interested in what exactly we
count, and link to it (see `TODO[blog post]` in the code)
- [ ] Prepare a short survey for participants
- [ ] Fine-tune the texts at
https://github.com/deltachat/deltachat-android/pull/3794, and get it
reviewed and merged
- [ ] After the next release, ask people to enable the
statistics-sending
Create unprotected group in test_create_protected_grp_multidev
The test is renamed accordingly.
SystemMessage::ChatE2ee is added in encrypted groups
regardless of whether they are protected or not.
Previously new encrypted unprotected groups
had no message saying that messages are end-to-end encrypted
at all.
this PR adds a info message "messages are end-to-end-encrypted" also for
chats created by eg. vcards. by the removal of lock icons, this is a
good place to hint for that in addition; this is also what eg. whatsapp
and others are doing
the wording itself is tweaked at
https://github.com/deltachat/deltachat-android/pull/3817 (and there is
also the rough idea to make the message a little more outstanding, by
some more dedicated colors)
~~did not test in practise, if this leads to double "e2ee info messages"
on secure join, tests look good, however.~~ EDIT: did lots of practise
tests meanwhile :)
most of the changes in this PR are about test ...
ftr, in another PR, after 2.0 reeases, there could probably quite some
code cleanup wrt set-protection, protection-disabled etc.
---------
Co-authored-by: Hocuri <hocuri@gmx.de>
Display name is rarely needed for debugging,
so there is no need to include it in the logs.
Display name is even already listed in `skip_from_get_info`,
but the test only allowed the values to be skipped
without checking that they are always skipped.
