Web platform architecture, user flow and mockups

[zner0L]

We discussed the basic architecture of the Tweasel Web platform. It is based on the following user story:

1. The user lands on the start page and searches for an App
2. On the page of the App, they are shown statistics of previous runs. They might also be shown how many notices and complaint are already going on.
3. The user can start an analysis. We ask for an email to notify the user and connect the proceeding to. If the email is not provided, users get a link to check for completion and can wait by keeping the tab open.
4. An analysis is added to the queue to be dispatched to the analysis system.
5. The users get a notification (email, browser notification, on the website) that the analysis completed.
6. We show the results of the analysis. In case we found violations, we offer the option to send a notice to the processors. Users need to send the notice themselves via their own email service.
7. After the users sent the notice, we wait for them to upload the email as a PDF or .eml file. Alternatively, they can forward or BCC the email to an automatic email address, which will add it to the proceeding.
8. After the email has been uploaded, we set up a notification for the deadline of the notice. This is either a .ics to add to the calendar or an email notification. The user leaves the website.
9. The user comes back to the website, either because the company answered them before the deadline or because we notified them. They are directed to a page where we ask question on wheter the processor answered and what the answer contained. We see these possibilities:
   • The processor claims they fixed the issue. -> We need to check that, see step 3 to 6
   • The processor disregards the issue or claims it isn‘t true. -> a complaint is in order, see step 11
   • The processor did not answer within the set deadline. -> a complaint is in order, see step 11
   • The processors asks for more time. -> The user can set a new deadline.
10. If we determined the processor did not react properly, users are offered with the option to act:
    • If no other users started a complaint via Tweasel, yet, (still open for discussion) we offer the option to do so. We then require the user to provide a list of contacted hosts on their device as well.
    • If there is already a complaint going on, the user can send a recommendation of control to the authority.

Things or systems we need to build for that

• [ ] An account system, where users can lock in via a magic link they can request with their email. Accounts are just lists of proceedings.
• [ ] A system to keep track of proceedings which can be accessed via their tokens. These need not be connected to an account.
• [ ] A queue to keep analyses in
• [ ] A system to the the analysis on
• [ ] An email notification system
• [ ] A not email-based notification system
• [ ] A web interface
• [ ] A system to create PDFs from .eml emails safely
• [ ] A magic email address that receives forwarded emails and connects them to proceedings
• [ ] Garbage collection, which deletes old proceedings, emails and other random data we don‘t want to keep
• [ ] A way to download the current app version reliably for analysis.

[baltpeter]

We have also discussed how to find a good balance between allowing anonymous access but also having convenience features for people who don't mind having an account.

• Proceedings themselves are not linked to a person, instead each one has a unique token that allows them to be managed.
• Users have the option of creating an account. Accounts essentially only hold a list of these tokens.
  • Of course, users can also delete (forget) proceedings from their account. If they do that, we keep the proceeding in the database but delete the token from their token store.
• If a users want to use the site anonymously without an account, they can just manage the token themselves (we'll probably give them a /<endpoint>?token=<token> link).

[baltpeter]

I've started a mockup of the user flow[^miro]: https://miro.com/app/board/uXjVKI3TeDU=/?share_link_id=865934522346

[^miro]: We're not particularly happy about using Miro, either. But we genuinely (unsuccessfully) spent quite a lot of time looking for a usable FOSS alternative and didn't want to waste even more time on that for a one-off mockup. Once the mockup is done(-ish), we'll do a PDF export.

This is very much WIP still and subject to change. So far, I have only started very broadly sketching out the user flow that we have described above. I haven't yet put any significant amount of thought into UX and the text is also very much not final yet. I would definitely appreciate help with all of that, @zner0L!

[baltpeter]

Here's the export of the mockup (in the various formats that it let me export after getting a trial of the premium account…):

• Tweasel Mockup.pdf
• Tweasel Mockup slides.pdf
• Tweasel Mockup
• Tweasel Mockup.rtb

[baltpeter]

These are the URLs I came up with for the steps of the mockup:

/a
/a/{platform}/{app_id}
/a/{platform}/{app_id}/{analysis_id}

/p/{platform}/{app_id}/confirm-platform
/p/{platform}/{app_id}/wrong-platform/{actual_platform}
/p/{token}
/p/{token}/send-notice
/p/{token}/evaluate-response
/p/{token}/complain