https://reclaimthenet.org/discord-expands-age-verification-id-system-to-more-regions

Discord’s push to verify users through government ids shows how safety mandates can quietly turn into systems of surveillance

Over the past years, repeated investigations have shown that at least 14 EU Member States have deployed spyware against journalists, human rights defenders, lawyers, activists, political opponents, and others.

Despite the findings of the European Parliament’s PEGA Inquiry Committee in 2023, and the push from human rights organisations, the European Commission has so far refused to propose binding legislation to prohibit spyware. Not only that: it has done nothing. Right now, no EU-wide red lines exist against the use of spyware. This means that victims lack effective remedies, authorities face no scrutiny, and commercial spyware vendors continue to operate with near-total impunity, enriching themselves by violating human rights, and even benefiting from European public funding.

Hello!

As a handsome local AI enjoyer™ you’ve probably noticed one of the big flaws with LLMs:

It lies. Confidently. ALL THE TIME.

(Technically, it “bullshits” - https://link.springer.com/article/10.1007/s10676-024-09775-5

I’m autistic and extremely allergic to vibes-based tooling, so … I built a thing. Maybe it’s useful to you too.

The thing: llama-conductor

llama-conductor is a router that sits between your frontend (OWUI / SillyTavern / LibreChat / etc) and your backend (llama.cpp + llama-swap, or any OpenAI-compatible endpoint). Local-first (because fuck big AI), but it should talk to anything OpenAI-compatible if you point it there (note: experimental so YMMV).

Not a model, not a UI, not magic voodoo.

A glass-box that makes the stack behave like a deterministic system, instead of a drunk telling a story about the fish that got away.

TL;DR: “In God we trust. All others must bring data.”

Three examples:

1) KB mechanics that don’t suck (1990s engineering: markdown, JSON, checksums)

You keep “knowledge” as dumb folders on disk. Drop docs (.txt, .md, .pdf) in them. Then:

