| 24 Apr 2024 |
 foretold | I would like something that doesnt require an account ideally, and its also a learning opportunity for me. | 16:24:34 |
 spaetz | In reply to @foretold:matrix.org
Honestly, never heard of livekit https://docs.livekit.io/realtime/ | 17:21:34 |
| spaetz | it might not be targetting the p2p case too much though, not sure | 17:22:46 |
| spaetz | I just know that the element-call stack uses it. | 17:23:00 |
| spaetz | * I just know that the element-call stack uses it for video calls. | 17:23:07 |
| spaetz | * I just know that the element-call stack uses it for video calls. (but OT in here, so I'll stop) | 17:23:25 |
| 25 Apr 2024 |
|  @theimpulson:matrix.org left the room. | 03:21:25 |
|  michael_seven joined the room. | 16:50:04 |
| michael_seven | Notifications are sent to the provider using HTTP, so does that mean the network (ISP or VPN, mine or the server's) can read them? | 17:01:32 |
 walter.dietrich | i guess it depends on the chosen push server... but most of them use https. and secondly - what the user can't really decide - it depends on how the app/service works. for example Element uses an ID or something to just wake up the app and receive & decrypt the actual E2EE message. | 17:32:59 |
| walter.dietrich | please correct me if i got something completely wrong (not so sure about the first part). | 17:33:36 |
| walter.dietrich | * i guess it depends on the chosen push server... but most of them use https. and secondly - what the user can't really decide - it also depends on how the app/service works. for example Element uses an ID or something to just wake up the app and receive & decrypt the actual E2EE message. | 17:34:29 |
| michael_seven | 
Download diagram.png | 17:37:11 |
| michael_seven | So what's this HTTP POST thing? | 17:37:34 |
 Jonas Leder | The HTTP Post comes from the Server of your Application (e.g. Telegram) to your UnifiedPush Server (e.g. Ntfy.sh) | 17:45:45 |
| michael_seven | I see that, I'm wondering if it can be read by the ISP | 17:46:37 |
| walter.dietrich | that's the communication from the app server to the push server you have chosen... let it be ntfy, NextPush or even still Google Firebase. - but if you use a FOSS option you can (bit don't have to) run your own server.
this communication uses usually transport encryption via TLS. | 17:47:37 |
| Jonas Leder | The ISP can theoreticall see that there's a HTTP request, but as the communication uses HTTPs it's fully encryptes | 17:48:07 |
| walter.dietrich | * that's the communication from the app server to the push server you have chosen... let it be ntfy, NextPush or even still Google Firebase. - but if you use a FOSS option you can (but don't have to) run your own server.
this communication uses usually transport encryption via TLS. | 17:48:09 |
| michael_seven | Great, thanks | 17:49:06 |
 MayeulC | A few notes:
- Your ISP can only intercept the brown vertical arrow in the middle (push provider -> distributor)
- Usually this is encrypted (depends on the distributor)
- Other ISPs (the one used by the server of your provider, and the application server, as well as transit ISP) can only see the HTTP post on the top of this diagram
- Usually this is encrypted
- Most applications do not send sensitive data via push, it's mostly a "ping", and when there is data, it's generally encrypted (depends on the app)
- Usually, what your ISP can see and collect is metadata: when your phone receives a notification, and what distributor contacted it. Not its content. If it has more data, it can theoritically correlate this (with the data size and the timings) with what's being sent from the application server, and to other phones. This requires extensive surveillance, and could be used to infer your social groups and apps that you use. This attack is not specific to UnifiedPush though, and could be used against Google Firebase+Whatsapp, for instance (but would be harder to pull of due to the noise of so many other users).
The last point is pretty theoretical, but I think I read something about the NSA asking similar metadata from Google?
| 17:57:04 |
| walter.dietrich | * i guess it depends on the chosen push server... but most of them use https. and secondly - what the user can't really decide - it also depends on how the app/service works. for example Matrix uses an ID or something to just wake up the app and receive & decrypt the actual E2EE message. | 18:06:47 |
|  xeld joined the room. | 18:40:05 |
| xeld set a profile picture. | 18:50:20 |
| xeld changed their profile picture. | 18:54:15 |
| xeld changed their profile picture. | 19:00:10 |
| xeld changed their profile picture. | 19:02:41 |
| xeld changed their display name from xeld to xld. | 19:04:04 |
| xeld changed their display name from xld to xeld. | 19:04:36 |
|  comodo joined the room. | 22:23:52 |
