Re:Slightly OT, does anyone use iPod with Linux?
on
No WMA for HP iPod
·
· Score: 2, Informative
USB Mass Storage. The standard protocol for USB harddisks.
The grandparent is half wrong about the iPod - it does work as standard mass storage (at least over firewire, less sure about USB 2.0 on the newer models), but to add music to it needs to be in a special directory and the song info needs to be added to a metadata file. The special directory is annoying (because it mixes the files, so you need to use a program to copy from the iPod and get album directories back), but the metadata file makes sense since searching the entire FS and reading id3 tags sucks.
How much better would not CD-MP3 players be if there were a standard index file that one placed in the root directory on the CD, allowing interfaces like the iPods?
Re:Slightly OT, does anyone use iPod with Linux?
on
No WMA for HP iPod
·
· Score: 4, Informative
I am only using MP3 files, though I understand that gtkpod has some support AAC files as well:
NEW FEATURE: import of AAC files (.m4a) supported, provided the
mp4v2 library from the mpeg4ip project
(mpeg4ip.sourceforge.net) is available during the compilation of
gtkpod. Writing tags to AAC files is also supported..m4p files
can also be imported, but they are not played by the iPod..m4a
files work fine.
BTW, never mind what I said about not getting hotplug to work, I just checked it now and got it working fine using the instructions in the gtkpod README file.
Re:Slightly OT, does anyone use iPod with Linux?
on
No WMA for HP iPod
·
· Score: 5, Informative
I use my iPod with Linux, and have for over a year. In fact, it has never been used with any other operating system, and I have never used iTunes or Musicmatch (or whatever the windows thing is called) so I can't really compare.
Linux firewire support is experimental in 2.4, so getting it working requires your basic linux skills, but I haven't had any real problems. Most firewire cards and MBs use a standard driver, so it is just to compile the modules (and firewire harddisk support) and run. I have never gotten automatic hotplug support working here, but scanning the scsi bus manually isn't that big a deal (and others apparently have). With kernels before 2.4.20 I had a recurring hard lockup while transfering, which was annoying, but that is gone now. And I don't think the drivers are completely optimal so the transfers are slower then advertised (but still many times faster than USB).
I don't know if it is better with the new iPods that support USB2.0, since I have an old firewire only model. And I haven't tried the 2.6 kernel which is supposed to have better firewire support.
The best software for adding and removing music that I have found is gtkpod. It is a nice, easy to use, GUI program that allows you to select music, construct playlists, etc. The page also contains information for getting all the other stuff working.
No they don't, and yes they can. That they would have to release their entire program is mostly Microsoft FUD. It is really just like any other copyright violation.
.nu was popular in Sweden because the.se TLD used to be very strictly controlled - only company names of limited corporations were allowed. So it was used a lot for product pages, like TryRadiumDentalFloss.now or VisitSvalbard.now etc.
However, the limitations on.se have now been dropped, and the use of.nu is more of a novelty nowadays.
how many folks can you find who are *experts* good with both SQL & Java? (BTW,I don't mean that they can write simple joins, group bys and unions. I mean good enough to understand access paths and parallelism choices). Of the 100+ java developers I've worked with over the last four or so years I've only met *1* who would meet that critieria.
Database developers like to go on and on about how difficult it is, and how "non-experts" can't possibly learn to develop good databases. So we'll buy that: you can't find java developers who also have the magical unattainable quality of being able to handle a database.
But turn it around instead. How come your database "*experts*" can't learn java? I have java down as well as anyone, and I would claim that anybody with half a brain can become an expert at java development in a few months. Anybody who has experience with imperitive programming can learn it in a few weeks. For people who know OOP it is a matter of days.
Why NVidia doesnt just come clean and release the specs for the chips i'll never know, since its only going to get them bad press, I for one have spent hours of frustration on these problems.
Given their track record, you probably could have expected this from Nvidia before you purchased the chip.
Of course it isn't like Intel are any better with Centrino...
I have a distinct feeling that Linux on desktop computers is not featured in any of the chip makers future plans. This is hardly surprising, as their future is based around "Trusted Computing", and free software isn't invited to that particular "party" (read prison)...
Read Linus reply about the meaning of "use" in TFA. To programmers, simply using the class may feel like just using the software, but from the legal perspective use means only running the program. Using a class in your code is linking to that class in some sense.
What part of this contradicts my statement that the GPL "derives it's authority from copyright law"?
If I download and run application X under the GPL, then I need to enter exactly zero contracts with anybody. If I want to redistribute X, or a derived version X1, then I need to enter a contract under the GPL, but not sooner.
Say I download and run application X, and then write and distribute application Y. The only way that I would need to get into a contract (the GPL) with the author of X in order to distribute Y is if Y is in some way a derived work of X. The GPL is not a EULA, it cannot add any restrictions on my behavior until such time as I do something with program X that normal copyright law does not allow by default.
This is exactly the situation with kernel modules. If kernel modules are not a derived work of the Linux kernel under copyright law, then the it does not matter what the GPL says. If kernel modules are considered original works under the law, then they can be distributed in exactly whatever form the author chooses, regardless of what the GPL says. Microsoft likes to talk about the "viral" GPL. But the GPL can never be more "viral" then copyright law is: as long as something is an original work, the author can never be compelled to GPL it.
This whole question is simply one of legal interpretation. What is a derived work under the law and what is an original work? If something is a derivative of GPLed code like the kernel, then the GPL is required, if it isn't, then there are no licensing requirements. At least Linus seems to understand this much.
The real question is if the stub is a derivative work of the kernel. That is exactly the same question as wether a directly linkable binary module is a derivative work of the kernel. According to the GPL it is, according to standard law it is not.
The GPL derives it's authority only from copyright law. If copyright law does not recognize the stub as a derivative work, then nothing in the GPL can force it to be, and there are no restrictions under what license it can be distributed.
The problem seems to be that nobody can say for sure whether such a stub is a derivative work under current copyright laws or not.
But it isn't like somebody is sitting around considering whether they should be allowed or not. The kernel is under the GPL, with no expections, and unlike the GNU software where the FSF owns the copyright of the entire thing, everybody who submits to the kernel has kept copyright for their own patches. The linux kernel has thousands of owners, and it would be litterally impossible to change the license now.
So all we can do is try to decipher the meaning of the license that the kernel is already under. Whether that license permits binary modules or not doesn't depend on whether we want it to, but whether they are derived works in the legal sense.
Personally I have always found the argument that linking makes something a derived work very questionable, especially for things like java where linked class files contain little other than the class and method names that they link to. If a java class that calls another is a derived work, then that is yet another dumb copyright law. However, I think that Valdis Kletnieks point about inlining very persuasive. I have a very hard time seeing how a binary module that contains snippets of object code directly compiled from GPLed methods in the kernel (because they were inlined) could possibly be anything but unauthorized distribution.
So add a database file somewhere on the disk, like the iPod does. If the file is in a simple transparent format, perhaps XML, then it will be easy enough to reverse engineer and implement for any platform.
It is a shame nobody standardized such a file for MP3 CD disks.
There is no excuse for using a non-standard USB protocol.
I remember watching the 2000 presidential debacle with some amusement, and most interesting of all was the partisan nature of EVERY aspect. It seemed that representatives from both parties were needed not only for political comments, but for everything from counting votes to doing statistical analysis. In the end, even the supreme court decide along party lines.
I mentioned how absurd this is to my father, who is a civil servant here (Sweden) and a historian. His answer was that the concept of a politically indepedent civil servant in Europe is actually a remnant of the monarchic roots: civil servants in European monarchies were traditionally loyal to the king, not to the houses of parlament. Even though the monarchy is reduced to a symbolic role (more so here than in the UK), the tradition of indepedence from the political process lives on.
America simply does not have this background: everything in American government is fundamentally political, so the concept of an _independent_ electoral commission is impossible.
You are misunderstanding the way freenet (or at least the ARK thing) works. ARKs can't be fed to a node to replace other nodes in it's routing table. ARKs are simply a way of updating the information about nodes that are already in the routing table.
If a node starts sending you requests, and those requests are successfully fullfilled, then you can set "DataSource" value on the reply to yourself or one of your other compromised nodes - this is the value that is actually added to the routing table. We called this attack a "cancer", for obvious reasons. Scott Miller and I did a presentation at one of the O'Reilly conferences where we, among other things, showed that with infinite resources a cancer could basically swallow the entire Freenet network.
I had not thought about the possibility of trying to target a cancer at isolating a particular node. My intuition tells me that it would not work: every time the node routes to you, it adds a reference to another one of your compromised nodes, but every time it routes to another node (and that is after all 49 times more common to start off with) it should be (*) adding a node that is not compromised by you. Calculating the results precisely should not be that complicated a problem.
(*) The way things worked originally, the only limit on the size of the routing table was the number of references, which could all have been to a single node or each to a different one. When Tavin rewrote the routing table in late 2001 (IIRC) he changed this to N nodes which could have R references each (typically 50 and 100 or something). This was done for technical reasons, as when we implemented the PKI each node took up a substantial amount of memory (2-3 KB maybe), while references where still only 23 bytes. I have since then come to decide that this was a mistake for several reasons, but it had not struck me that this could facilitate the kind of attack you describe: the attacker gives himself an advantage, because each response from him contains a reference to an entirely new node, while a lot of the references received from uncompromised will be to nodes that are already in the routing table.
Still, I think the attack, if possible, would be a lot harder than you describe.
I am tired of typing into a textbox! If you want to discuss this further, then I'm in #freenet on freenode (old OpenProjects) or can be emailed with this handle at freenetproject.org. I don't read the fp.org mailing lists anymore, though.
I don't think so. How could Freenet do proper onion routing when you can not determine what route it will take?
There was a negative missing there. Freenet does NOT do onion routing. Sorry (though I think it can be seen from the context what I intended.)
Actually, the defense is both good and bad - the problem lies in the HTL - Hops To Live. As it is (or at least was, when I tried to convince them it was a bad idea) the maximum HTL is 25 (in node, no matter what the program requests). That is, if you request/insert something with HTL 25, it's *your* request/insert, noone else's.
There is an added random factor to it, IIRC, but it isn't nearly high enough. In retrospect, I think that we should not have used HTL at all, but instead had a random probability of the request terminating at each node it reaches. The blame for it not being done this way lies mostly with me - I had an idea when we implemented the basic protocol that it should be very robust, thus every node keeps track of every request and times it out as soon as possible, and then something like HTL was needed.
Having seen how things turned out, if I was to go back today, I would made the protocol as lightweight, "fire and forget", and memoryless as possible instead. The usage pattern I imagined where users made a single request that had to succeed or fail correctly became "spam the network and hope for something" and the protocol was never designed for that.
It should be noted that the anonymity aspects of freenet take a hit from the routing problems in this case: Overload and lousy routing caused people to pump up the HTL, which caused us to limit it strictly to avoid and evil cycle (that wasn't avoided), which is why most people start with the highest permitted value today.
Also here, Freenet is pretty dumb in that it has a static 50 node limit by default. Once you've got 50 compromised nodes in contact with the target node, it's isolated from the network and you can see all requests/inserts it does. With at least some random factor, you would provide some uncertainty - do we control all nodes now, or are there still more? Can we *prove* these came from him?
I would say that the benefit of a random factor is dubious here. If you have the capacity to compromise all the nodes in the routing table, then you probably have the capacity to scan their traffic to see if they have other peers (I mean, how else did you find all their peers?)
They could not do a simple port scan, as you need the node's public key to get a response. However, you can listen on the network for those. Due to the state of the Freenet network, you need a certain inflow of new nodes, and so you also need to announce your node on the network. If you had a set of stable 24/7 static ip nodes to connect to, you wouldn't need to. However, since nearly all residential connections are semi-stable (cable/dsl), it is as it must be in order to keep the node functional.
"Silent Bob" as we called the idea of not responding until the key is seen, is in the protocol, but it is not, IIRC, the current default behavior of the node (for perfromance reasons). I don't agree that "a set of stable 24/7 static ip nodes" would be a good thing. The more static the network is, the more vulnerable.
The node probing defense also makes it impossible to know without actually securing the node - the node will sometimes pass the request, regardless of whether it has the data or not.
There is no defense against timing analysis of these responses. If the response is instantaneous, then you can be pretty sure the node contained the data before you probed it.
There is no defense against timing analysis of these responses. If the response is instantaneous, then you can be pretty sure the node contained the data before you probed it.
I think my analysis is almost the opposite. I wouldn't worry much about requesting or inserting data (if the network was working, I don't know w
What can play the encrypted AAC from iTMS? Does it require special licensing, secuirty, or software to play them?
It requires DRM. Except it isn't DRM, because it comes from Steve - so it is really GoodRM, or NiceRM, or TheLeaderHasToldUsToSwallowRM. Either way, we really like it! We never really wanted to control the data in our own computers ourselves anyways, we think it is good that Steve is in charge now.
Next week, we are installing a door to our house that will only let us out when it decides to! It is called a FairDoor! We are doing this because Steve said so, and it is made of really cool brushed metal and opens with a single click when going outside is permitted. This doesn't really make our houses into prisons, because we can burn part of the wall, and then convert it back into a door if we want (and anyways, if we do want to go outside when the don't let us, it is probably because we want to break some law. FairDoor keeps us honest)!
USB Mass Storage. The standard protocol for USB harddisks.
The grandparent is half wrong about the iPod - it does work as standard mass storage (at least over firewire, less sure about USB 2.0 on the newer models), but to add music to it needs to be in a special directory and the song info needs to be added to a metadata file. The special directory is annoying (because it mixes the files, so you need to use a program to copy from the iPod and get album directories back), but the metadata file makes sense since searching the entire FS and reading id3 tags sucks.
How much better would not CD-MP3 players be if there were a standard index file that one placed in the root directory on the CD, allowing interfaces like the iPods?
I am only using MP3 files, though I understand that gtkpod has some support AAC files as well:
.m4p files .m4a
NEW FEATURE: import of AAC files (.m4a) supported, provided the
mp4v2 library from the mpeg4ip project
(mpeg4ip.sourceforge.net) is available during the compilation of
gtkpod. Writing tags to AAC files is also supported.
can also be imported, but they are not played by the iPod.
files work fine.
BTW, never mind what I said about not getting hotplug to work, I just checked it now and got it working fine using the instructions in the gtkpod README file.
I use my iPod with Linux, and have for over a year. In fact, it has never been used with any other operating system, and I have never used iTunes or Musicmatch (or whatever the windows thing is called) so I can't really compare.
Linux firewire support is experimental in 2.4, so getting it working requires your basic linux skills, but I haven't had any real problems. Most firewire cards and MBs use a standard driver, so it is just to compile the modules (and firewire harddisk support) and run. I have never gotten automatic hotplug support working here, but scanning the scsi bus manually isn't that big a deal (and others apparently have). With kernels before 2.4.20 I had a recurring hard lockup while transfering, which was annoying, but that is gone now. And I don't think the drivers are completely optimal so the transfers are slower then advertised (but still many times faster than USB).
I don't know if it is better with the new iPods that support USB2.0, since I have an old firewire only model. And I haven't tried the 2.6 kernel which is supposed to have better firewire support.
The best software for adding and removing music that I have found is gtkpod. It is a nice, easy to use, GUI program that allows you to select music, construct playlists, etc. The page also contains information for getting all the other stuff working.
I am happy with my iPod on Linux.
No they don't, and yes they can. That they would have to release their entire program is mostly Microsoft FUD. It is really just like any other copyright violation.
Groklaw has a good article on the subject.
.nu was popular in Sweden because the .se TLD used to be very strictly controlled - only company names of limited corporations were allowed. So it was used a lot for product pages, like TryRadiumDentalFloss.now or VisitSvalbard.now etc.
.se have now been dropped, and the use of .nu is more of a novelty nowadays.
However, the limitations on
American dialup is where it has always been, you choose between giving your money to:
The Church of Scientology (Earthlink)
Time Warner and RIAA/MPAA (AOL)
Bill Gates and Palladium (Microsoft)
What to do... What to do...
how many folks can you find who are *experts* good with both SQL & Java? (BTW,I don't mean that they can write simple joins, group bys and unions. I mean good enough to understand access paths and parallelism choices). Of the 100+ java developers I've worked with over the last four or so years I've only met *1* who would meet that critieria.
Database developers like to go on and on about how difficult it is, and how "non-experts" can't possibly learn to develop good databases. So we'll buy that: you can't find java developers who also have the magical unattainable quality of being able to handle a database.
But turn it around instead. How come your database "*experts*" can't learn java? I have java down as well as anyone, and I would claim that anybody with half a brain can become an expert at java development in a few months. Anybody who has experience with imperitive programming can learn it in a few weeks. For people who know OOP it is a matter of days.
God bless you, everyone...
Or something...
Why would you be interested in emulating the development model if the resulting product isn't good?
Imitation is flattery, regardless of how MS would spin it.
Why NVidia doesnt just come clean and release the specs for the chips i'll never know, since its only going to get them bad press, I for one have spent hours of frustration on these problems.
Given their track record, you probably could have expected this from Nvidia before you purchased the chip.
Of course it isn't like Intel are any better with Centrino...
I have a distinct feeling that Linux on desktop computers is not featured in any of the chip makers future plans. This is hardly surprising, as their future is based around "Trusted Computing", and free software isn't invited to that particular "party" (read prison)...
If I had remembered the "but" I would have been +5 funny. Now I'm going to have two -1 offtopic. :-(
He would, American forces arrested him south of Tikrit yesterday...
A lot of Liberal whining about how evil businessmen... from a Liberal to criticize their fellow Communists
You keep using that word. I do not think it means what you think it means...
Why spend all that money on a high end processor when you are spending $200 on a TV card that does the intense computing.
Wouldn't one of the cheap VIA processors that can run fanless be better?
Who needs the NYT when we have the esteemed publication of the Reverend Sun Moon!
Of course, how many of you knew this.
Read Linus reply about the meaning of "use" in TFA. To programmers, simply using the class may feel like just using the software, but from the legal perspective use means only running the program. Using a class in your code is linking to that class in some sense.
What part of this contradicts my statement that the GPL "derives it's authority from copyright law"?
If I download and run application X under the GPL, then I need to enter exactly zero contracts with anybody. If I want to redistribute X, or a derived version X1, then I need to enter a contract under the GPL, but not sooner.
Say I download and run application X, and then write and distribute application Y. The only way that I would need to get into a contract (the GPL) with the author of X in order to distribute Y is if Y is in some way a derived work of X. The GPL is not a EULA, it cannot add any restrictions on my behavior until such time as I do something with program X that normal copyright law does not allow by default.
This is exactly the situation with kernel modules. If kernel modules are not a derived work of the Linux kernel under copyright law, then the it does not matter what the GPL says. If kernel modules are considered original works under the law, then they can be distributed in exactly whatever form the author chooses, regardless of what the GPL says. Microsoft likes to talk about the "viral" GPL. But the GPL can never be more "viral" then copyright law is: as long as something is an original work, the author can never be compelled to GPL it.
This whole question is simply one of legal interpretation. What is a derived work under the law and what is an original work? If something is a derivative of GPLed code like the kernel, then the GPL is required, if it isn't, then there are no licensing requirements. At least Linus seems to understand this much.
The real question is if the stub is a derivative work of the kernel. That is exactly the same question as wether a directly linkable binary module is a derivative work of the kernel. According to the GPL it is, according to standard law it is not.
The GPL derives it's authority only from copyright law. If copyright law does not recognize the stub as a derivative work, then nothing in the GPL can force it to be, and there are no restrictions under what license it can be distributed.
The problem seems to be that nobody can say for sure whether such a stub is a derivative work under current copyright laws or not.
But it isn't like somebody is sitting around considering whether they should be allowed or not. The kernel is under the GPL, with no expections, and unlike the GNU software where the FSF owns the copyright of the entire thing, everybody who submits to the kernel has kept copyright for their own patches. The linux kernel has thousands of owners, and it would be litterally impossible to change the license now.
So all we can do is try to decipher the meaning of the license that the kernel is already under. Whether that license permits binary modules or not doesn't depend on whether we want it to, but whether they are derived works in the legal sense.
Personally I have always found the argument that linking makes something a derived work very questionable, especially for things like java where linked class files contain little other than the class and method names that they link to. If a java class that calls another is a derived work, then that is yet another dumb copyright law. However, I think that Valdis Kletnieks point about inlining very persuasive. I have a very hard time seeing how a binary module that contains snippets of object code directly compiled from GPLed methods in the kernel (because they were inlined) could possibly be anything but unauthorized distribution.
So add a database file somewhere on the disk, like the iPod does. If the file is in a simple transparent format, perhaps XML, then it will be easy enough to reverse engineer and implement for any platform.
It is a shame nobody standardized such a file for MP3 CD disks.
There is no excuse for using a non-standard USB protocol.
I remember watching the 2000 presidential debacle with some amusement, and most interesting of all was the partisan nature of EVERY aspect. It seemed that representatives from both parties were needed not only for political comments, but for everything from counting votes to doing statistical analysis. In the end, even the supreme court decide along party lines.
I mentioned how absurd this is to my father, who is a civil servant here (Sweden) and a historian. His answer was that the concept of a politically indepedent civil servant in Europe is actually a remnant of the monarchic roots: civil servants in European monarchies were traditionally loyal to the king, not to the houses of parlament. Even though the monarchy is reduced to a symbolic role (more so here than in the UK), the tradition of indepedence from the political process lives on.
America simply does not have this background: everything in American government is fundamentally political, so the concept of an _independent_ electoral commission is impossible.
You are misunderstanding the way freenet (or at least the ARK thing) works. ARKs can't be fed to a node to replace other nodes in it's routing table. ARKs are simply a way of updating the information about nodes that are already in the routing table.
If a node starts sending you requests, and those requests are successfully fullfilled, then you can set "DataSource" value on the reply to yourself or one of your other compromised nodes - this is the value that is actually added to the routing table. We called this attack a "cancer", for obvious reasons. Scott Miller and I did a presentation at one of the O'Reilly conferences where we, among other things, showed that with infinite resources a cancer could basically swallow the entire Freenet network.
I had not thought about the possibility of trying to target a cancer at isolating a particular node. My intuition tells me that it would not work: every time the node routes to you, it adds a reference to another one of your compromised nodes, but every time it routes to another node (and that is after all 49 times more common to start off with) it should be (*) adding a node that is not compromised by you. Calculating the results precisely should not be that complicated a problem.
(*) The way things worked originally, the only limit on the size of the routing table was the number of references, which could all have been to a single node or each to a different one. When Tavin rewrote the routing table in late 2001 (IIRC) he changed this to N nodes which could have R references each (typically 50 and 100 or something). This was done for technical reasons, as when we implemented the PKI each node took up a substantial amount of memory (2-3 KB maybe), while references where still only 23 bytes. I have since then come to decide that this was a mistake for several reasons, but it had not struck me that this could facilitate the kind of attack you describe: the attacker gives himself an advantage, because each response from him contains a reference to an entirely new node, while a lot of the references received from uncompromised will be to nodes that are already in the routing table.
Still, I think the attack, if possible, would be a lot harder than you describe.
I am tired of typing into a textbox! If you want to discuss this further, then I'm in #freenet on freenode (old OpenProjects) or can be emailed with this handle at freenetproject.org. I don't read the fp.org mailing lists anymore, though.
That has nothing to do with the DMCA. If people want to make compatible tools, then they have to license the technology, not reverse engineer it.
I hope you aren't posting that from an IBM compatible PC. Those dirty thieving bastards at Compaq should just have licensed it from IBM!!!
Thank God that the "DMCA is a Good Thing". Keeps us from having horrible things like competition occuring in the future!
I don't think so. How could Freenet do proper onion routing when you can not determine what route it will take?
There was a negative missing there. Freenet does NOT do onion routing. Sorry (though I think it can be seen from the context what I intended.)
Actually, the defense is both good and bad - the problem lies in the HTL - Hops To Live. As it is (or at least was, when I tried to convince them it was a bad idea) the maximum HTL is 25 (in node, no matter what the program requests). That is, if you request/insert something with HTL 25, it's *your* request/insert, noone else's.
There is an added random factor to it, IIRC, but it isn't nearly high enough. In retrospect, I think that we should not have used HTL at all, but instead had a random probability of the request terminating at each node it reaches. The blame for it not being done this way lies mostly with me - I had an idea when we implemented the basic protocol that it should be very robust, thus every node keeps track of every request and times it out as soon as possible, and then something like HTL was needed.
Having seen how things turned out, if I was to go back today, I would made the protocol as lightweight, "fire and forget", and memoryless as possible instead. The usage pattern I imagined where users made a single request that had to succeed or fail correctly became "spam the network and hope for something" and the protocol was never designed for that.
It should be noted that the anonymity aspects of freenet take a hit from the routing problems in this case: Overload and lousy routing caused people to pump up the HTL, which caused us to limit it strictly to avoid and evil cycle (that wasn't avoided), which is why most people start with the highest permitted value today.
Also here, Freenet is pretty dumb in that it has a static 50 node limit by default. Once you've got 50 compromised nodes in contact with the target node, it's isolated from the network and you can see all requests/inserts it does. With at least some random factor, you would provide some uncertainty - do we control all nodes now, or are there still more? Can we *prove* these came from him?
I would say that the benefit of a random factor is dubious here. If you have the capacity to compromise all the nodes in the routing table, then you probably have the capacity to scan their traffic to see if they have other peers (I mean, how else did you find all their peers?)
They could not do a simple port scan, as you need the node's public key to get a response. However, you can listen on the network for those. Due to the state of the Freenet network, you need a certain inflow of new nodes, and so you also need to announce your node on the network. If you had a set of stable 24/7 static ip nodes to connect to, you wouldn't need to. However, since nearly all residential connections are semi-stable (cable/dsl), it is as it must be in order to keep the node functional.
"Silent Bob" as we called the idea of not responding until the key is seen, is in the protocol, but it is not, IIRC, the current default behavior of the node (for perfromance reasons). I don't agree that "a set of stable 24/7 static ip nodes" would be a good thing. The more static the network is, the more vulnerable.
The node probing defense also makes it impossible to know without actually securing the node - the node will sometimes pass the request, regardless of whether it has the data or not.
There is no defense against timing analysis of these responses. If the response is instantaneous, then you can be pretty sure the node contained the data before you probed it.
There is no defense against timing analysis of these responses. If the response is instantaneous, then you can be pretty sure the node contained the data before you probed it.
I think my analysis is almost the opposite. I wouldn't worry much about requesting or inserting data (if the network was working, I don't know w
What can play the encrypted AAC from iTMS? Does it require special licensing, secuirty, or software to play them?
It requires DRM. Except it isn't DRM, because it comes from Steve - so it is really GoodRM, or NiceRM, or TheLeaderHasToldUsToSwallowRM. Either way, we really like it! We never really wanted to control the data in our own computers ourselves anyways, we think it is good that Steve is in charge now.
Next week, we are installing a door to our house that will only let us out when it decides to! It is called a FairDoor! We are doing this because Steve said so, and it is made of really cool brushed metal and opens with a single click when going outside is permitted. This doesn't really make our houses into prisons, because we can burn part of the wall, and then convert it back into a door if we want (and anyways, if we do want to go outside when the don't let us, it is probably because we want to break some law. FairDoor keeps us honest)!
We love the Steaver!