• >>attach <kb> — attaches a KB folder
• >>summ new — generates SUMM_*.md files with SHA-256 provenance baked in
• `>> moves the original to a sub-folder

Now, when you ask something like:

“yo, what did the Commodore C64 retail for in 1982?”

…it answers from the attached KBs only. If the fact isn’t there, it tells you - explicitly - instead of winging it. Eg:

The provided facts state the Commodore 64 launched at $595 and was reduced to $250, but do not specify a 1982 retail price. The Amiga’s pricing and timeline are also not detailed in the given facts.

Missing information includes the exact 1982 retail price for Commodore’s product line and which specific model(s) were sold then. The answer assumes the C64 is the intended product but cannot confirm this from the facts.

Confidence: medium | Source: Mixed

No vibes. No “well probably…”. Just: here’s what’s in your docs, here’s what’s missing, don't GIGO yourself into stupid.

And when you’re happy with your summaries, you can:

• >>move to vault — promote those SUMMs into Qdrant for the heavy mode.

2) Mentats: proof-or-refusal mode (Vault-only)

Mentats is the “deep think” pipeline against your curated sources. It’s enforced isolation:

• no chat history
• no filesystem KBs
• no Vodka
• Vault-only grounding (Qdrant)

It runs triple-pass (thinker → critic → thinker). It’s slow on purpose. You can audit it. And if the Vault has nothing relevant? It refuses and tells you to go pound sand:

FINAL_ANSWER:
The provided facts do not contain information about the Acorn computer or its 1995 sale price.

Sources: Vault
FACTS_USED: NONE
[ZARDOZ HATH SPOKEN]

Also yes, it writes a mentats_debug.log, because of course it does. Go look at it any time you want.

The flow is basically: Attach KBs → SUMM → Move to Vault → Mentats. No mystery meat. No “trust me bro, embeddings.”

3) Vodka: deterministic memory on a potato budget

Local LLMs have two classic problems: goldfish memory + context bloat that murders your VRAM.

Vodka fixes both without extra model compute. (Yes, I used the power of JSON files to hack the planet instead of buying more VRAM from NVIDIA).

• !! stores facts verbatim (JSON on disk)
• ?? recalls them verbatim (TTL + touch limits so memory doesn’t become landfill)
• CTC (Cut The Crap) hard-caps context (last N messages + char cap) so you don’t get VRAM spikes after 400 messages

So instead of:

“Remember my server is 203.0.113.42” → “Got it!” → [100 msgs later] → “127.0.0.1 🥰”

you get:

!! my server is 203.0.113.42 ?? server ip → 203.0.113.42 (with TTL/touch metadata)

And because context stays bounded: stable KV cache, stable speed, your potato PC stops crying.

There’s more (a lot more) in the README, but I’ve already over-autism’ed this post.

TL;DR:

If you want your local LLM to shut up when it doesn’t know and show receipts when it does, come poke it:

• Primary (Codeberg): https://codeberg.org/BobbyLLM/llama-conductor
• Mirror (GitHub): https://github.com/BobbyLLM/llama-conductor

PS: Sorry about the AI slop image. I can't draw for shit.

PPS: A human with ASD wrote this using Notepad++. If it the formatting is weird, now you know why.

Developer @SuspciousCarrot78@lemmy.world ousc

Translated from German (with DeepL):

The Swiss messenger service Threema is being acquired by the German investment company Comitis Capital. Both the company and Threema itself emphasize that the arrival of the new investor will not lead to any significant changes for the time being. The company headquarters and servers will remain in Switzerland, and the management team will stay unchanged.

A financial investor with a broad portfolio

Comitis Capital is a young private equity firm, not a technology company. It invests in various industries, including a UK-based supplier of vegan meat alternatives and a manufacturer of dog accessories.

Its business model consists of providing financial support to promising companies so that they can grow and establish themselves internationally. “Comitis now clearly sees this potential in Threema too,” says SRF digital editor Tanja Eder.

Data protection as a business model

The strong focus on data protection is considered a key strength of the messenger. Precisely because US tech companies are coming under increasing criticism and digital sovereignty is gaining in importance, Comitis sees this aspect as a clear unique selling point.

Whether this will remain the case in the long term is unclear, according to Eder. If Comitis were to conclude at some point that it would be more profitable to collect Threema customer data or sell the company, no one could prevent them from doing so.

Trust in the authorities remains an issue

In Switzerland, federal authorities and the military also use Threema for internal communication. Even though everyone involved is aware that there is no such thing as absolute security, Threema still has advantages over its competitors.

For example, Threema's source code is openly accessible. Experts in the fields of data protection, IT security, and research regularly check whether the company is keeping its promises. Government agencies can also carry out their own checks.

Hardly any alternatives on the market

Good alternatives to Threema are rare. “Apart from WhatsApp, which dominates the market, there is simply not much room for other messenger services,” notes the digital editor.

Signal is considered another secure messenger alongside Threema. However, it is operated from the US, albeit by a non-profit foundation and financed by donations. In Switzerland, Proton offers encrypted emails, but does not have its own messenger service.

“Given this limited offering, we can only hope that privacy-friendly communication services will gain in importance in the future,” says Eder.

The UK government, MPs, organisations and public figures are discussing whether there should be stronger rules about children's access to social media - including an Australia-style ban for under-16s.

The latest update for the popular Nova Launcher app includes Facebook Ads and Google AdMob.

Compare 8.2.4: https://reports.exodus-privacy.eu.org/en/reports/698198/

With 8.1.6: https://reports.exodus-privacy.eu.org/en/reports/673643/

From 2 trackers to 6 trackers. From 30 permissions to 36. And two of the "trackers" are for ad stuff, like Facebook Ads.

I believe the owner also changed. It's no longer Branch, but something called Instabridge Sweden.

By @K0Z@lemdro.id

We have no marketing budget and are trying to get as many people away from Big Tech surveillance as possible. Please share this link with friends and family, and on social media.

It contains a full link index of all our Alternatives pages, as well as links to our Big Tech Walkout programme, and a Quick Start section for those who just want to grab the top choices.

Thank you!

Patrick (Rebel Tech Alliance)

https://immich.app/

https://www.removepaywall.com/search?url=https%3A%2F%2Fwww.theguardian.com%2Ftechnology%2F2026%2Fjan%2F16%2Ftiktok-to-strengthen-age-verification-technology-across-eu

Move comes as calls for Australia-style social media ban for under-16s grow around world, TikTok will begin to roll out new age-verification technology across the EU in the coming weeks, as calls grow for an Australia-style social media ban for under-16s in countries including the UK.

NOTE: This is still a work-in-progress and far from finished. It is free to use and not sold or monetized in any way. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app. I have open source examples of various part of the app and im sure more investigation needs to be done for all details of this project. USE RESPONSIBLY!

I usually post along the lines of "promoting my project". I'm aiming for this post to be more technical. I hope to make it clear how the project works and some features/capabilities I will be working on. Feel free to reach out for clarity.

Im aiming to create the "theoretically" most secure messaging app. This has to be entirely theoretical because its impossible to create the "most secure messaging app". Cyber-security is a constantly evolving field and no system can be completely secure.

If you'd humor me, i tried to create an exhaustive list of features and practices that could help make my messaging app as secure as possible. Id like to open it up to scrutiny.

Demo

(Im grouping into green, orange and red because i coudnt think of a more appropriate title for the grouping.)

Green

• P2P - so that it can be decentralized and not rely on a central server for exchanging messages. The project is using WebRTC to establish a p2p connection between browsers.
• End to end encryption - so that even if the messages are intercepted, they cannot be read. The project is using an application-level cascading cipher on top of the encryption provided by WebRTC. the key sub-protocols involves in the approach are Signal, MLS and AES. while there has been pushback on the cascading cipher, rest-assured that this is functioning on and application-level and the purpose of the cipher is that it guarantees that the "stronger" algoritm comes up on top. any failure will result in a cascading failure... ultimately redundent on top of the mandated WebRTC encryption. i would plan to add more protocols into this cascade to investigate post-quantum solutions.
• Perfect forward secrecy - so that if a key is compromised, past messages cannot be decrypted. WebRTC already provides a reasonable support for this in firefox. but the signal and mls protocol in the cascading cipher also contribute resiliance in this regard.
• Key management - so that users can manage their own keys and not rely on a central authority. there is key focus on having local-only encryption keys. sets of keys are generated for each new connection and resued in future sessions.
• Secure signaling - so that the initial connection between peers is established securely. there are many approaches to secure signaling and while a good approach could be exchanging connection data offline, i would also be further improving this by providing more options. its possible to establish a webrtc connection without a connection-broker like this.
• Minimal infrastructure - so that there are fewer points of failure and attack. in the Webrtc approach, messages can be sent without the need of a central server and would also work in an offline hotspot network.
• Support multimedia - so that users can share animations and videos. this is important to provide an experience to users that makes the project appraling. there is progress made on the ui component library to provide various features and functionality users expect in a messaging app.
• Minimize metadata - so no one knows who’s messaging who or when. i think the metadata is faily minimal, but ultimately is reletive to how feature-rich i want the application. things like notification that a "user is typing" can be disabled, but its a common offering in normal messaging apps. similarly i things read-reciepts can be a useful feature but comes with metadata overhead. i hope to discuss these feature more in the future and ultimately provide the ability to disable this.

Orange

• Open source - moving towards a hybrid approach where relevent repositories are open source.
• Remove registration - creating a messaging app that eliminates the need for users to register is a feature that i think is desired in the cybersec space. the webapp approach seems to offer the capabilities and is working. as i move towards trying to figure out monetization, im unable to see how registration can be avoided.
• Encrypted storage - browser based cryptography is fairly capable and its possible to have important data like encryption keys encrypted at rest. this is working well when using passkeys to derive a password. this approach is still not complete because there will be improvements to take advantage of the filesystem API in order to have better persistence. passkeys wont be able to address this easily because they get cleared when you clear the site-data (and you lose the password for decrypting the data).
• User education - the app is faily technical and i could use a lot more time to provide better information to users. the current website has a lot of technical details... but i think its a mess if you want to find information. this needs to be improved.
• Offline messaging - p2p messaging has its limitations, but i have an idea in mind for addressing this, by being able to spin up a selfhosted version that will remain online and proxy messages to users when they come online. this is still in the early stages of development and is yet to be demonstrated.
• Self-destructing messages - this is a common offering from secure messaging apps. it should be relatively simple to provide and will be added as a feature "soon".
• Javascript - there is a lot of rhetiric against using javascript for a project like this because of conerns about it being served over the internet. this is undestandable, but i think concerns can be mitigated. i can provide a selfhostable static-bundle to avoid fetching statics from the intetnet. there is additional investigation towards using service workers to cache the nessesary files for offline. i would like to make an explicit button to "fetch latests statics". the functionality is working, but more nees to be done before rolling out this functionality.
• Decentralized profile: users will want to be able to continue conversations across devices with multidevice-sync. It's possible to implement a p2p solution for this. This is an ongoing investigation.

Red

• Regular security audits - this could be important so that vulnerabilities can be identified and fixed promptly. security audits are very expensive and until there is any funding, this wont be possible. a spicier alternative here is an in-house security audit. i have made attempts to create such audits for the signal protocols and MLS. im sure i can dive into more details, but ultimately an in-house audit in invalidated by any bias i might impart.
• Anonymity - so that users can communicate without revealing their identity is a feature many privacy-advocates want. p2p messages has nuanced trandoffs. id like to further investigate onion style routing, so that the origins can be hidden, but i also notice that webrtc is generally discourage when using the TOR network. it could help if users user a VPN, but that strays further from what i can offer as part of my app. this is an ongoing investigation.

Demo

FAQs:

Why are there closed source parts? - This project comes in 2 flavours; open-source and close-source. To view the open source version see here. ive tried several grants applications and places that provide funding for open source project. im aware they exist… unfortunately they rejected this project for funding. Im sure many are inundated with project submissions that have a more professional quality and able to articulate details better than myself. Continuing with open source only seems to put me at a competative disadvantage.

Monetization - Im investigating introducing clerk. I hope to use that to create a subscription model. I would like to charge $1 per-month as per the minimum allowed by clerk. I started off thinking i could avoid charging users entirely given it seems a norm for secure messaging apps to be free. but given the grant rejects and the lack of donations on github sponsors (completely understandable), but its clear that it wont be able to sustain the project. I tried Google adsense on the website/blog but it was making practically nothing; so i disabled it because it wasnt a good look when it goes against the whole “degoogling” angle. This project is currently not funded or monnetized in any way. (Its not for lack of trying)

How does it compare against signal, simpleX, element, etc? - The project is far from finished and it woudnt make sense to create something as clear as a comparison table. Especially because core features like group-messaging isnt working. Some technical details can be seen here if your want to draw your own comparison.

• https://positive-intentions.com/docs/projects/chat
• https://positive-intentions.com/docs/category/sparcle

Javascript over the internet is not secure - im investigating the to use service workers to cache the file. this is working to some degree, but needs improvement before i fully roll it out… i would like to aim for something like a button on the UI called “Update” that would invalidate the service-worker cache to trigger an update. I hope to have something more elegant than selfhosting on localhost or using a dedicated app. its possible to provide a static bundle that can work from running index.html in a browser without the need to run a static server. The static bundle of the open source version can be seen and tested to work from this directory: https://github.com/positive-intentions/chat/tree/staging/Frontend . When i reach a reasonable level of stability on the app, i would like to investigate things like a dedicated app as is possible on the open source version. https://positive-intentions.com/blog/docker-ios-android-desktop

How is this different to any other messaging app? - the key distinction between this project and other like it like signal and simpleX is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration. its understandable that such a feature doesnt appeal to everyone, but along with the native build, it should cover all bases depending on your threat model.

What about Chat Control? - I see a lot a fear mongering in the cybersecurity community around chat-control. I aim to create something that doesn't have the censorship pitfalls of a traditional architecture. A previous post on the matter: https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my

Is it vibecoded? - AI is being used appropriately to help me in various aspects. I hope it doesnt undermine the time and effort i put into the project.

Aiming to provide industry grade security encapsulated into a standalone webapp. Feel free to reach out for clarity on any details or check out the following links:

• Docs: https://positive-intentions.com/
• Subreddit: https://www.reddit.com/r/positive_intentions
• Mastodon: https://infosec.exchange/@xoron

IMPORTANT NOTE: It's worth repeating, this is still a work in progress and not ready to replace any existing solution. many core features like group-messaging are not working. Provided for testing, demo and feedback purposes only.

Government invasion of a reporter’s home, and seizure of journalistic materials, is exactly the kind of abuse of power the First Amendment is designed to prevent. It represents the most extreme form of press intimidation. Yet, that’s what happened on Wednesday morning to Washington Post reporter...

TL;DR

ID scanning is becoming a more common requirement to access bars and clubs in Australia (and worldwide). A company called ScanTek is used in over 1,000 clubs in Aus and provides tools such as biometric-matching someone's face to an ID, detecting fake IDs, flagging people and sharing data with other venues automatically

As well as verifying ages, ScanTek boasts "collect marketing information from IDs and drivers licences, which business owners can use to target specific demographics with promotions" on its website in a pitch to business owners. Though they claim to not share any of this with third parties

Australia's privacy laws are vague, don't specify what can be collected and how it must be stored, and only say that companies shouldn't keep data for longer than is "reasonable"

While New York City, Los Angeles, and Chicago have all received significant attention when it comes to police use of surveillance technologies, the small city of New Orleans has for years been the laboratory for a sophisticated surveillance apparatus deployed by the city’s police department and other policing bodies.

Just last year, New Orleans was in the news as the city considered setting a new surveillance precedent in the United States. First, a privately run camera network, Project N.O.L.A., was exposed for deploying facial recognition technology, including “live use” (meaning Project N.O.L.A. was identifying people in real time as they walked through the city). All of this was done in close collaboration with the local police, despite these uses violating a 2022 ordinance that placed narrow limits on the use of facial recognition.

Then the city flirted with formally approving the use of live facial recognition technology, which would have been a first in the United States. If enacted, live facial recognition technology would allow police to identify individuals as they move about New Orleans in real time. All of this occurred in the months before the Trump administration deployed Border Patrol and Immigration and Customs Enforcement (ICE) agents, wielding an array of surveillance technologies, to terrorize and kidnap New Orleans residents. Of course, New Orleans residents have organized and actively fought back against the police and their spying, offering lessons for organizers across the country.

Edith Romero, an organizer with Eye on Surveillance (EOS), spoke with Truthout about the history of Eye on Surveillance, Project NOLA, the use of facial recognition technology in New Orleans and why we should all be watching what’s happening there if we’re concerned about the growing surveillance state.

First they came for adults site and social media; now they are already discussing about putting vpns and app stores behind age verification.

Cross posted from: https://sh.itjust.works/post/53553563

EFF is against age gating and age verification mandates, and we hope we’ll win in getting existing ones overturned and new ones prevented. But mandates are already in effect, and every day many people are asked to verify their age across the web, despite prominent cases of sensitive data getting leaked in the process.

A major expansion of the UK’s Online Safety Act (OSA) has taken effect, legally obliging digital platforms to deploy surveillance-style systems that scan, detect, and block user content before it can be seen.