You may not be stealing the actual content, more so “making a copy”, but in doing that you’re taking away money the artist would have earned if you bought their album or streamed it on Spotify (admittedly that’a a very small amount for the artist but that’s another thing)
And if I stole something physical you had for sale, you wouldn’t make the money, so the end result is effectively the same.
The “if you bought their album” is the non-trivial part of that sentence. A pirate is not necessarily going to fork over $20 for an album if they couldn’t pirate. Chances are they will simply not buy the album. In either case the artist doesn’t get their $1.20 (6% to the artist the rest to the studio and distributors). So the result is really not the same because the artist and the pirate can both have the album in different ways and in both cases the artist doesn’t get their $1.20 unlike a physical good which cannot be cloned.
What this really is exposing is that most art is not worth the same. A Taylor Swift album is not worth the same on the open market as a Joe Exotic album. Pricing both at say $20 is artificial. Realistically most music has near zero actual value, hence why if you are a B tier or lower artist you won’t make much compared to an A tier artist on platforms like Spotify or YouTube which pay per listen/watch.
Very cool. Seeing how almost everything from WiFi, to NVME SSDs, (to apparently USB ports sometimes?) are connected to it, is PCIe the only high-speed interconnect we have for peripherals to communicate with modern CPUs?
The high speed signals that come out of mainstream CPU chips are generally DDR, SMP, and PCIe. Outside of a very few exotic things that use QPI or HT to connect, or exotic storage might use DDR, yes high speed off-chip peripherals use PCIe.
NVLink is another one you might have heard of, although it might also fall in the exotic category. I think some systems take AXI off-chip too. So there's various other weird and wonderful things. But none you're likely to have in your PC I think.
On-chip is another story, you can connect USB or NVMe or GPU "peripherals" using an on-chip interconnect type. But I guess you are asking about off-chip.
What is verification? What does it involve doing? A lot of information on why it's useful, but how is it implemented? I hope it's not something like the Play Integrity API, but with no information to go on, I can't say either way.
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
So is this like the Signal PIN which is required when installing on a new device? If you forget, the cryptography changes and old contacts are warned that signatures are rotated, right?
Quite. I have yet to manage a verification between clients.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
In this case, it's what you do when signing in from a new device (or browser) to attest that it's yours. It avoids warnings to you and your contacts that a device has gained access to your account without your approval.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
The experiences reported here seem to say otherwise...
As others, anyhow, I haven't tried again recently
> (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
I last tried Element about six months ago, but for years using the recovery key was either impossible or close to it, and mostly just for idiotic UI mistakes that were never corrected (something like you had to enter the key where they wanted the passphrase or the opposite).
To my recollection the version from six months ago worked better in that regard, but it was still asking to enter the passphrase where you actually had to enter the recovery key.
I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier.
Also, other clients exist.
For whatever it's worth, I've been using Matrix for about five years, including some of its roughest times. I seldom see errors these days, but I can understand how folks who were frustrated with earlier iterations would still be soured to it. Such is the nature of an ambitious work in progress, I suppose.
I use it because there is nothing else with the combination of features that are most important to me, and because (despite my gripes) I can see slow and steady improvement. I think it's moving in the right direction overall. I could picture introducing family members to it once Matrix 2.0 is released and the implementations shake out any early problems.
In short, the passphrase works with both and the recovery key with neither, specifically:
Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."
That's how it was the last time I used it, and if I'm not mistaken it's been for years.
Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.
Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.
The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.
> Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
I have just tried this on Android.
I am directed to
1) "Device verified - Now you can read or send messages securely, and ... - [Continue]"
2) "Help improve Element X ... [OK] [Not now]"
3) list of chats
Element X Android fyi. No problems logging in using Firefox.
Since you didn't share all the details of your tests, I'm having trouble picturing how I could try reproducing what you did. (That's okay; I'm not an Element maintainer.)
However, a couple of things occur to me:
- No Matrix client that I know of supports setting both a randomly generated recovery key and recovery passphrase on the same account. So in order to test both, you would have to use a separate account for each. If you tried to test both on the same account, it's expected that one of the two would be rejected.
- You didn't specify a platform, but since you wrote "Element classic", I guess you must mean Android or iOS. I used Element Desktop / Web to set up my accounts, which could explain why I saw different prompts.
I hope you reported the error message referring to a passphrase when a key had been entered. I imagine that could leave the user wondering whether they had made a typo or the app had misinterpreted what they typed, which would not inspire confidence in it.
That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.
Discord does not do any sort of end-to-end encryption. All messages are fully readable and writable by Discord. Discord decides whether you are who you say you are, and all clients trust whatever Discord says to be trustworthy.
> The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.
honestly it's the best thing ever they have done:
- I have heard of someone who failed to use Matrix, because he got frustrated of having not a secure enough passphrase
- people don't choose secure passphrases
- it provides options making things more complex (especially when guiding others)
- you know you won't memorize it, so you are more likely to put it down
1. Generating a random key by default (but still allowing advanced users to prefer a passphrase) would solve your "secure enough" problem.
2. Better yet, a "secure enough" passphrase could be generated by default, à la Correct Horse Battery Staple. A user wouldn't be forced to choose one.
3. When adding an option, interface complexity can be avoided by simply not showing it by default, or by placing it off to the side in collapsed state where it doesn't draw attention.
4. If you're worried about people writing down a passphrase, you should be even more worried about a string of 50 random characters.
That last one is important. Nobody is going to memorize a random key, which means everyone has to write it to a file (or painstakingly write it on paper) for long term storage. When verifying remote devices, they also have to get the key to the other devices, so they are likely to use copy/paste, which will put it on at least two devices' clipboards, where it will be available for harvesting by nosy apps/websites or accidental pasting to random ones. They also have to figure out a way to transport the key from one device's clipboard to another, which might be email or SMS or some other insecure channel that they're accustomed to using. Or in the unlikely event that they choose paper, they have to painstakingly transcribe it again at the other end.
In other words, forcing the use of a random key does not increase security vs. a well-implemented passphrase system, but instead pushes responsibility for security out of the software and into the hands of people who aren't trained in it. Inviting more big mistakes.
A passphrase would avoid most of those exposure risks by not having to be written down or copy/pasted or sent through insecure channels. And with the right UI, it wouldn't be more complex to use or less secure.
Fortunately, Matrix supports passphrase-derived keys at the protocol level, so client developers who understand how to implement them well for humans can still do so. I hope Element's product managers will come around eventually.
I was afraid of that as well given the wording but, no, it's nothing to do with third parties at all. Just when you log into a new device, you confirm it on your old device so it knows it can transfer encryption keys for old messages to the new device
This has been in Element/Matrix since forever and I found it the easiest verification mechanism of all the encrypted messengers I've tried. I'm not surprised they're making this part of the standard process, but the wording in 2025 is... unfortunate. Or perhaps that adjective should be applied to the rest of the world since it's not the Matrix Foundation which changed. For the reader to decide ^^
In the current state, it's basically just a self verification. When you use a new device it shows a series of emoji on each device and asks you if they're the same, then the device is verified.
Thankfully, no, it's not anything evil like Play Integrity is. The simple explanation is that the first time you log in to an existing account from a new device, you need to go on one of your old devices and confirm that the new one is yours.
I’m a server admin and I still couldn’t tell you why when I sign new endpoints in and verify for cross-signing it still also asks me for a recovery key.
For encrypted search on desktop it has to fetch batches of messages and this is configurable in settings. It just had a number? what is that? how large the batch is, how many ms? no clue! good thing we can’t do encrypted search on mobile/web.
Yeah, I was wondering this as well. At the very least, this appears to be an Element requirement that was just enabled by a Matrix protocol update, so moving would be possible, but afaik Element is extremely popular as far as Matrix goes.
Fairly unsatisfying conclusion. I’d be interested in knowing what that proprietary program does, how it works so well, how Sony stores video files, etc.
I think the key point is that cameras don't write the video files in one long contiguous block on disk. They internally split it up and write in an interleaved fashion. It even mentions low-level tricks like manipulating the FAT table so the moov atom which is written last appears at the beginning of the file.
I've found when you have a file with stops and starts, it's because the extraction process is not familiar with how the data is laid down on the storage media. So it sees 'I have a file'...and if it's better it sees 'the name of the file is here' and then 'it's this big' and then 'here's the linked list of clusters for that file'....or it starts at the first cluster and gets as far as it can before it runs off the tracks.
> Running iperf server on the router itself creates CPU contention between the WiFi scheduling and the iperf process. The router’s TCP stack isn’t tuned for this either. Classic mistake.
Can you elaborate on this? I don't know much about WiFi so I'm curious what CPU work the router needs to do and what wouldn't be offloaded to hardware somehow (like most routing/forwarding/QoS duties can be).
It has nothing to do with WiFi even; when running a test you need a server that emits the test data - this could be a standard HTTP server on the internet (in case of public speed tests) or a binary like iperf that synthesizes the test data on the fly.
You need to ensure the server is able to send the test data quickly enough so that the network link becomes the bottleneck.
In his case he was running the test server on the router, and the router’s CPU was unable to churn out the data quickly enough to actually saturate the network link (most network equipment does the network switching/routing/NAT in hardware and so doesn’t actually come equipped with a CPU that is capable of line-rate TCP because it’s not actually needed in normal operation).
reply