We tested one of those at 26C3 using a simple VPN to the UK, so we had a Vodafone UK network in Germany (and successfully placed a call). This is Not Supposed To Work (and at this point we hadn't made any changes to the software yet). It seems beyond nonexistent physical security, the location determination features and other measures in place to prevent use in the wrong place/country aren't working very well or at all.
So when Joe Haxor manages to use a cheap DNS exploit to point www.mybank.com to his web server and then hands out a self-signed certificate 'proving' it's www.mybank.com, you really think that not having a padlock icon on the window will stop Joe Average from handing over their passwords and thereby all their money?
Joe Haxor will use a cheap DNS exploit to point www.mybank.com to his web server, which will not support, enable, or redirect to HTTPS. Or do you really believe that Joe Average actually types https://www.mybank.com? You're lucky if they even get the www. part in.
Sorry, self-signed certs are better than than unencrypted HTTP, and unconditional roadblocks to their use are ridiculous when anyone can impersonate anyone over simple unencrypted HTTP. Anyone can argue that they should not be given equivalent security status to CA certificates (and I agree), but actively hindering their use is stupid and actively hurts security by discouraging Joe Web Developer from trivially enabling SSL to at least stop passive snooping.
So don't give users the lock icon, and just pretend it's an unencrypted website.
Self-signed certificates provide no protection against MITM attacks, but they do provide protection against passive snooping which is what the parent is talking about. There is zero disadvantage to using them. You can argue the lack of some advantages all you want, but throwing tons of warnings at users for using them is ridiculous, when regular unencrypted HTTP traffic is let through fine. I am particularly annoyed at the obnoxious warnings in recent browsers, Firefox included.
I will never understand current SSL warning policy - it's completely retarded. It would be a lot saner to shove the ridiculous warnings into user's faces only when a website previously using CA security downgrades to self-signed or plain HTTP. If you're going to warn for self-signed certs, then you ought to be warning for every single plain HTTP website.
I've been working on hacking the Vodafone femtocells for fun. They have an internal serial port and the bootloader has no security, not to mention the Linux image uses short default passwords that are easy to crack given the shadow file. So far we don't know of a way to get root given only network control, but it might be possible depending on how their IPSEC tunnel is set up. Our goal would be to use these for our own network, via OpenBSC.
It's worth noting that it's early and we're not entirely sure about the security implications and just how much you can do with these things (e.g. I don't know yet if voice traffic is decrypted inside the femtocell or if it is passed on encrypted to the servers). Chances are there will be some interesting exploits and chances are they will be presented at this year's Chaos Community Congress if they're interesting enough. Unless we get bored and work on something else, which happens sometimes.
The emulator used is PearPC. I'm not sure if it does JIT/Dynamic Recompilation, but I seriously doubt it has an ARM backend, so chances are it's running in full software emulation mode, which is going to be ridiculously slow.
You cannot get the root key. It's in hardware, it's used by hardware, software can't see it or touch it. Besides that, SPE code is encrypted, which means the hypervisor is never going to see the code. Sure, the hypervisor can talk to the isolated SPE, and if you found a hole in the SPE code you could exploit it and do fun stuff, but without access to the SPE binary finding and crafting and exploit is going to be nigh impossible.
The memory is by definition not secure (it's not encrypted nor signed). Therefore reading out all the memory isn't a hack, it's just a cute trick. Sure, the PS3 isn't designed to let you do that, but it's also designed such that doing it doesn't gain you much.
This exploit isn't going to get you keys. The keys are stored in an entirely different core with secure local storage. The word "hypervisor" is overhyped (pun intended); it isn't the primary target in order to own the system. That's why it was so easy to hack (this hack is fairly trivial). Geohot just did a knee-jerk trick and only later realized it wasn't nearly as useful as he imagined.
As someone who has been reverse engineering quite a bit of software recently, I can tell you that the assembly code from the attack and the Chinese version of the algorithm match completely. In other words, the output looks like exactly what an (optimizing) compiler would've produced given that source code. Note the operations performed inside the loop and the use of stack allocation for the table (and therefore the required initialization every time the function is called).
As far as I can see, none of the English versions are similar. Sure, they implement the same algorithm, but the chinese implementation matches the attack code, not just the algorithm,
I wasn't talking about licenses, I was talking about the principles of Free Software and Open Source Software, which necessitate no discrimination against any people whatsoever.
But you quoted an item in the open source definition, which applies to licenses, and which doesn't apply here.
The actions don't violate the letter of open source, that's certain. Whether they violate the spirit is a more debatable question. They certainly violate my personal principles, but that's just personal opinion; I'm not sure it's fair to extend this to the entire open source community.
The "export restriction" law cannot/shouldn't be applied to products of collective global work and efforts.
Again, I'm pretty sure the rational here is the hosting service is being exported, not the products themselves (which no one is arguing are "American").
Wikipedia? Slashdot? Google? Why not, they also provide service to people in those countries. And services are products.
Yes, those might fall for the same reasons. Retarded? You bet. Don't get me wrong, I don't agree with the US government at all, but you should direct your anger at them, not at SF.
No, because they aren't providing binaries either. The GPL requires that they provide source if they provide binaries. No binaries, no source requirement.
The freedoms of Free Software apply to licenses, not people or entities. This isn't a violation of any open source license as far as I'm aware. Roughly speaking, licenses will require either nothing in this regard (BSD doesn't force you to give away the code or binaries to anyone at all), or distribution of source code to people who receive binaries (GPL and the like). SourceForge isn't doing this, they're just refusing to distribute anything at all to these countries. This also has nothing to do with the software itself, just the act of hosting it. It's about the service, not the good. No one is preventing you from accessing your own work, just from accessing it through SourceForge's service (servers). Just have someone in a neutral country get it for you; this is perfectly legit and I bet even encouraged by SF.
The licenses themselves cannot include these kinds of limitations (if a licence says you can't run the program if you're North Korean, then it isn't an open source license, and this is what Freedom 5 is all about), but they do not require that users have this kind of openness. In fact, it is unnecessary: since the license lets you redistribute the program, all it takes is a third party to proxy between a restrictive distributor and the destination that he wants to avoid.
You can disagree with SF's take on the subject, but they aren't violating any licenses. If they did export to restricted countries, they would be violating local law. Given the availability of proxies and the like, it would be a questionably useful move. So the US government wants to annoy you; work around it and complain about the US government all you want (and rightly so), but don't blame the people who are just following the law.
The space station is at most 460km above the Earth. Not counting bouncing around support satellites, the lag is only going to be a millisecond or two. People have this misconception that the ISS is far from the Earth, while in reality it's not that high up.
Even if they have to bounce through a satellite in GEO (which is some 100 times farther away than the ISS and the farthest you're going to get for comms), that's, say, 300ms Earth-GEO-ISS, so the total ping time would be 600ms. No good for Counter-Strike, but still quite tolerable.
I know that. Which is why we need to fight software patents, to end all this nonsense.
If you're running Linux, chances are you're running software that violates hundreds of software patents. I'm not referring to some FUD claim by $company, this is just common sense. There are zillins of ridiculous software patents out there and pretty much all software infringes on a bunch of them.
Open source h.264 is just going to increase that patent violation tally by a few, and Theora itself very likely violates other patents out there. We're screwed either way, software patents just need to die.
I doubt YouTube is going to go ahead and reencode everything to Theora. Firefox needs to get its act together and at least take advantage of OS-supplied h.264 when it's available. Everyone likes to whine about patents for h.264, but there are free/oss decoders available and the best h.264 encoder is probably the open source x264. Considering that Theora isn't guaranteed not to contain patented technology anyway (it's just not known to), I'd say h.264 is a pretty good option with better support.
Consider that Vorbis never really broke into the mainstream, and it's actually superior to MP3. Theora doesn't really stand a chance as it is, and I have my doubts that it'll ever get to h.264's performance.
I hate microsofts business practices as much as the next guy on slashdot, but Bing is something they're actually done really good.
I disagree. So far, I've found no compelling issue to switch to Bing. I see it return noticeably lower quality search results (at least for international users). I did some tests with a certain class of internet scams that try to sell you freely available software and found that international Bing users were exceedingly likely to never notice, as they'd get scam result after scam result, while Google users would receive various "XX is a scam" results as the first few, so it looks like Bing is particularly vulnerable to the usual cross-linking tactics used for affiliate marketing scams. Their indexing bots are intentionally ill-behaved. I've blocked their entire IP space because they've made a habit out of randomly ignoring robots.txt and spoofing their user agent to various versions of IE.
Once Bing starts returning decent quality results and does so without violating accepted behavior guidelines for bots I'll give it a shot again. Until then, I'm not touching it.
Oh, wait, you mean they don't have a clock at all, I guess?
Most DACs don't have their own clock. They depend on a signal processor before them to provide the proper clock rate. If there is no such signal processor and the signal comes straight from a demodulated S/PDIF clock, then you get some jitter.
Clock syncing is actually a non-trivial problem, because clock rates tend not to be exact (and S/PDIF has no sample clocking - it just feeds data at whatever rate the sender chooses). A self-clocked DAC would end up drifting out of alignment with the source and have to either skip or duplicate some samples every now and then, which probably won't sound very good without some filtering. So a dumb DAC will always use whatever clock it gets from the input. Syncing is of course performed whenever you have a DSP, both because you have to do it and because a DSP has the hardware and software capable of doing it. And just about every S/PDIF receiver uses a DSP.
Oh, it does? And they're just morons. Right, I forgot.
Correct.
Actually, the real question is what the hell this has to do with microscopic differences in cable length anyway. Cable lengths don't alter the clock. Are we assuming multiple signals on different twisted pairs?
On S/PDIF clock and data are merged, so cable quality (which is tied to cable length) affects the recovered clock. Since the clock is tied to data, phase errors due to the cable do not result in a consistent phase error after clock recovery. As you degrade an S/PDIF connection, the recovered clock quality suffers until the point where you get data bit errors. Again, this is irrelevant for just about all S/PDIF receivers (which use a DSP); I'm just trying to explain where the original claimed issue comes from.
ren't all devices that have RJ-45 (As opposed to the lower-end coax) already the highend stuff? Is there really any device at all that accepts an RJ-45 cable but can't clean up the clock?
I don't know what the RJ-45 interface is about so I wouldn't know what to tell you here. It's been claimed it's I2S but I somehow doubt that. Anyway, the kind of "high-end" stuff made by "high-end" companies that also make "high-end" cables probably has lower chances of getting these kinds of issues right. It's what you get when companies are more interested in catering to bullshit audiophile claims than actual good design.
hint: you can't fully undo jitter at the reclocking phase. you can attenuate some but if the source adds jitter then you can't magically take it all 'back' via reclocking.
Yeah, you can. See, this is where you audiophiles fail: you take some word that refers to a real concept and mangle it into fairy tales that have nothing to do with reality.
Jitter is real, it affects craptacular dumb DACs driven by a clock recovered from a self-clocking signal, and it's eliminated completely by any form of clocked digital processing or buffering on the signal after clock recovery. Or in other words, yes, it exists, no, it doesn't affect 99% of AV receivers out there.
You can have poor quality digital audio, in one very specific case that audiophiles love to extend to the rest of the world: (very) jittery clocks caused by self-clocking modulation with no buffering or cleanup at the receiver side. This is what they call jitter. It's a true effect and it does affect signal quality at the output (how audible it is is subject to debate). The issue is that digital signal data is digital, but digital signal clocks are analog: the timing is determined by "analog" clock edges (time isn't quantized). This is fine for periodic simple clocks, since any distortion will be uniform and the result will still be a stable clock. However, once you merge clock and data into one stream (like S/PDIF), the recovered clock has artifacts that depend on the data and the kind of degradation that the signal suffered after traveling through the wire. The actual clock is still a clock, it's just that its edges are no longer uniformly spaced. If you feed this to a dumb DAC that clocks from its input, you get audio samples that aren't exactly uniform, and this is a measurable effect that could conceivably affect audio quality. Specific DAC types (sigma-delta etc) may or may not further aggravate this.
Thing is this only affects the specific circumstance of self-clocking protocols and dumb DACs with no digital processing, clock regeneration, or buffering. Add any of those and the issue goes away entirely, and we're back in the purely digital world where things either work perfectly or suck completely.
The problem is there are no error correction or CRC mechanisms in I2S digital audio and S/PDIF digital audio, which are by far the most common. S/PDIF does parity and the receiver can mask (not correct) errors if it's smart enough, but don't count on it.
Things like retransmissions are taken for granted in communications protocols, and things like CRCs are taken for granted in storage media, but digital audio streaming interfaces are really quite simple in comparison.
You clearly haven't tried it, at least not with calm music. Here, try this. That's a single-sample, single-channel glitch at around second 16, created by changing a single byte in a WAV file with a hex editor (and then encoding to Vorbis for bandwidth reasons - this does not affect the effect of the glitch significantly). It's quite obvious.
You're confusing jitter with clock skew. Clock skew means nothing as long as the input signal is still within the setup/hold times of the receiver. It either works or doesn't. This isn't to say that you don't need good matching, just that better matching will not improve quality.
Jitter is different. Jitter is uneven clocking. On the other hand, jitter is almost nonexistent on separate clock/data connections because any delays in the clock are consistent.
Jitter does matter in things like S/PDIF that combine clock and data, because then the data will affect the distortion on the clock and it will be jittery when recovered. This is what all the talk about jitter is: S/PDIF (and similar) clock recovery. Don't mix it up with other issues and other interfaces.
S/PDIF does have improved quality if the signal is less distorted, because it improves jitter. This problem can be completely eliminated by using a buffer before the DAC, or at least a PLL to clean up the clock (it only affects DACs that clock straight off of the recovered S/PDIF clock). Other interfaces (I2S) with separate clock and data do not have this problem because any distortion on the clock is consistent cycle to cycle.
You may be interested to learn that most digital audio interconnects these days still don't use error correction. Some use parity to detect errors, and may use error concealment techniques to hide errors (interpolation), but they don't use true digital error correction that results in an identical output. This means that you still need a reasonably decent connection, crappy connections which cause errors every few seconds do result in apparent noise (especially with systems that don't use parity and error concealment). These errors aren't really common though, because building a reasonable quality digital cable is by no means rocket science (or expensive), but this has nothing to do with error correction.
Digital audio storage (CD, Flash memory, etc) does use error correction.
Slashdot Mirror
We tested one of those at 26C3 using a simple VPN to the UK, so we had a Vodafone UK network in Germany (and successfully placed a call). This is Not Supposed To Work (and at this point we hadn't made any changes to the software yet). It seems beyond nonexistent physical security, the location determination features and other measures in place to prevent use in the wrong place/country aren't working very well or at all.
Joe Haxor will use a cheap DNS exploit to point www.mybank.com to his web server, which will not support, enable, or redirect to HTTPS. Or do you really believe that Joe Average actually types https://www.mybank.com? You're lucky if they even get the www. part in.
Sorry, self-signed certs are better than than unencrypted HTTP, and unconditional roadblocks to their use are ridiculous when anyone can impersonate anyone over simple unencrypted HTTP. Anyone can argue that they should not be given equivalent security status to CA certificates (and I agree), but actively hindering their use is stupid and actively hurts security by discouraging Joe Web Developer from trivially enabling SSL to at least stop passive snooping.
So don't give users the lock icon, and just pretend it's an unencrypted website.
Self-signed certificates provide no protection against MITM attacks, but they do provide protection against passive snooping which is what the parent is talking about. There is zero disadvantage to using them. You can argue the lack of some advantages all you want, but throwing tons of warnings at users for using them is ridiculous, when regular unencrypted HTTP traffic is let through fine. I am particularly annoyed at the obnoxious warnings in recent browsers, Firefox included.
I will never understand current SSL warning policy - it's completely retarded. It would be a lot saner to shove the ridiculous warnings into user's faces only when a website previously using CA security downgrades to self-signed or plain HTTP. If you're going to warn for self-signed certs, then you ought to be warning for every single plain HTTP website.
I've been working on hacking the Vodafone femtocells for fun. They have an internal serial port and the bootloader has no security, not to mention the Linux image uses short default passwords that are easy to crack given the shadow file. So far we don't know of a way to get root given only network control, but it might be possible depending on how their IPSEC tunnel is set up. Our goal would be to use these for our own network, via OpenBSC.
It's worth noting that it's early and we're not entirely sure about the security implications and just how much you can do with these things (e.g. I don't know yet if voice traffic is decrypted inside the femtocell or if it is passed on encrypted to the servers). Chances are there will be some interesting exploits and chances are they will be presented at this year's Chaos Community Congress if they're interesting enough. Unless we get bored and work on something else, which happens sometimes.
The emulator used is PearPC. I'm not sure if it does JIT/Dynamic Recompilation, but I seriously doubt it has an ARM backend, so chances are it's running in full software emulation mode, which is going to be ridiculously slow.
You also need access to fun and deadly chemicals (HF) to strip the top layers, and a lot of time on that microscope. But sure, that might work.
You cannot get the root key. It's in hardware, it's used by hardware, software can't see it or touch it. Besides that, SPE code is encrypted, which means the hypervisor is never going to see the code. Sure, the hypervisor can talk to the isolated SPE, and if you found a hole in the SPE code you could exploit it and do fun stuff, but without access to the SPE binary finding and crafting and exploit is going to be nigh impossible.
The memory is by definition not secure (it's not encrypted nor signed). Therefore reading out all the memory isn't a hack, it's just a cute trick. Sure, the PS3 isn't designed to let you do that, but it's also designed such that doing it doesn't gain you much.
This exploit isn't going to get you keys. The keys are stored in an entirely different core with secure local storage. The word "hypervisor" is overhyped (pun intended); it isn't the primary target in order to own the system. That's why it was so easy to hack (this hack is fairly trivial). Geohot just did a knee-jerk trick and only later realized it wasn't nearly as useful as he imagined.
As someone who has been reverse engineering quite a bit of software recently, I can tell you that the assembly code from the attack and the Chinese version of the algorithm match completely. In other words, the output looks like exactly what an (optimizing) compiler would've produced given that source code. Note the operations performed inside the loop and the use of stack allocation for the table (and therefore the required initialization every time the function is called).
As far as I can see, none of the English versions are similar. Sure, they implement the same algorithm, but the chinese implementation matches the attack code, not just the algorithm,
But you quoted an item in the open source definition, which applies to licenses, and which doesn't apply here.
The actions don't violate the letter of open source, that's certain. Whether they violate the spirit is a more debatable question. They certainly violate my personal principles, but that's just personal opinion; I'm not sure it's fair to extend this to the entire open source community.
Again, I'm pretty sure the rational here is the hosting service is being exported, not the products themselves (which no one is arguing are "American").
Yes, those might fall for the same reasons. Retarded? You bet. Don't get me wrong, I don't agree with the US government at all, but you should direct your anger at them, not at SF.
No, because they aren't providing binaries either. The GPL requires that they provide source if they provide binaries. No binaries, no source requirement.
The freedoms of Free Software apply to licenses, not people or entities. This isn't a violation of any open source license as far as I'm aware. Roughly speaking, licenses will require either nothing in this regard (BSD doesn't force you to give away the code or binaries to anyone at all), or distribution of source code to people who receive binaries (GPL and the like). SourceForge isn't doing this, they're just refusing to distribute anything at all to these countries. This also has nothing to do with the software itself, just the act of hosting it. It's about the service, not the good. No one is preventing you from accessing your own work, just from accessing it through SourceForge's service (servers). Just have someone in a neutral country get it for you; this is perfectly legit and I bet even encouraged by SF.
The licenses themselves cannot include these kinds of limitations (if a licence says you can't run the program if you're North Korean, then it isn't an open source license, and this is what Freedom 5 is all about), but they do not require that users have this kind of openness. In fact, it is unnecessary: since the license lets you redistribute the program, all it takes is a third party to proxy between a restrictive distributor and the destination that he wants to avoid.
You can disagree with SF's take on the subject, but they aren't violating any licenses. If they did export to restricted countries, they would be violating local law. Given the availability of proxies and the like, it would be a questionably useful move. So the US government wants to annoy you; work around it and complain about the US government all you want (and rightly so), but don't blame the people who are just following the law.
The space station is at most 460km above the Earth. Not counting bouncing around support satellites, the lag is only going to be a millisecond or two. People have this misconception that the ISS is far from the Earth, while in reality it's not that high up.
Even if they have to bounce through a satellite in GEO (which is some 100 times farther away than the ISS and the farthest you're going to get for comms), that's, say, 300ms Earth-GEO-ISS, so the total ping time would be 600ms. No good for Counter-Strike, but still quite tolerable.
I know that. Which is why we need to fight software patents, to end all this nonsense.
If you're running Linux, chances are you're running software that violates hundreds of software patents. I'm not referring to some FUD claim by $company, this is just common sense. There are zillins of ridiculous software patents out there and pretty much all software infringes on a bunch of them.
Open source h.264 is just going to increase that patent violation tally by a few, and Theora itself very likely violates other patents out there. We're screwed either way, software patents just need to die.
I doubt YouTube is going to go ahead and reencode everything to Theora. Firefox needs to get its act together and at least take advantage of OS-supplied h.264 when it's available. Everyone likes to whine about patents for h.264, but there are free/oss decoders available and the best h.264 encoder is probably the open source x264. Considering that Theora isn't guaranteed not to contain patented technology anyway (it's just not known to), I'd say h.264 is a pretty good option with better support.
Consider that Vorbis never really broke into the mainstream, and it's actually superior to MP3. Theora doesn't really stand a chance as it is, and I have my doubts that it'll ever get to h.264's performance.
I disagree. So far, I've found no compelling issue to switch to Bing. I see it return noticeably lower quality search results (at least for international users). I did some tests with a certain class of internet scams that try to sell you freely available software and found that international Bing users were exceedingly likely to never notice, as they'd get scam result after scam result, while Google users would receive various "XX is a scam" results as the first few, so it looks like Bing is particularly vulnerable to the usual cross-linking tactics used for affiliate marketing scams. Their indexing bots are intentionally ill-behaved. I've blocked their entire IP space because they've made a habit out of randomly ignoring robots.txt and spoofing their user agent to various versions of IE.
Once Bing starts returning decent quality results and does so without violating accepted behavior guidelines for bots I'll give it a shot again. Until then, I'm not touching it.
There's no Flash 10.1 for 64-bit Linux. And the current 64-bit versions of 10.0 still suck in every possible way.
Most DACs don't have their own clock. They depend on a signal processor before them to provide the proper clock rate. If there is no such signal processor and the signal comes straight from a demodulated S/PDIF clock, then you get some jitter.
Clock syncing is actually a non-trivial problem, because clock rates tend not to be exact (and S/PDIF has no sample clocking - it just feeds data at whatever rate the sender chooses). A self-clocked DAC would end up drifting out of alignment with the source and have to either skip or duplicate some samples every now and then, which probably won't sound very good without some filtering. So a dumb DAC will always use whatever clock it gets from the input. Syncing is of course performed whenever you have a DSP, both because you have to do it and because a DSP has the hardware and software capable of doing it. And just about every S/PDIF receiver uses a DSP.
Correct.
On S/PDIF clock and data are merged, so cable quality (which is tied to cable length) affects the recovered clock. Since the clock is tied to data, phase errors due to the cable do not result in a consistent phase error after clock recovery. As you degrade an S/PDIF connection, the recovered clock quality suffers until the point where you get data bit errors. Again, this is irrelevant for just about all S/PDIF receivers (which use a DSP); I'm just trying to explain where the original claimed issue comes from.
I don't know what the RJ-45 interface is about so I wouldn't know what to tell you here. It's been claimed it's I2S but I somehow doubt that. Anyway, the kind of "high-end" stuff made by "high-end" companies that also make "high-end" cables probably has lower chances of getting these kinds of issues right. It's what you get when companies are more interested in catering to bullshit audiophile claims than actual good design.
Yeah, you can. See, this is where you audiophiles fail: you take some word that refers to a real concept and mangle it into fairy tales that have nothing to do with reality.
Jitter is real, it affects craptacular dumb DACs driven by a clock recovered from a self-clocking signal, and it's eliminated completely by any form of clocked digital processing or buffering on the signal after clock recovery. Or in other words, yes, it exists, no, it doesn't affect 99% of AV receivers out there.
You can have poor quality digital audio, in one very specific case that audiophiles love to extend to the rest of the world: (very) jittery clocks caused by self-clocking modulation with no buffering or cleanup at the receiver side. This is what they call jitter. It's a true effect and it does affect signal quality at the output (how audible it is is subject to debate). The issue is that digital signal data is digital, but digital signal clocks are analog: the timing is determined by "analog" clock edges (time isn't quantized). This is fine for periodic simple clocks, since any distortion will be uniform and the result will still be a stable clock. However, once you merge clock and data into one stream (like S/PDIF), the recovered clock has artifacts that depend on the data and the kind of degradation that the signal suffered after traveling through the wire. The actual clock is still a clock, it's just that its edges are no longer uniformly spaced. If you feed this to a dumb DAC that clocks from its input, you get audio samples that aren't exactly uniform, and this is a measurable effect that could conceivably affect audio quality. Specific DAC types (sigma-delta etc) may or may not further aggravate this.
Thing is this only affects the specific circumstance of self-clocking protocols and dumb DACs with no digital processing, clock regeneration, or buffering. Add any of those and the issue goes away entirely, and we're back in the purely digital world where things either work perfectly or suck completely.
The problem is there are no error correction or CRC mechanisms in I2S digital audio and S/PDIF digital audio, which are by far the most common. S/PDIF does parity and the receiver can mask (not correct) errors if it's smart enough, but don't count on it.
Things like retransmissions are taken for granted in communications protocols, and things like CRCs are taken for granted in storage media, but digital audio streaming interfaces are really quite simple in comparison.
You clearly haven't tried it, at least not with calm music. Here, try this. That's a single-sample, single-channel glitch at around second 16, created by changing a single byte in a WAV file with a hex editor (and then encoding to Vorbis for bandwidth reasons - this does not affect the effect of the glitch significantly). It's quite obvious.
You're confusing jitter with clock skew. Clock skew means nothing as long as the input signal is still within the setup/hold times of the receiver. It either works or doesn't. This isn't to say that you don't need good matching, just that better matching will not improve quality.
Jitter is different. Jitter is uneven clocking. On the other hand, jitter is almost nonexistent on separate clock/data connections because any delays in the clock are consistent.
Jitter does matter in things like S/PDIF that combine clock and data, because then the data will affect the distortion on the clock and it will be jittery when recovered. This is what all the talk about jitter is: S/PDIF (and similar) clock recovery. Don't mix it up with other issues and other interfaces.
S/PDIF does have improved quality if the signal is less distorted, because it improves jitter. This problem can be completely eliminated by using a buffer before the DAC, or at least a PLL to clean up the clock (it only affects DACs that clock straight off of the recovered S/PDIF clock). Other interfaces (I2S) with separate clock and data do not have this problem because any distortion on the clock is consistent cycle to cycle.
You may be interested to learn that most digital audio interconnects these days still don't use error correction. Some use parity to detect errors, and may use error concealment techniques to hide errors (interpolation), but they don't use true digital error correction that results in an identical output. This means that you still need a reasonably decent connection, crappy connections which cause errors every few seconds do result in apparent noise (especially with systems that don't use parity and error concealment). These errors aren't really common though, because building a reasonable quality digital cable is by no means rocket science (or expensive), but this has nothing to do with error correction.
Digital audio storage (CD, Flash memory, etc) does use error correction.