1. The portable device issue is one of chicken-vs-egg, add demand and support will follow (probably in short-order since it's just a firmware update, something iThings handle very nicely if you use them with the iSoftware).
2. Ripping is indeed a pain, however I like to hoard the physical goods; the sleeves and whatnot. I rip them to flac and mp3 and my Squeezebox plays the flac versions, my portables will settle for mp3 (mostly because of storage space and the devices don't have that good DAC+amp anyway). Another reason for flac is future-proofing, I would absolutely hate to re-rip the 600+ (and counting) collection: it would take months...
3. Is also simply solved by the iSoftware (it already has options for automagical transcoding), or whatever software your favourite player ships with.
> CD audio is also not as good as LP audio; where the LP playback is done with a high quality pickup cartridge, and the playback is pristine (no record scratches, dust, vibration, hum, incorrect turntable setup, etc).
Actually LPs have significant dynamic range compression (ie reduction in "quality") for example the "RIAA correction", now you could claim that since all of this is done in analog you still have "infinite" resolution but fact is that vinyl has higher noise-floor than CD.
Now the mastering techniques are different and especially when CDs were new people didn't really know how to master them properly and thus did all sorts of mistakes leading to the fact that those albums sounded much better on vinyl.
And to dispel another myth: tube amps actually distort the sound more than transistor amps, however the distortions are "pleasing" to most humans so many people prefer the tube sound even though from cold-facts POV it's inferior quality. And of course it can be argued that if a record has been mastered in the golden age of tube amps then it will likely sound best on a tube amp due to the fact that the mastering has been tweaked to take advantage of the limitations of the medium.
I do agree that 16bit @44.1kHz is a bit low for "true sound" since there are all sorts of harmonics to consider in the frequencies that are technically above human hearing range, but isn't new recording work done on 24bit @192kHz, I must admit I can't remember the dvd-audio spec... Anyways even if you master down from that in the intermediate steps you will want plenty of headroom so nothing gets lost accidentally.
Yes, and when the goverment proves that he actually is a drug dealer *then* they can forfeit property as part of damages (punititive or otherwise), before the trial they can freeze the assets (not forfeit, *freeze* a *huge* difference) to avoid the property from "getting lost" (this is also a bit tricky, a person should be able to defend themselves but if all their assets are totally frozen how to do that ? [IMO using frozen property to fund defense should be allowed])
> rather than trying to stick some kid in pound-me-in-the-ass hard-core prison, for writing a script that spams a bunch of crap to a million accounts.
Writing a script is not a problem, you can do what you want with your own resources, however it gets more complicated when you involve my resources (bandwidth + time) and resources I pay in part for (ISP staff handling the mail servers, the bandwidth my ISP needs to handle the torrent of spam in addition to legitimate traffick).
This conviniently excludes the fact that spammers use malware induced zombies (definitely illegal) to send the messages (for various technical and economic reasons)
Let's do a quick calculation; I use a few minutes a day to doublecheck that I have no important mail in the spam folder, this at my consulting rates comes to about 10EUR/day, let's round the daily spam to 200pcs so per spam it's 0.05EUR, doesn't sound much ? well it does add up, multiply by a few hundred million messages sent per spam run and suddenly it's a very real and very big cost to society (and this is just the lost time alone, adding all the extra infrastructure and staff will increase the cost even more).
Joe-Jobs are of course a problem but should be easy to weed out with proper investigation, but yes, going after the spammers themselves is going to be unproductive. OTOH those actually selling the stuff need some way to handle payments which will make tracking them down relatively easy. So go after the ones who pay for spam to be sent, fine them say 1USD/spam, halved if their help is instrumental in nailing the actual spammer (1USD/spam plus of course whatever using malware to zombie boxes earns them) and of course if they're breaking any other laws then that's a separate issue.
And since "they" (internet "pharmacy") choose to ignore the rules about how to properly check the person doing to ordering actually 1. has prescription 2. is the person to whom the medicine has been prescribed you might want to think about what other rules they choose to ignore for their profits.
For example: using reputable suppliers that actually deliver what it says on the box.
Also since their customers are not acting exactly within the law themselves it's all too tempting to just send them whatever cheap pills they happen to have at hand (if it's only placebo the customer is lucky to only having been defrauded and not poisoned too [yes, I have lost my faith in humanity], but I don't think those are actually the cheapest pills available) and trust that the people who respond to spam are not going to go complain to the police that they got defrauded when illegally buying drugs.
My ISP back here in finland will actually rent you a static IP-block even for consumer-grade connection if you ask nicely (and configure reverse-dns for them upon request too [though that might be just me; I have very good relations with them and very rare name]), don't really know if they block outgoing 25 since I always have used their mail server as smarthost (it saves me a whole bunch of trouble with blacklists etc).
I also have a proper business-grade connection from them (since the uplink speeds on consumer-grade connections suck) at another location and that one is expensive (over 5 times the price of the consumer link), however it's not "best effort" of a theoretical maximum bandwidth you will never reach (and that too is shared between who know how many subscribers) but proper guaranteed bandwidth from your modem to their interconnects (and up/down bandwidths are the same), now the consumer stuff is in theory 10Mbit per sec, still for "some reason" (aka the "best effort") the 4Mbit/sec business-grade connection constantly achieves higher sustained transfer rates...
Some people might have highly malleable double-standards but I for example still do buy music and/or stream/download it from the various fully legal sources.
My problem with the *AAs of the world (IFPI and it's minions are the problem here in Europe) is first the whole stupid DRM debacle and criminalizing in a backhanded way things that used to be legal (time and format shifting was fully legal before the "protection circumvention" stuff came along, now the status is questionable at best) while still demanding "compensation payments" on blank media (instantiated back when tape-to-tape copying was all the rage) the "compensation" scheme was just increased to cover external hard-drives for example, which is totally nuts but apparently they have bought the right politicians.
Then there's the sampling issue (no piece of music recorded in commercial interest has been truly original [there might be something truly original recorded somewhere but it would so completely weird that it never be commercially successful, people like famialiarity], everything borrows from something else) and length of copyright issue (current "limits" are totally meaningless).
Add to that the 3-strikes etc things they "must have" since they possibly can't use the existing legal framework to go after the infringers the way it was meant to be (specifically: make the process such that it's only worth going after commercial counterfeiters instead of harassing individuals into "settlements").
I could go on about more issues with Imaginary Property in general but for me there is no real double-standard between game assets and music/movies.
the exponential problem is that increasing key size by a single bit doubles the time required to check the key space.
So yes, should quantum factorization actually work for real-world key sizes this would be a huge advantage for the attacker compared to the current situation but it's still less costly for the defender to double the key size in order to keep the "probably not decrypted while earth still exists" timeframe than for the attacker increase their cracking capability to match.
Of course Amazons EC2 do not automatically protect you from DDOS, they merely allow you to build an automatically scalabale system should you have the money and interest to pay for that scaling when needed.
This is not a critisism of EC2, just pointing out that there's no magical Amazon unicorn defending your website even if you happen to host it on a server in EC2.
By now you may have seen my follow-up that I mistyped when I said "un-md5" (meant compare hashes on the server).
Yup, that was in fact a completely secondary point to me as I first thought that is what you *must* have meant , since hashes are not reversible, and only seconds later decided that maybe pointing the fact out might be a good idea.
But I disagree that all logins (even for large sites) are encrypted.
For example, I use Slashdot just fine without JavaScript. I haven't checked the source, but the standard HTML FORM element doesn't encrypt anything when sending form submissions over the network. So the password must obviously be sent (at least the first time) in the clear.
That's why I was encouraging people to md5 their passwords on the client before sending it over. That won't stop this attack, but it'll stop others (security in-depth).
A fair point, though that would require either plaintext passwords (*very* bad) or unsalted passwords (slightly bad) in db (or first validating the username to get the specific users salt to be passed on to the client but that is again rather bad).
IMO someone attacking the server gaining access to wholesale set of plaintext or unsalted (rainbow tables here we come) usernames&passwords is in fact worse than someone sniffing plaintext passwords in POSTs in you network segment (or between you and server but that's less likely).
Actually on wired network it depends on the switching hardware whether you're getting packets meant for others on your port or not (discounting active mac/arp spoofing but with properly configured high-end HW you will find yourself in an isolated network segment really quickly if you try that)
The problem is not reading the password as plaintext from the cookie (now that would be monumentally stupid design) but that since the cookie equals valid session authentication copying the cookie equals session hijacking (or sidejacking since the original cookie is still there on the original users machine).
Replying to myself, seems like PhonebookFS has many of the same ideas as Rubberhose, but is probably easier to get into (it's not been pronounced officially dead yet but things are not looking good for it either)
It seems rubberhose is dead, but look at it and especially the fundamental ideas in it if you really wish to pursue this (I like the idea of having N encrypted volumes and the fact that you cannot prove that you have fully co-operated [and they cannot prove that you're not], of course you need some interesting data on the "bait" volumes as well).
The problem with properly used encryption being indistinguishable from random data is that you need a lot of good quality random data to hide your encrypted data in, because it will be distinguishable from the not-so-random data that you get out of/dev/urandom.
If you are in a situation where you will actually need encryption (especially deniable the sort) then don't trust your own code. As they say: A lawyer who represents himself has a fool for a client. (Don't trust someone elses code either unless it has been actually reviewed by more than two people who actually know how to do cryptoanalysis)
Cracking HDCP would probably be one of the most inefficient ways of backing up your whatever happens to travel over HDMI: the protocol is for encrypting the uncompressed data streams, which are *huge* (current HDMI max bandwidth is 10.2Gbit/s though 1080p + 7ch audio uses less than that but it's still multiple gigabits/s).
And it's not like there hasn't been any HD material on the pirate networks before...
I don't really understand why the hell HDCP was ever taken into use; it causes a ton of problems due to subtle implementation differences and even specification issues (my brother does big AV-system installations [well, programming for the control touchscreen controllers etc] and HDCP causes them no end of headaches) and the protection value is questionable at best since capturing the raw uncompressed bitstreams wasn't even close to practicality back when the protocol was designed. Sure HW will get better, so "it's for the future" is a valid argument, however attacks too will get better and now we have a total break and nothing but trouble and expense to show for it.
Of course the trouble and most of the expense is externalized to us, the customers, so maybe it was a good deal to those that wanted to temporarily block a totally unpractical approach to copying the content.
"anybody" (with sufficient resources for HW design and manufacture) can now create source or sink device, which is nice but doesn't yet solve the most problems HDCP causes on practical level (not all compliant devices like to talk to each other, my old DVD player [with DVI output, high-end device back in the day] crashed every time I tried to connect it to my new projector, either directly or through my amp which has repeater) for those HDCP would have to be turned off. OTOH for the problems of the big-AV-setups (think monitor matrices etc) now a HW solution can be made, need to route picture to multiple monitors or do PiP ? All but impossible before because it was not possible to do decrypt->mix->re-encrypt (according to specs repeaters have to be dumb AFAIUnderstand)
Case point industrial processes: some take multiple days to restart if halted, and downtime costs 20-60kEUR/minute (and beyond). So "oops I accidentally the whole" that triggers emergency shutdown by mistake is simply not an option.
Doing proper correctness verification gets very, very expensive as soon as complexity goes beyond trivial.
AFAIUnderstood none and it's not the currency networks problem anyway (as long as the botherders are running peers that act within the rules of the network).
OTOH the bot-herders are already turning their victims electricity and broadband bills to cash and usually in ways that generate damage to third parties as well, I for one would be very pleased if they suddenly decided it would be more profitable just to generate bitcoins instead.
1. The cost of the SMS is cost enough that nosy people won't go on a massive trawl of the data (since if it was legal to publish said info someone would set up a crowdsourced database).
2. When the vehicle changes owner the traffick authority knows about it, you probably don't (and since your incentive to publsih someones info is to "name and shame" someone else is now in the receiving end of hate intended to the previous owner of registration number X)
3. They want to protect their revenue stream (see crowdsourced db from point 1)
> Wouldn't getting hold of THOSE codes be interesting? They'd amount to the capability for any terrorist with the codes and a radio to launch a nuclear strike on the West.
This is different from the American looking glass radio-controlled launch authorization how ?
The interesting thing about micropayments is the micro-part, I've consulted for website that sells subscriptions and ala carte access to articles, but these cost 8EUR minimum (they're also well researched articles on international politics by known and respected analysts and thus well worth the money to those who buy them...), micropayments by definition are very small.
The problem is that there is a limit where transaction costs make the exercise worthless to the publisher and that means it's simply not possible to pay say 10eurocents for an X (let alone single cents or fractions of cents). thus either X must be ad-funded, free, or much higher value for the user.
Also note that du reports the *size on disk*, which means it's just about always slightly larger than the "real" size of the file because you can't put parts of two files on the same block.
Available here in Finland in just about any supermarket, yay! My gripe is that only available dubbed, I would really liked to see them (once upon a time... X) it in the original french with subtitles (either finnish or english).
Also I have a bunch of boxed sets of anime that I haven't gotten around to watching yet due to time constraints so will not be buying more untill the to-watch -buffer is empty.
Slashdot Mirror
1. The portable device issue is one of chicken-vs-egg, add demand and support will follow (probably in short-order since it's just a firmware update, something iThings handle very nicely if you use them with the iSoftware).
2. Ripping is indeed a pain, however I like to hoard the physical goods; the sleeves and whatnot. I rip them to flac and mp3 and my Squeezebox plays the flac versions, my portables will settle for mp3 (mostly because of storage space and the devices don't have that good DAC+amp anyway). Another reason for flac is future-proofing, I would absolutely hate to re-rip the 600+ (and counting) collection: it would take months...
3. Is also simply solved by the iSoftware (it already has options for automagical transcoding), or whatever software your favourite player ships with.
> CD audio is also not as good as LP audio; where the LP playback is done with a high quality pickup cartridge, and the playback is pristine (no record scratches, dust, vibration, hum, incorrect turntable setup, etc).
Actually LPs have significant dynamic range compression (ie reduction in "quality") for example the "RIAA correction", now you could claim that since all of this is done in analog you still have "infinite" resolution but fact is that vinyl has higher noise-floor than CD.
Now the mastering techniques are different and especially when CDs were new people didn't really know how to master them properly and thus did all sorts of mistakes leading to the fact that those albums sounded much better on vinyl.
And to dispel another myth: tube amps actually distort the sound more than transistor amps, however the distortions are "pleasing" to most humans so many people prefer the tube sound even though from cold-facts POV it's inferior quality. And of course it can be argued that if a record has been mastered in the golden age of tube amps then it will likely sound best on a tube amp due to the fact that the mastering has been tweaked to take advantage of the limitations of the medium.
I do agree that 16bit @44.1kHz is a bit low for "true sound" since there are all sorts of harmonics to consider in the frequencies that are technically above human hearing range, but isn't new recording work done on 24bit @192kHz, I must admit I can't remember the dvd-audio spec... Anyways even if you master down from that in the intermediate steps you will want plenty of headroom so nothing gets lost accidentally.
Yes, and when the goverment proves that he actually is a drug dealer *then* they can forfeit property as part of damages (punititive or otherwise), before the trial they can freeze the assets (not forfeit, *freeze* a *huge* difference) to avoid the property from "getting lost" (this is also a bit tricky, a person should be able to defend themselves but if all their assets are totally frozen how to do that ? [IMO using frozen property to fund defense should be allowed])
> rather than trying to stick some kid in pound-me-in-the-ass hard-core prison, for writing a script that spams a bunch of crap to a million accounts.
Writing a script is not a problem, you can do what you want with your own resources, however it gets more complicated when you involve my resources (bandwidth + time) and resources I pay in part for (ISP staff handling the mail servers, the bandwidth my ISP needs to handle the torrent of spam in addition to legitimate traffick).
This conviniently excludes the fact that spammers use malware induced zombies (definitely illegal) to send the messages (for various technical and economic reasons)
Let's do a quick calculation; I use a few minutes a day to doublecheck that I have no important mail in the spam folder, this at my consulting rates comes to about 10EUR/day, let's round the daily spam to 200pcs so per spam it's 0.05EUR, doesn't sound much ? well it does add up, multiply by a few hundred million messages sent per spam run and suddenly it's a very real and very big cost to society (and this is just the lost time alone, adding all the extra infrastructure and staff will increase the cost even more).
Joe-Jobs are of course a problem but should be easy to weed out with proper investigation, but yes, going after the spammers themselves is going to be unproductive. OTOH those actually selling the stuff need some way to handle payments which will make tracking them down relatively easy. So go after the ones who pay for spam to be sent, fine them say 1USD/spam, halved if their help is instrumental in nailing the actual spammer (1USD/spam plus of course whatever using malware to zombie boxes earns them) and of course if they're breaking any other laws then that's a separate issue.
And since "they" (internet "pharmacy") choose to ignore the rules about how to properly check the person doing to ordering actually 1. has prescription 2. is the person to whom the medicine has been prescribed you might want to think about what other rules they choose to ignore for their profits.
For example: using reputable suppliers that actually deliver what it says on the box.
Also since their customers are not acting exactly within the law themselves it's all too tempting to just send them whatever cheap pills they happen to have at hand (if it's only placebo the customer is lucky to only having been defrauded and not poisoned too [yes, I have lost my faith in humanity], but I don't think those are actually the cheapest pills available) and trust that the people who respond to spam are not going to go complain to the police that they got defrauded when illegally buying drugs.
My ISP back here in finland will actually rent you a static IP-block even for consumer-grade connection if you ask nicely (and configure reverse-dns for them upon request too [though that might be just me; I have very good relations with them and very rare name]), don't really know if they block outgoing 25 since I always have used their mail server as smarthost (it saves me a whole bunch of trouble with blacklists etc).
I also have a proper business-grade connection from them (since the uplink speeds on consumer-grade connections suck) at another location and that one is expensive (over 5 times the price of the consumer link), however it's not "best effort" of a theoretical maximum bandwidth you will never reach (and that too is shared between who know how many subscribers) but proper guaranteed bandwidth from your modem to their interconnects (and up/down bandwidths are the same), now the consumer stuff is in theory 10Mbit per sec, still for "some reason" (aka the "best effort") the 4Mbit/sec business-grade connection constantly achieves higher sustained transfer rates...
Some people might have highly malleable double-standards but I for example still do buy music and/or stream/download it from the various fully legal sources.
My problem with the *AAs of the world (IFPI and it's minions are the problem here in Europe) is first the whole stupid DRM debacle and criminalizing in a backhanded way things that used to be legal (time and format shifting was fully legal before the "protection circumvention" stuff came along, now the status is questionable at best) while still demanding "compensation payments" on blank media (instantiated back when tape-to-tape copying was all the rage) the "compensation" scheme was just increased to cover external hard-drives for example, which is totally nuts but apparently they have bought the right politicians.
Then there's the sampling issue (no piece of music recorded in commercial interest has been truly original [there might be something truly original recorded somewhere but it would so completely weird that it never be commercially successful, people like famialiarity], everything borrows from something else) and length of copyright issue (current "limits" are totally meaningless).
Add to that the 3-strikes etc things they "must have" since they possibly can't use the existing legal framework to go after the infringers the way it was meant to be (specifically: make the process such that it's only worth going after commercial counterfeiters instead of harassing individuals into "settlements").
I could go on about more issues with Imaginary Property in general but for me there is no real double-standard between game assets and music/movies.
how about strange and charmed ?
the exponential problem is that increasing key size by a single bit doubles the time required to check the key space.
So yes, should quantum factorization actually work for real-world key sizes this would be a huge advantage for the attacker compared to the current situation but it's still less costly for the defender to double the key size in order to keep the "probably not decrypted while earth still exists" timeframe than for the attacker increase their cracking capability to match.
Of course Amazons EC2 do not automatically protect you from DDOS, they merely allow you to build an automatically scalabale system should you have the money and interest to pay for that scaling when needed. This is not a critisism of EC2, just pointing out that there's no magical Amazon unicorn defending your website even if you happen to host it on a server in EC2.
By now you may have seen my follow-up that I mistyped when I said "un-md5" (meant compare hashes on the server).
Yup, that was in fact a completely secondary point to me as I first thought that is what you *must* have meant , since hashes are not reversible, and only seconds later decided that maybe pointing the fact out might be a good idea.
But I disagree that all logins (even for large sites) are encrypted.
For example, I use Slashdot just fine without JavaScript. I haven't checked the source, but the standard HTML FORM element doesn't encrypt anything when sending form submissions over the network. So the password must obviously be sent (at least the first time) in the clear.
That's why I was encouraging people to md5 their passwords on the client before sending it over. That won't stop this attack, but it'll stop others (security in-depth).
A fair point, though that would require either plaintext passwords (*very* bad) or unsalted passwords (slightly bad) in db (or first validating the username to get the specific users salt to be passed on to the client but that is again rather bad).
IMO someone attacking the server gaining access to wholesale set of plaintext or unsalted (rainbow tables here we come) usernames&passwords is in fact worse than someone sniffing plaintext passwords in POSTs in you network segment (or between you and server but that's less likely).
Actually on wired network it depends on the switching hardware whether you're getting packets meant for others on your port or not (discounting active mac/arp spoofing but with properly configured high-end HW you will find yourself in an isolated network segment really quickly if you try that)
The login forms/submissions AFAIUnderstand do go over SSL so doing encrypting the password is kinda pointless there.
Also there is no such thing as "un-md5", now the password might be encrypted (des/aes/whatever) but hashes are by definition one-way.
You are missing the point.
The problem is not reading the password as plaintext from the cookie (now that would be monumentally stupid design) but that since the cookie equals valid session authentication copying the cookie equals session hijacking (or sidejacking since the original cookie is still there on the original users machine).
Replying to myself, seems like PhonebookFS has many of the same ideas as Rubberhose, but is probably easier to get into (it's not been pronounced officially dead yet but things are not looking good for it either)
Unless you're Bruce (Schneier).
It seems rubberhose is dead, but look at it and especially the fundamental ideas in it if you really wish to pursue this (I like the idea of having N encrypted volumes and the fact that you cannot prove that you have fully co-operated [and they cannot prove that you're not], of course you need some interesting data on the "bait" volumes as well).
The problem with properly used encryption being indistinguishable from random data is that you need a lot of good quality random data to hide your encrypted data in, because it will be distinguishable from the not-so-random data that you get out of /dev/urandom.
If you are in a situation where you will actually need encryption (especially deniable the sort) then don't trust your own code. As they say: A lawyer who represents himself has a fool for a client. (Don't trust someone elses code either unless it has been actually reviewed by more than two people who actually know how to do cryptoanalysis)
Cracking HDCP would probably be one of the most inefficient ways of backing up your whatever happens to travel over HDMI: the protocol is for encrypting the uncompressed data streams, which are *huge* (current HDMI max bandwidth is 10.2Gbit/s though 1080p + 7ch audio uses less than that but it's still multiple gigabits/s).
And it's not like there hasn't been any HD material on the pirate networks before...
I don't really understand why the hell HDCP was ever taken into use; it causes a ton of problems due to subtle implementation differences and even specification issues (my brother does big AV-system installations [well, programming for the control touchscreen controllers etc] and HDCP causes them no end of headaches) and the protection value is questionable at best since capturing the raw uncompressed bitstreams wasn't even close to practicality back when the protocol was designed. Sure HW will get better, so "it's for the future" is a valid argument, however attacks too will get better and now we have a total break and nothing but trouble and expense to show for it.
Of course the trouble and most of the expense is externalized to us, the customers, so maybe it was a good deal to those that wanted to temporarily block a totally unpractical approach to copying the content.
"anybody" (with sufficient resources for HW design and manufacture) can now create source or sink device, which is nice but doesn't yet solve the most problems HDCP causes on practical level (not all compliant devices like to talk to each other, my old DVD player [with DVI output, high-end device back in the day] crashed every time I tried to connect it to my new projector, either directly or through my amp which has repeater) for those HDCP would have to be turned off. OTOH for the problems of the big-AV-setups (think monitor matrices etc) now a HW solution can be made, need to route picture to multiple monitors or do PiP ? All but impossible before because it was not possible to do decrypt->mix->re-encrypt (according to specs repeaters have to be dumb AFAIUnderstand)
Case point industrial processes: some take multiple days to restart if halted, and downtime costs 20-60kEUR/minute (and beyond). So "oops I accidentally the whole" that triggers emergency shutdown by mistake is simply not an option.
Doing proper correctness verification gets very, very expensive as soon as complexity goes beyond trivial.
AFAIUnderstood none and it's not the currency networks problem anyway (as long as the botherders are running peers that act within the rules of the network).
OTOH the bot-herders are already turning their victims electricity and broadband bills to cash and usually in ways that generate damage to third parties as well, I for one would be very pleased if they suddenly decided it would be more profitable just to generate bitcoins instead.
1. The cost of the SMS is cost enough that nosy people won't go on a massive trawl of the data (since if it was legal to publish said info someone would set up a crowdsourced database).
2. When the vehicle changes owner the traffick authority knows about it, you probably don't (and since your incentive to publsih someones info is to "name and shame" someone else is now in the receiving end of hate intended to the previous owner of registration number X)
3. They want to protect their revenue stream (see crowdsourced db from point 1)
to nitpick: the gas wents and the semi/full -auto mechanism eat a nontrivial amount energy of the "equal but opposite reaction".
> Wouldn't getting hold of THOSE codes be interesting? They'd amount to the capability for any terrorist with the codes and a radio to launch a nuclear strike on the West.
This is different from the American looking glass radio-controlled launch authorization how ?
The interesting thing about micropayments is the micro-part, I've consulted for website that sells subscriptions and ala carte access to articles, but these cost 8EUR minimum (they're also well researched articles on international politics by known and respected analysts and thus well worth the money to those who buy them...), micropayments by definition are very small.
The problem is that there is a limit where transaction costs make the exercise worthless to the publisher and that means it's simply not possible to pay say 10eurocents for an X (let alone single cents or fractions of cents). thus either X must be ad-funded, free, or much higher value for the user.
Also note that du reports the *size on disk*, which means it's just about always slightly larger than the "real" size of the file because you can't put parts of two files on the same block.
Available here in Finland in just about any supermarket, yay! My gripe is that only available dubbed, I would really liked to see them (once upon a time ... X) it in the original french with subtitles (either finnish or english).
Also I have a bunch of boxed sets of anime that I haven't gotten around to watching yet due to time constraints so will not be buying more untill the to-watch -buffer is empty.