This one is p2p: https://github.com/schlagmichdoch/PairDrop (or just try it in https://pairdrop.net/ )

But that also means that you need to keep the page open while the other device downloads.

Another p2p alternative is using webtorrent: https://instant.io/

Ah, I see. Sorry, the text was too long and I’m not dutch so it was hard to spot that for me too.

But I interpret that part differently. I think them saying that there’s an ambiguous section about risks does not necessarily mean that the ambiguity is in the responsibility of those who choose to not implement the detection… it could be the opposite: risks related to the detection mechanism, when a service has chosen to add it.

I think we would need to actually see the text of the proposal to see where is that vague expression used that she’s referring to.

It seems the reason companies are currently allowed to do this in the EU is because there was in 2020 a temporary derogation from certain provisions of the e-Privacy Directive.

But it was temporary, so it will expire in April 2026. With this new law the intention is to make that “voluntary detection” a permanent thing they allow service providers to do, as a norm. The providers still have the choice to not do it, so I don’t think this affects services like signal, as far as I understand.

Thanks for the link, and the clarification (I didn’t know about april 2026)… although it’s still confusing, to be honest. In your link they seem to allude to this just being a way to maintain a voluntary detection that is “already part of the current practice”…

If that were the case, then at which point “the new law forces [chat providers] to have systems in place to catch or have data for law inforcements”? will services like signal, simplex, etc. really be forced to monitor the contents of the chats?

I don’t find in the link discussion about situations in which providers will be forced to do chat detection. My understanding from reading that transcript is that there’s no forced requirement on the providers to do this, or am I misunderstanding?

Just for reference, below is the relevant section translated (emphasis mine).

In what form does voluntary detection by providers take place, she asks. The exception to the e-Privacy Directive makes it possible for services to detect online sexual images and grooming on their services. The choice to do this lies with the providers of services themselves. They need to inform users in a clear, explicit and understandable way about the fact that they are doing this. This can be done, for example, through the general terms and conditions that must be accepted by the user. This is the current practice. Many platforms are already doing this and investing in improving detection techniques. For voluntary detection, think of Apple Child Safety — which is built into every iPhone by default — Instagram Teen Accounts and the protection settings for minors built into Snapchat and other large platforms. We want services to take responsibility for ourselves. That is an important starting point. According to the current proposal, this possibility would be made permanent.

My impression from reading the dutch, is that they are opposing this because of the lack of “periodic review” power that the EU would have if they make this voluntary detection a permanent thing. So they aren’t worried about services like signal/simplex which wouldn’t do detection anyway, but about the services that might opt to actually do detection but might do so without proper care for privacy/security… or that will use detection for purposes that don’t warrant it. At least that’s what I understand from the below statement:

Nevertheless, the government sees an important risk in permanently making this voluntary detection. By permanently making the voluntary detection, the periodic review of the balance between the purpose of the detection and privacy and security considerations disappears. That is a concern for the cabinet. As a result, we as the Netherlands cannot fully support the proposal.

It seems the article is misinterpreting things. It’s not that it’s “voluntary for individual EU states”… but rather “voluntary” for service providers. The service providers don’t have to implement this chat detection if they don’t want to.

The thing is that if they don’t pass something like this, then by April 2026 a bunch of current services that are already doing CP detection would be breaking the law, since the temporary derogation of the e-Privacy Directive will expire. But I don’t think this affects services like signal/simplex who voluntarily choose to not try to detect it.

Where is this explained? the article might be wrong then, because it does state the opposite:

scanning is now “voluntary” for individual EU states to decide upon

It makes it sound like it’s each state/country the one deciding, and that the reason “companies can still be pressured to scan chats to avoid heavy fines or being blocked in the EU” was because of those countries forcing them.

Who’s the one deciding what is needed to reduce “the risks of the of the chat app”? if it’s each country the ones deciding this, then it’s each country who can opt to enforce chat scanning… so to me that means the former, not the latter.

In fact, isn’t the latter already a thing? …I believe companies can already scan chats voluntarily, as long as they include this in their terms, and many do. A clear example is AI chats.

The thing is… that even if there are countries publicly rejecting this, once the infrastructure is in place and a backdoor exists due to it being enforced by some other country, how can you be sure it’s not being used / exploited?

Even in the (hypothetical) case that the government is not using it (regardless of what they might say to the public), I wouldn’t trust that this backdoor would be so secure that nobody else than a government could make use of it.

I believe Germany is now in favor of this new proposal, according to https://fightchatcontrol.eu/

Only Italy, Netherlands, Czech Republic and Poland are against. This seems to be based on “leaked documents from the September 12 meeting of the EU Council’s Law Enforcement Working Party”.

I’m not sure if that’d be what it’d look like… distributions are hardly ever that heterogeneous.

I’d bet all the GrapheneOS users would get together in their own corner and nerd out about their customizations.

For the record: 1 in 25 is 4% …the image gives (intentionally?) the illusion of the proportion being higher.

3. The Pixel is easily unlockable, so one can install custom firmware without being a “pro”, its hardware is (or was reverse-engineered to be) compatible enough to make the experience seamless, with a whole firmware project / community that it’s exclusively dedicated on that specific range of hardware devices, making it a target for anyone looking for a phone where to install custom Android firmware on.

But I’d bet it’s a mix of 2 and 3.

