Add export details to html printed version of chatlist and chats

[Meteor0id]

.exportDetails {
display: hidden;
}
@media print {
.exportDetails {
display: block;
}

<div class="exportDetails">
<span>render datetime 15-feb-2024 15:14</span>
<span>Signal android version xx.x</span>
<span>Signal andorid export date</span>
<span>Signal desktop version xx.x</span>
<span>checksum xyz</span>
<span>export options: includeStickers, includeDesktop, includeCalllogs</span>
</div>

Not sure what details exactly we can list but the point is to add information which shows what was exported when and from what source files. By default this info should be added to every html export but can be toggled off (opt-out not opt-in!) using argument --no-export-details This kind of information is useful for archiving. Maybe a checksum of some kind might help but of course you can't actually proof that a html export was not tampered with.

[bepaald]

I'm open to this in principle. But,

(opt-out not opt-in!)

Why so adamant about this? I definitely prefer opt-in.

Also

render datetime 15-feb-2024 15:14

That's fine (already present in a comment at the top of every page, together with the version of this tool and the databaseversion)

Signal android version xx.x

Not available

Signal andorid export date

Not available

Signal desktop version xx.x

Not available (Does not even make sense really, this tool works with Android backups. There is no way to know if any content was sourced from elsewhere, let alone what version of some program the user happened to have installed on their computer)

checksum xyz

Of what, the backup file the html was exported from? I could do that, but as you say, I don't know what good it would do.

export options: includeStickers, includeDesktop, includeCalllogs

Certainly possible.

On which of the pages would like to show this block (all of them)?

[bepaald]

Signal andorid export date

Maybe an acceptable alternative is to show the datetime of the first and last messages in the backup? Those are easily retrieved.

Are you still interested in this feature with its many limitations? Where on the page (which page) do you think this block should appear? Right at the top, or below the title? At the bottom?

[Meteor0id]

I would put it at the bottom of each html file (not on each printed page).

The goal of this feature is to provide some information about what was exported when. In my mind mostly used when a Signal export is used as evidence or as disclosure, such as asking a government department to share all communication about a certain topic, you want to see what dates have been included and what. Something to support the scope of what has been exported.

Opt-out to avoid the "oh didn't know there was that option" or "forgot to turn it on".

question is what information is available and says something useful about the scope of the export? Obviously this is not some kind of tamper proof mechanism, but just there to prevent misunderstandings. The datetime of when the export file was greated would be great but is only available as the file name of the export file if it wasn't modified. But that sort of stuff.

[bepaald]

I would put it at the bottom of each html file (not on each printed page).

Ok

The goal of this feature is to provide some information about what was exported when. In my mind mostly used when a Signal export is used as evidence or as disclosure, such as asking a government department to share all communication about a certain topic, you want to see what dates have been included and what. Something to support the scope of what has been exported.

Opt-out to avoid the "oh didn't know there was that option" or "forgot to turn it on".

Yeah, I figured something like this. Not fully convinced though. Anyone being summoned to produce an export made by this program (already unlikely), would surely need to be thoroughly instructed on the procedure. They will almost certainly not know of this programs existence and would need to be told how to run it (including telling them to add --exporthtml (and --includecalllog, and...), so what's one more instruction?

Also, as evidence, an export like this is still completely useless, the HTML can be edited at will. And even if somehow you could verify the integrity of the HTML (impossible I think), the backup file itself can be edited at will with this same program. So, one would need to have compliance from the other party (and trust in this fact), in which case, asking them to add another option ­— again — shouldn't be problem.

question is what information is available and says something useful about the scope of the export? Obviously this is not some kind of tamper proof mechanism, but just there to prevent misunderstandings. The datetime of when the export file was greated would be great but is only available as the file name of the export file if it wasn't modified. But that sort of stuff.

Just throwing everything I could think of in there, current work-in-progress looks like this:

Nothing implemented yet, everything there is just hand-typed if it wasn't obvious. Also a note on the list of options: these will only be the options that pertain to the htmlexport() function (those the function has access to). An alternative would be to just save and pass around the entire command line, but that would include passwords which would be bad, or a lot of work to filter those out, which would also be bad.

Thoughts?

[Meteor0id]

I think all I read and see here looks great. Best achievable and might be useful to some.

Yeah any kind of integrety check is non-sense other than making it slightly more effort to ediy en export, not worth any efford.

But showing dile name and scope of the export like in your example is useful.

Well you know, the Dutch goverment was having issues with Sugnal because it wasn't possible yo properly archive it. With the existance of this tool that is no longer true. It would take a minimal efford IF they do not use iPhones for work but typically they do not. At least it invalidates that argument, now lets give them time to discover and adopt this tool. Surly they already know it exists, a simple google search would show it.

[bepaald]

I had a first go at this. I've excluded the searchpage for now (though I don't mind adding it if you want).

On most pages it looks fine, pretty much identical to the screenshot above. But — if the print preview is correct — some weird things are going on there... While in Firefox's built-in inspector it looks fine with the media print css switched on, in the print preview the details section often doesn't appear (fully) below the conversation-box, but running partly or completely through it. I've also noticed conversations where multiple entirely blank pages are inserted, mostly around sticker-messages (and sticker-messages seem to generally take an entire page for themselves). I suspect that was already the case before adding the exportdetails though. I think the media print rules need some work...

So, this is probably still a work in progress-version. I haven't played around with it much, so maybe it's easy to solve, but it's not gonna be today.

You can test it out and see if you find errors, it's behind --addexportdetails (at least for now).

[bepaald]

I believe I fixed almost all print-css-weirdness (by removing just one line in the css). So, this issue may be solved. Let me know if it looks ok when you have time. Thanks!

[bepaald]

So I think this issue is finished, the details look pretty much like in the screenshot and I see no (unexpected) strangeness in print mode. Also, I've added the option to the README and the --help output. If you find anything wrong this issue can always be re-opened. Thanks!