Yeah, it’d be a live monitoring footprint limited to, say, wherever you have/bring a personal device plus maybe wherever there’s a wifi network it knows. But you’d be able to see where the tag was when it last pinged you, so you could return to that location to search for it and get a more accurate location fix.
The only case my example doesn’t cover is if a third party moves the tag away from your typical footprint and networks.
I don’t want an even higher level spyware device.
but I use […] AirTags regularly
Hmm…
Alfred is disappointed.
It might be time to move on from the mass-surveillance-on-every-single-device style of object location tracking.
Are there localising/tracking bluetooth tags available which only connect to your network/devices?
A few years ago I was using “Call Recorder” which seemed good at the time, but right now hasn’t had any work done on it since 2023.
It was on f-droid, but the author threw a tantrum at f-droid about donations.
One prominent example in Australia is via one of the two biggest nationwide supermarket chains, Coles: https://www.itnews.com.au/news/coles-to-run-palantir-analytics-suite-across-its-supermarkets-604698
Australians soon facing age checks when viewing adult websites [& search engines, social media, file
Huh, first I’ve seen that writeup. First in-depth well-reasoned set of criticisms I’ve read on the XMPP+OMEMO setup, which is my goto and usual recommendation (and what I still find most power-efficient on a degoogled phone, most usable and reliable despite its stagnation).
Gives a good overview of the accumulated technical debt/chaos beneath the surface. Really hope that conversations and omemo can sort out their mess, or that other clients like kaidan can rise up and push omemo forward, because xmpp itself has been a solid foundation.
https://tosdr.org/ for summaries.
Whittaker’s phrasing is ambiguous. Could be read as expressing one of a number of things:
- The paper/article is misleading and distracting from meaningful threats to privacy.
- That the original tweet is using misleading accusations to distract us from the article’s revelations of meaningful threats to privacy.
- That Appelbaum’s authorship of the research is an unwanted negative association which undermines the attention deserved by the threats documented in the paper which are misleadingly justified as necessary by eg. governments.
It’s difficult to know without a better understanding of Whittaker’s position on the various matters at hand, so I don’t know.
(I have never used their commercial offering).
Jitsi works really well, and the developers seem to have made an effort to have it work well on any platform, even mobile browsers and PSTN. I’ve always found it the lowest friction teleconferencing method for all types of users.
It’s self-hostable, integrates with SIP, and 8x8’s commercial offering mentions HIPAA, BAA and GDPR.
Migadu is a decent option if you don’t want to self-host.
The article does not explain the primary design purpose of a VPN – providing an encrypted tunnel into or between two private subnets.
For example, your home subnet is typically all 192.168.nnn.nnn addresses – a class of addresses which the wider internet does not route, and which your router/modem does not allow the wider internet to access unless explicitly permitted.
Say you have a NAS on your home network, and you want to access it from your laptop while at a cafe; you could set up a VPN between your laptop and your home router, and it can make your home network appear as your local network to your laptop, giving you access to your NAS.
Or between two office locations of a business – their database servers, accounting systems, printers, etc can all be freely accessible between offices without being exposed to the wider internet.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
- https://codeberg.org/UnifiedPush/specifications/pulls/1
- https://github.com/binwiederhier/ntfy-android/pull/98
- https://codeberg.org/iNPUTmice/Conversations/issues/428
I noticed that the examples given on https://codeberg.org/iNPUTmice/up/src/branch/master/README.md are unencrypted.
I mean ntfy’s primary purpose is not dependent on UnifiedPush – all UP functionality could be removed and ntfy would still work as intended.
Ntfy server knows how to be a UP gateway, and relays those messages to the ntfy app, which knows how to be a UP distributor.
As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.
You could have a look at the messages ntfy is passing around using its trace function: https://docs.ntfy.sh/troubleshooting/
a private DNS server that only has records from your local services would at least prevent apps from reaching out as long as they aren’t smart enough to fall back to an IP address if DNS fails.
Yes, this. It’s important that your local DNS server does not even forward queries from the isolated subnet to external DNS, because these queries (and responses) can contain information. (“DNS tunneling”).
I think a lot of comments have missed that ntfy.sh does not use UnifiedPush, the ntfy server is a UnifiedPush provider and the ntfy app is a UnifiedPush distributor.
Regarding encryption of the push message, from https://unifiedpush.org/developers/spec/android/ :
Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive).
That rules it out for me then. I like to use XMPP+OMEMO with about 4-5 clients which I can continue a conversation with at any time. Main mobile, tablet, desktop, other desktop, and backup mobile which is usually switched off. (Even if a device has been missing for too long and run out of OMEMO keys, the keys sync up again once I send a message with it.)
You have to trust the servers with your metadata, and that the servers have their inter-server communication locked down, but at least you can choose/operate servers.
Some clients are a bit flaky with their e2e encryption defaults or from a UI perspective it is easy to send an unencrypted message (in a new chat for example) before noticing that was how it was set.
There are a few XEPs the server needs which enable things like OMEMO, efficient mobile data/battery use, offline and multiple device deliverability, file transfers, etc. Audio/video calling has various requirements as I think xmpp only facilitates the setup of the call.
XMPP lacks good clients and suffers from fragmentation of protocol standards implementation
- For Android: Conversations is excellent, also on F-Droid if you don’t want to use the Google store.
- For iOS/MacOS: Siskin or iOS/MacOS: Monal.
- For Linux/Windows: Gajim or Linux: Dino.
“Protocol fragmentation” is not a valid complaint about XMPP – it’s like complaining that ActivityPub is fragmented; but that’s not a problem: you use the services (Mastodon, Lemmy, Kbin, etc) built with it which suit your needs, mostly interacting with that sector of the federation (eg, Lemmy+Kbin), but get a little interoperability with other sectors as a bonus (eg, Lemmy+Mastodon).
MP Bob Katter would disagree that crocodiles are non-political: https://youtu.be/_ih1EuMLspY
If that’s the main problem then that’s easy to solve! Simply use a free public xmpp server.
I mention the self- and paid-hosting options because businesses tend to like having a sevice agreement backed by a contract, and may have additional specialised requirements not provided by free services (xmpp or otherwise).
It’s a talking-head video presentation on a well-known video publishing website.
Given your browser couldn’t show anything useful from that webpage, @kugmo@sh.itjust.works offered a solution: just feed the URL into mpv, which happens to be excellent at playing audio/video from web pages if you also have yt-dlp installed.
Yes: https://prosody.im/doc/turn
Further notes on implementing calling with XMPP: https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9
…seems like things may have stagnated around group calling; for now probably need to consider something more video conferencing specific like jitsi or bigbluebutton.