Code being visible is not very useful if you can’t distribute it, extend it, expand it and improve it.

Many Keepass clients have support for not actually deleting entries, and instead moving them to a “Trash” subgroup inside the kdb that is ignored when searching entries. Also they usually keep track of the history of changes to each entry, to make it non-destructive.

Coupled with Syncthing typically automatically creating backups whenever it encounters conflicting changes, I feel this should be enough, at least for me personally.

Yep. I just confirmed it… restarting Firefox seems to make the ID in https://demo.supercookie.me/ change. Thought as long as you keep Firefox session open the id will be the same.

I’m not sure if the links you reference are the whole story though, because they are talking about partitioning the cache per top-level domain, which I would expect wouldn’t have been enough, since the demo is specific to its top-level domain and it’s not necessarily about cross-domain id.

Those are open questions that I don’t think we can answer yet.

If you are asking if Valve did make changes there, I’m expecting the answer is likely no. They haven’t shown anything regarding KDE/desktop mode on the Steam Frame. And we have yet to see how exactly this is integrated with gamescope. But if the device does become popular and interest grows for Linux VR development, then I expect we’ll see people trying to make new VR environments for Linux (or adapt existing ones for VR).

However, given that Valve plans to offer ways to play non-VR games with the Frame, I expect one could add a nested wayland session as if it were a non-Steam non-VR game, so in the VR environment from SteamOS one could have a floating screen showing a traditional KDE session relatively easy, I would expect. And in that sense one could have a desktop VR environment standalone, in the Frame.

Yes, I think you’re talking about something else, related to your particular needs. But the post OP opened (which you were replying to) was about discussing what “implications for Linux” would the new Steam hardware have.

I feel the only part in your comment that was somewhat relevant to the question raised by OP was:

Anyway IMHO the big questions for VR on Linux more broadly is what changes upstream on KDE in terms of immersive UX? Is KDE Plasma becoming a VR graphical shell? Does it have 3D widgets? Does it impact freedesktop in any way?

The only reason Linux became a thing is because Torvalds managed to get engagement and popularity amongst a niche community of hackers that happened to share the same needs/goals.

Because what gives it importance is the needs we share. “The need of 1” is measured in relation to “the need of many”. Community is a huge piece in the “open source” puzzle. A community of 1 is not a community… it’s a personal space. If you don’t share your software with a community then declaring it “open” is pointless.

Also… when I said “relevant” I specifically meant for the questions raised by OP. I’m not talking about “relevancy” in some weird transcendental way… I don’t believe such a thing exists… everything has a viewpoint from which something can be said to be “relevant”… however, as you yourself said: “your preferences are not relevant to my needs”.

Everyone can say the same thing… your needs are not relevant either then.

Popularity is ultimately what moves the needle, this post was asking in which direction will the needle move… so in this context your personal needs are only relevant in relation to how popular they are.

Relevant section:

At first, around 1996, it was common practice to make the Windows key act as Meta. However, because of the existing alternative keys for Meta in Emacs, the reintroduction of a hardware Meta key binding did not prove exceptionally useful. This made Super the next most frequently emulated key of choice, and thus it became the standard assignment for the Windows key under X11.

Most Linux software and documentation calls these keys “Super” keys. However, they are still referred to as KEY_LEFTMETA and KEY_RIGHTMETA in the kernel,[5] and some documentation such as that of KDE Plasma refers to it as just the Meta key.[6][7] “Windows” and ⌘[8] are also used in documentation.

It’s unclear what you are trying to say. The question was what would switching license do. There’s 2 scenarios: 1) either Google is really not doing changes in ffmpeg source internally right now …or 2) they are in fact making changes to it internally (perhaps for encoding with their own codecs, etc.) which they are not releasing back to the public (since the code is LGPL, and not AGPL)

With situation 1, they can simply continue using ffmpeg, even if it were to switch to AGPL. They would have no need/obligation to release anything, whether they decide to fund development or not. The way I see it, only if it’s situation 2, will Google be affected by a license change. However, if the use they make of ffmpeg is just to have their own encoder program for use with specific codecs, they might as well decide to stop using ffmpeg for this purpose instead and have their own program to work with their encoders. Most of the encoding work is already being done in the encoding libraries separately released (like libaom, which Google licensed under BSD-2).

But even in the rare case of Google having made changes that (after license change) they would suddenly decide to be willing to share with the community despite having not done so before… the whole problem with this bug-reporting mess is that most of the issues reported by the automated tools aren’t something really that impactful/important, they are things that even Google would not really be that interested to fix… (why would Google need to fix a codec that only affects a videogame cinematic from 1995?). These reports are just the result of automated & indiscriminated AI analysis, slop.

AGPL is more “copyleft”, but not really more “permissive”, in the sense that AGPL adds the extra requirement of forcing server admins to provide the sourcecode to the users of any service that internally makes use of AGPL code.

It plugs a loophole of the other GPL licenses that allows companies to not share any custom modifications as long as they don’t directly share the binaries (they can offer a service using internally modified binaries, but as long as they don’t distribute the binaries themselves they don’t have to share the source code from those modifications running on their private servers, even if they are GPL).

However, I don’t think a license change would really solve this particular bug-reporting trouble. Most likely Google has not patched these vulnerabilities internally either, or at least the biggest chunk of them (since most of them are apparently edge cases that would most likely not apply to Google’s services anyway).