iTunes would have any song you ever might want, so what if only a small handful of people ever download a particular song? It's only (cheap) hard disk space.
I don't know why but I'm picturing an enormous 40-foot-high iPod sitting in an aircraft hangar outside Cupertino...
If you can use a device form anywhere without changing its address, won't this break ingress/egress-based filtering and introduce a whole new range of spoofing problems?
The hackers have evil-looking electronic spikes stuck into their spinal columns. I guess their interface equipment is scavenged from the "pod farms", and the machines have no qualms about killing humans, so the equipment probably includes functions to kill the wearer when he/she dies in the simulation. Maybe they don't have the tools to build "safe" equipment?
And why make a database field a file, when it already exists in the database, which itself is a file?
Well, I think the idea is that the database wouldn't be a file.;-) The database would be a collection of files, moving as much structure as possible into the filesystem, so you could use the same interface for any strutured data storage/retrieval task.
Hey, let's take this to the logical conclusion! Let's have hardlink between modification time metadata files. And the modification time for the modification time file could be a file as well!
I must admit I wondered about that too. Where are the read/write/execute permissions for foo/..rwx stored? In foo/..rwx/..rwx?
The metadata-aware system treats the MP3 file as a directory. If there is a plugin associated with MP3 files, the contents of the directory will be dynamically generated based on the contents of the file (ID3 tags for title, artist etc). The ID3 tags will also be updated by the plugin if you modify the contents of the directory (eg echo "Ornette Coleman and Howard Shore" > "Naked Lunch.mp3/artist"). Obviously if you create metadata that the plugin can't understand, it won't be stored in the file (eg echo "8/10" > "Naked Lunch.mp3/rating").
If there is no plugin associated with MP3 files, the contents of the directory will be independent from the contents of the file. If you change Naked Lunch.mp3/artist, the corresponding tag in the MP3 file will not be changed.
Either way, you will be able to move the MP3 file to a metadate-unaware filesystem and it will still be a valid MP3 file. However, some of the metadata will be lost unless you move the entire directory.
Here's my question though: if you move the entire directory to a metadata-unaware system, will it be possible to access the MP3 file as a file rather than as a directory, through a file called Naked Lunch.mp3/..data or something similar?
Reiser4 doesn't throw away the "everything is a file" model. In fact, it extends it: an ACL can be a file, a modification time can be a file, a database field can be a file. Reiser4 is making the Unix filesystem into what it was always meant to be: a single, unified namespace for storing any kind of data, so that any kind of data can be manipulated by the same simple tools.
Write the XML so that if you email one of these files to someone that doesn't support the system, it could be trivial for them to get the data.
OK, imagine how you would do that: you wouldn't want to send the data twice, so the data would need to be sent as a second attachment, and instead of a data field in the XML file you would have a field saying, effectively, "see second attachment for data". So what you have now is a file for metadata, and a file for data.
If you continue to break down the metadata file so that _every_ field is stored in a separate data file, you're left with an XML file containing field-name/pointer pairs (ie a directory), and a bunch of files. Which is pretty much what the article was describing, but without the XML.
you are incorrectly assuming that the network scales linearly
No, I mentioned logarithmic scaling in my post.
In fact, much of the traffic is going to be for relatively few, popular blocks, a bunch of medium popular blocks, and a few unpopular blocks - it isn't going to be a bell curve either
I think the phrase you're looking for is "Zipf-like query distribution".;-) You have a good point -- caching can reduce communication overhead in a filesharing scenario -- but it remains to be seen whether caching can have a large enough effect to make anonymous filesharing networks worthwhile for the majority of users.
Designed correctly, it is possible to implement a group-anonymous, minimal-trust distributed protocol for distributing 0day releases faster than BitTorrent.
Yes, you just need to get the nodes to arrange themselves into a spanning tree with the source of the file at the root. But distributing a file quickly to all nodes is not the problem I'm trying to solve.
Overnet/eDonkey are also a minimal speed - in a network of 1 million nodes, weighted via estimated upload speed distribution, you can expect 30KB/s for the average archive release ISO and about 25 seconds of latency between request and beginning of mesh transfer. You telling me that's not good enough?
You're comparing apples to oranges. I was talking about a network in which every request and reply is routed through a fixed overlay topology based on the web of trust. You're talking about a network in which nodes connect directly to untrusted nodes. Obviously if you're prepared to connect to untrusted nodes you can get good performance.
Weird thing is - how is it that the real files are just not out there amidst all the fakes?
Are you using a FastTrack-based network? The details of the FastTrack protocol are secret, but it's known to use "supernodes" for searching: your list of shared files is sent to the nearest supernode, all searches are sent to the nearest supernode, and supernodes only forward searches to other supernodes. This avoids Gnutella's problem of low-bandwidth nodes being overwhelmed by search traffic.
My guess is that the RIAA has worked out how the supernodes rank search results, and is tailoring the descriptions of its fake files to produce good rankings. For example, your file probably gets a high rank if you advertise a high-speed connection, respond quickly to PINGs, never cancel transfers, and stay online for weeks at a time.
Perhaps real copies of the songs are still out there, but you can't find them because the RIAA has worked out how to exploit the search system.
If I can see addresses other than the addresses of my neighbors in the overlay (who are presumably my friends or at least people who trust me in real life), then I can systematically gather information about who is sharing what, which is unreasonable. It seems that Freenet is suited to this.
Freenet nodes publish their addresses through the DataSource field of DataReply messages. This doesn't allow the recipient of the message to work out who is sharing what, because the DataSource is reset with a low probability by each node the message passes through. But it does allow a passive "address-gathering" attack which will eventually allow you to identify all Freenet participants, or all participants in a particular jurisdiction (eg China, RoadRunner, UCLA).
1. Data should pass through the overlay network. 3. Performance should be reasonable.
It's hard to see how these requirements can be reconciled. Even if the sender and recipient are on average only 2 hops apart in the overlay network, the effective bandwidth of all nodes is halved. Even if the overlay network has "small world" characteristics and the shortest path can always be found, the best we can realistically hope for is that the number of hops will grow logarithmically with the number of nodes. For a network of 10,000 nodes (the predicted scaling limit of Gnutella), each message might make a dozen hops, so each node will only get to use 1/12 of its bandwidth for its own traffic (the rest will be used for forwarding other nodes' traffic). People are unlikely to use such a network unless they have a very good reason for needing anonymity.
For this reason I suspect that the future of anonymous networking does not lie in internet overlays, but in new networks that are potentially independent of the internet, even if some of their links are made across the internet for the time being.
Your suggestion is very interesting, but it relies on the assumption that people will not be prepared to buy counterfeit copies. In the digital realm where copies are perfect, I'm not sure that's a realistic assumption.
Of course people might not be willing to openly sell counterfeit copies if there's an audit trail, but it will be possible for resellers to "fork" a legitimate artifact by selling multiple copies, each of which appear to be legitimate because it will have an audit trail leading back to the original seller. Unless every resale is somehow tied to the seller's legal identity, illegitimate copies will gradually "leak" into the legitimate market.
OK, I propose the 3PM format:
The header is the same as an MP3 file. The ID3 tag is the same as an MP3 file. The audio data is byte-swapped, so the four bytes ABCD are stored DCBA. If the length of the audio data is not a multiple of four bytes, the last 1-3 bytes are left untouched.
The extension can be.mp3 or.3pm, depending on how easy you want to make it for Sean to filter out byte-swapped files.
Many thanks for the link - I've emailed London's MEPs expressing my concern. Unfortunately I suspect the biggest difference it makes will be to the size of my 'Sent' folder. Ho hum.
Just my two cents: it's adding people from all over the world to my list. I live in a suburb of Philadelphia USA (on the East Coast for those not familiar with the US) and it's adding people to my list from Australia, Scandinavia, California.... etc.
I wonder if this is what's meant by 'progressive proximity search'? Maybe if it can't find anyone close to you then it gradually widens the search until it finds a mimimum number of people.
Visa and other Banks should have the pants sued off them for giving the public such a laugh of security in the form of credit cards.
If credit cards are so bad that someone should be sued for creating them, why do you use them? Let me guess: because it's convenient? While it's certainly inconvenient to live without a credit card in the US, since they're often used as a form of ID, it really isn't difficult to avoid USING your credit card.
You're trying to shift the blame for your own laziness onto a company that offered to make your life easier, but actually made it more complicated. SURPRISE: Most of the things that companies claim will make your life simpler, actually make it more complicated. If you desire a simple life, it is occasionally necessary NOT TO USE ALL THE SERVICES OFFERED TO YOU BY CORPORATIONS. If you decide to use a service anyway, when you know from personal experience that it will complicate your life, you should not blame anyone but yourself.
The existence of the exploit means that '007 Agent Under Fire' is a tool to circumvent the XBox's DRM, and distributing it is illegal under the DMCA.;-)
You believe it's your "right" to listen to a CD on your computer as well as on your CD player, even if that CD was designed to be compatible with your CD player but not with your computer? Do you also believe it's your right to be able to listen to that CD on a Minidisc player? On a turntable? By sticking it up a dog's arse? Of course not. The record company has no obligation to make their CDs compatible with your equipment. If you choose to buy them anyway, don't blame anyone else for violating your "rights".
And if you live in London, or any of the other British cities that are bristling with CCTV cameras:
(7) Don't use the Tube or take a bus
{8} Don't walk near shops, petrol stations or busy junctions
(9) Don't leave your house
(10) Close your curtains
(11) Enjoy your privacy! I hope it was worth it.
Slashdot Mirror
I don't know why but I'm picturing an enormous 40-foot-high iPod sitting in an aircraft hangar outside Cupertino...
Why didn't they just steal the code from BSD like they did with IPv4?
If you can use a device form anywhere without changing its address, won't this break ingress/egress-based filtering and introduce a whole new range of spoofing problems?
The hackers have evil-looking electronic spikes stuck into their spinal columns. I guess their interface equipment is scavenged from the "pod farms", and the machines have no qualms about killing humans, so the equipment probably includes functions to kill the wearer when he/she dies in the simulation. Maybe they don't have the tools to build "safe" equipment?
Well, I think the idea is that the database wouldn't be a file. ;-) The database would be a collection of files, moving as much structure as possible into the filesystem, so you could use the same interface for any strutured data storage/retrieval task.
Hey, let's take this to the logical conclusion! Let's have hardlink between modification time metadata files. And the modification time for the modification time file could be a file as well!
I must admit I wondered about that too. Where are the read/write/execute permissions for foo/..rwx stored? In foo/..rwx/..rwx?
The metadata-aware system treats the MP3 file as a directory. If there is a plugin associated with MP3 files, the contents of the directory will be dynamically generated based on the contents of the file (ID3 tags for title, artist etc). The ID3 tags will also be updated by the plugin if you modify the contents of the directory (eg echo "Ornette Coleman and Howard Shore" > "Naked Lunch.mp3/artist"). Obviously if you create metadata that the plugin can't understand, it won't be stored in the file (eg echo "8/10" > "Naked Lunch.mp3/rating").
If there is no plugin associated with MP3 files, the contents of the directory will be independent from the contents of the file. If you change Naked Lunch.mp3/artist, the corresponding tag in the MP3 file will not be changed.
Either way, you will be able to move the MP3 file to a metadate-unaware filesystem and it will still be a valid MP3 file. However, some of the metadata will be lost unless you move the entire directory.
Here's my question though: if you move the entire directory to a metadata-unaware system, will it be possible to access the MP3 file as a file rather than as a directory, through a file called Naked Lunch.mp3/..data or something similar?
Reiser4 doesn't throw away the "everything is a file" model. In fact, it extends it: an ACL can be a file, a modification time can be a file, a database field can be a file. Reiser4 is making the Unix filesystem into what it was always meant to be: a single, unified namespace for storing any kind of data, so that any kind of data can be manipulated by the same simple tools.
OK, imagine how you would do that: you wouldn't want to send the data twice, so the data would need to be sent as a second attachment, and instead of a data field in the XML file you would have a field saying, effectively, "see second attachment for data". So what you have now is a file for metadata, and a file for data.
If you continue to break down the metadata file so that _every_ field is stored in a separate data file, you're left with an XML file containing field-name/pointer pairs (ie a directory), and a bunch of files. Which is pretty much what the article was describing, but without the XML.
No, I mentioned logarithmic scaling in my post.
In fact, much of the traffic is going to be for relatively few, popular blocks, a bunch of medium popular blocks, and a few unpopular blocks - it isn't going to be a bell curve either
I think the phrase you're looking for is "Zipf-like query distribution". ;-) You have a good point -- caching can reduce communication overhead in a filesharing scenario -- but it remains to be seen whether caching can have a large enough effect to make anonymous filesharing networks worthwhile for the majority of users.
Designed correctly, it is possible to implement a group-anonymous, minimal-trust distributed protocol for distributing 0day releases faster than BitTorrent.
Yes, you just need to get the nodes to arrange themselves into a spanning tree with the source of the file at the root. But distributing a file quickly to all nodes is not the problem I'm trying to solve.
Overnet/eDonkey are also a minimal speed - in a network of 1 million nodes, weighted via estimated upload speed distribution, you can expect 30KB/s for the average archive release ISO and about 25 seconds of latency between request and beginning of mesh transfer. You telling me that's not good enough?
You're comparing apples to oranges. I was talking about a network in which every request and reply is routed through a fixed overlay topology based on the web of trust. You're talking about a network in which nodes connect directly to untrusted nodes. Obviously if you're prepared to connect to untrusted nodes you can get good performance.
Are you using a FastTrack-based network? The details of the FastTrack protocol are secret, but it's known to use "supernodes" for searching: your list of shared files is sent to the nearest supernode, all searches are sent to the nearest supernode, and supernodes only forward searches to other supernodes. This avoids Gnutella's problem of low-bandwidth nodes being overwhelmed by search traffic.
My guess is that the RIAA has worked out how the supernodes rank search results, and is tailoring the descriptions of its fake files to produce good rankings. For example, your file probably gets a high rank if you advertise a high-speed connection, respond quickly to PINGs, never cancel transfers, and stay online for weeks at a time.
Perhaps real copies of the songs are still out there, but you can't find them because the RIAA has worked out how to exploit the search system.
What you're describing is essentially chaffing and winnowing, first proposed by Ronald Rivest.
Freenet nodes publish their addresses through the DataSource field of DataReply messages. This doesn't allow the recipient of the message to work out who is sharing what, because the DataSource is reset with a low probability by each node the message passes through. But it does allow a passive "address-gathering" attack which will eventually allow you to identify all Freenet participants, or all participants in a particular jurisdiction (eg China, RoadRunner, UCLA).
1. Data should pass through the overlay network.
3. Performance should be reasonable.
It's hard to see how these requirements can be reconciled. Even if the sender and recipient are on average only 2 hops apart in the overlay network, the effective bandwidth of all nodes is halved. Even if the overlay network has "small world" characteristics and the shortest path can always be found, the best we can realistically hope for is that the number of hops will grow logarithmically with the number of nodes. For a network of 10,000 nodes (the predicted scaling limit of Gnutella), each message might make a dozen hops, so each node will only get to use 1/12 of its bandwidth for its own traffic (the rest will be used for forwarding other nodes' traffic). People are unlikely to use such a network unless they have a very good reason for needing anonymity.
For this reason I suspect that the future of anonymous networking does not lie in internet overlays, but in new networks that are potentially independent of the internet, even if some of their links are made across the internet for the time being.
Of course people might not be willing to openly sell counterfeit copies if there's an audit trail, but it will be possible for resellers to "fork" a legitimate artifact by selling multiple copies, each of which appear to be legitimate because it will have an audit trail leading back to the original seller. Unless every resale is somehow tied to the seller's legal identity, illegitimate copies will gradually "leak" into the legitimate market.
OK, I propose the 3PM format: The header is the same as an MP3 file. The ID3 tag is the same as an MP3 file. The audio data is byte-swapped, so the four bytes ABCD are stored DCBA. If the length of the audio data is not a multiple of four bytes, the last 1-3 bytes are left untouched. The extension can be .mp3 or .3pm, depending on how easy you want to make it for Sean to filter out byte-swapped files.
Perhaps US missiles could incorporate this technology to prevent them flying into Chinese embassies.
Dude, you have been reading too much popular science.
Many thanks for the link - I've emailed London's MEPs expressing my concern. Unfortunately I suspect the biggest difference it makes will be to the size of my 'Sent' folder. Ho hum.
It would also reduce our reliance on oil from Texas. Still wonder why it hasn't been done?
However the person charged with their murder was their school caretaker, not someone they met online.
I wonder if this is what's meant by 'progressive proximity search'? Maybe if it can't find anyone close to you then it gradually widens the search until it finds a mimimum number of people.
If credit cards are so bad that someone should be sued for creating them, why do you use them? Let me guess: because it's convenient? While it's certainly inconvenient to live without a credit card in the US, since they're often used as a form of ID, it really isn't difficult to avoid USING your credit card.
You're trying to shift the blame for your own laziness onto a company that offered to make your life easier, but actually made it more complicated. SURPRISE: Most of the things that companies claim will make your life simpler, actually make it more complicated. If you desire a simple life, it is occasionally necessary NOT TO USE ALL THE SERVICES OFFERED TO YOU BY CORPORATIONS. If you decide to use a service anyway, when you know from personal experience that it will complicate your life, you should not blame anyone but yourself.
The existence of the exploit means that '007 Agent Under Fire' is a tool to circumvent the XBox's DRM, and distributing it is illegal under the DMCA. ;-)
Hey, Finnish isn't that bad.
You believe it's your "right" to listen to a CD on your computer as well as on your CD player, even if that CD was designed to be compatible with your CD player but not with your computer? Do you also believe it's your right to be able to listen to that CD on a Minidisc player? On a turntable? By sticking it up a dog's arse? Of course not. The record company has no obligation to make their CDs compatible with your equipment. If you choose to buy them anyway, don't blame anyone else for violating your "rights".
(7) Don't use the Tube or take a bus
{8} Don't walk near shops, petrol stations or busy junctions
(9) Don't leave your house
(10) Close your curtains
(11) Enjoy your privacy! I hope it was worth it.