Your analysis is missing one component: download speeds aren't just about bandwidth, but also latency. P2P file distribution have an advantage for global distribution of large files: the optimization (peer selection) lets you download bits from somebody in your region. If you want to do that with a centralized approach, you need multiple datacenters in different parts of the world. Talk about expensive.
Since when was Avalanche "leaked" to the press? Please provide some kind of evidence. Any kind of evidence? I had read these Avalanche papers a couple of months back. They have been published for a while now.
Dvorak points to a blog post by an MVP, and quotes it as FUD against BitTorrent. Well, I read that post and it seems to be targetting spyware. It's not even saying that BitTorrent has a flaw or anything. It just happens that this spyware uses BitTorrent as a transfer mechanism... RTFA
So much dis-information it hurts. What I see is a lot of irrational paranoia (did someone even come up with a theory of Microsoft's motives?) and Slashdot FUD. All we have here is a researcher searching for ways to push the edge of technology. What if an MSR researcher invented a way to compress zip files into half of the size? Would everyone jump up and down with theories of Microsoft taking over the world?
Slashdotters, please read the articles, look for evidence and make your own minds up.
The difference is that systems can't be secured today because it requires too much configuration (ACLs) and ACLs are limited anyways. But capabilities allow for better security starting from the design. It's less in the hands of administrators and more in the hands of developpers. Agreed that it's not trivial for developpers to get right and it will require some training (the same way that programmers are trained to good design). It's lucky that it makes things easier for developpers by allowing for more focused security reviews.
Also it makes things less error-prone, by being secure by default (no authority is implicitly given to a new process unless some capabilities are explicitly given to it).
More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).
One thing about capability-based secure systems is that they allow for better security solutions to be designed. For example, you could build a a capability that would have read access to all the things you need backed up.
The current security model, based on the concept of principal and permissions/ACL, forces the trade-off between being able to do powerful things and raising the security risk.
The capability-based security model (see http://erights.org for more details) is a way to break this paradigm and allow for power AND safety (and usability, from the existing prototypes). Still lots of open issues, but seems like a very interesting direction for safer computing.
Although these menus do look weird at first, the idea seems interesting. Only some real life testing would tell if it's a good choice, but moving the menus is a good way to save some screen room. On the flip side, it's harder to "grab" the window to move it, but do people really do that a lot, now that tabbed browsing is going mainstream?
I think this is the best point in the thread: it really depends on Apple's intent. If they did that change to fix a bug or implement a feature, and it accidentally broken Real's files, that would be fine. But if they did it simply for that purpose, it's rather lame given their dominant position on the music/player market.
The problems lies in the ability for the "evil" window to access the popup from citibank just because it knows it's name. The browser/javascript API should be fixed/designed so that only the parent of a popup can access it.
Global variables aren't good for isolation. That's a pretty general security principle, which is pushed as far as it can in capability-secure systems for example, to ensure only the actors that need an authority can use it.
I doubt your Tivo was running for 3 years without a reboot. Tivo reboots after it updates itself. I'm not sure how frequently the reboot occurs, since it was always invisible to me (it's during the night). Also I did have some occasional freezes, but nothing too bad.
I see many comments about MS Passport not having succeeded and how that means MyUID or other similar systems are doomed.
Assuming the criteria for "success" is being used on many websites, three possible reasons why Passport didn't succeed (outside of MSN) that I can think of:
licensing cost (something like 10.000$ a year),
ambition of managing the user's data and all the privacy implications,
complexity of the system and the APIs.
I can't speak for MyUID, but systems like TypeKey take a different approach:
their target isn't necessarly commercial websites and they have a more open licensing (read "free beer") for those,
they avoid privacy issues by having a simpler info sharing model (they share the unique ID, don't share the email by default, and the rest of the optional info is considered public), and benefiting of not being Microsoft (which is monitored by regulation agencies),
their system is less sophisticated and is quite easy to implement/use (I just wrote a ASP.Net TypeKey authentication provider, Stuart Parmenter just wrote a "TypeKey" server,...).
Then there is the general question of central databases and security. Personally, I wouldn't mind having a unique ID for many site with rather low security requirements like Slashdot, Kuro5hin, Freshmeat, etc. (until we come up with a good distributed/federated authentication infrastructure).
At the same time, multipling these authentication services really only lowers their value.
"Conclusions
Put the computation near the data. The recurrent theme of this analysis is that "On Demand" computing is only economical for very CPU-intensive (100,000 instructions per byte or a CPU-day per gigabyte of network traffic) applications."
The article recommends that the patches be encrypted when being distributed, this doesn't make it any harder to reverse engineer them. Just install the patch on a box and do a before/after diff...
Altough a centralized auth system isn't ideal, it is still the best solution so far for this amount of users.
Security issues: how many security issues where found in windows or openssl, vs. how many in passport? Do you have any hard numbers?
Privacy issues: Regulation agencies are working closely with Passport to set a good industry standard. Can you clarify what privacy issues you were thinking of?
Let's see if SharedID or TypeKey manage to handle millions of user, for free, no licensing fee and with a good uptime (above 99.9).
Slashdot Mirror
Your analysis is missing one component: download speeds aren't just about bandwidth, but also latency.
P2P file distribution have an advantage for global distribution of large files: the optimization (peer selection) lets you download bits from somebody in your region.
If you want to do that with a centralized approach, you need multiple datacenters in different parts of the world. Talk about expensive.
BitTorrent supports webseeding. You only need a script file on your server (such as PHP). No need to build a whole module into your web server.
Check out http://www.blogtorrent.com/ and "torrent webseeding" on Google.
Can you point the location in that guy's papers where spyware and malware are discussed?
RTFP (paper) please. This research paper is simply about using some smart algorithms to improve file distribution in swarming P2P protocols.
Since when was Avalanche "leaked" to the press? Please provide some kind of evidence. Any kind of evidence?
I had read these Avalanche papers a couple of months back. They have been published for a while now.
Dvorak points to a blog post by an MVP, and quotes it as FUD against BitTorrent. Well, I read that post and it seems to be targetting spyware.
It's not even saying that BitTorrent has a flaw or anything. It just happens that this spyware uses BitTorrent as a transfer mechanism...
RTFA
So much dis-information it hurts. What I see is a lot of irrational paranoia (did someone even come up with a theory of Microsoft's motives?) and Slashdot FUD. All we have here is a researcher searching for ways to push the edge of technology.
What if an MSR researcher invented a way to compress zip files into half of the size? Would everyone jump up and down with theories of Microsoft taking over the world?
Slashdotters, please read the articles, look for evidence and make your own minds up.
Here is a Greasemonkey user script (and some more too) to remove that anti-feature:y .html
http://blog.monstuff.com/archives/cat_greasemonke
The difference is that systems can't be secured today because it requires too much configuration (ACLs) and ACLs are limited anyways. But capabilities allow for better security starting from the design. It's less in the hands of administrators and more in the hands of developpers.
Agreed that it's not trivial for developpers to get right and it will require some training (the same way that programmers are trained to good design). It's lucky that it makes things easier for developpers by allowing for more focused security reviews.
Also it makes things less error-prone, by being secure by default (no authority is implicitly given to a new process unless some capabilities are explicitly given to it).
More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).
One thing about capability-based secure systems is that they allow for better security solutions to be designed. For example, you could build a a capability that would have read access to all the things you need backed up.
The current security model, based on the concept of principal and permissions/ACL, forces the trade-off between being able to do powerful things and raising the security risk.
The capability-based security model (see http://erights.org for more details) is a way to break this paradigm and allow for power AND safety (and usability, from the existing prototypes). Still lots of open issues, but seems like a very interesting direction for safer computing.
Although these menus do look weird at first, the idea seems interesting. Only some real life testing would tell if it's a good choice, but moving the menus is a good way to save some screen room.
On the flip side, it's harder to "grab" the window to move it, but do people really do that a lot, now that tabbed browsing is going mainstream?
VoiP? Must be this new 'Phone' thing.
I think this is the best point in the thread: it really depends on Apple's intent.
If they did that change to fix a bug or implement a feature, and it accidentally broken Real's files, that would be fine. But if they did it simply for that purpose, it's rather lame given their dominant position on the music/player market.
The problems lies in the ability for the "evil" window to access the popup from citibank just because it knows it's name.
The browser/javascript API should be fixed/designed so that only the parent of a popup can access it.
Global variables aren't good for isolation. That's a pretty general security principle, which is pushed as far as it can in capability-secure systems for example, to ensure only the actors that need an authority can use it.
Sounds like LeanOnMe, a JXTA-powered backup system with encryption.
I doubt your Tivo was running for 3 years without a reboot.
Tivo reboots after it updates itself. I'm not sure how frequently the reboot occurs, since it was always invisible to me (it's during the night).
Also I did have some occasional freezes, but nothing too bad.
You still end up having one account for each website. Tell me how the browser helps you the day that you decide to change your password?
In comparison with keeping the same password forever, maybe a centralized authentication server isn't such an insecure solution after all...
I see many comments about MS Passport not having succeeded and how that means MyUID or other similar systems are doomed.
Assuming the criteria for "success" is being used on many websites, three possible reasons why Passport didn't succeed (outside of MSN) that I can think of:
I can't speak for MyUID, but systems like TypeKey take a different approach:
Then there is the general question of central databases and security. Personally, I wouldn't mind having a unique ID for many site with rather low security requirements like Slashdot, Kuro5hin, Freshmeat, etc. (until we come up with a good distributed/federated authentication infrastructure). At the same time, multipling these authentication services really only lowers their value.
Why not leave the sites online, but with some authentication turned on (Basic HTTP auth)?
This way online the blog authors could access the system and get their data out. The load on the server should stay reasonable.
Distributed Computing Economics.
"Conclusions Put the computation near the data. The recurrent theme of this analysis is that "On Demand" computing is only economical for very CPU-intensive (100,000 instructions per byte or a CPU-day per gigabyte of network traffic) applications."
I can't access the original article. Apparently they switched it to Premium access only...
Actually this is still far from clear. The latest I read was that SP2 will be exactly like SP1 in regards to pirates.
It seems there has been conflicts between various sources of information. I'd wait til SP2 is out to be sure on that one...
General-Purpose Computation Using Graphics Hardware. Anyone interested in this topic should check that site out.
Some comments mention that errors are unacceptable.
I'm surprised nobody mentioned error correction to fight this random bit flipping...
Am I missing something?
What's the probability of a random bit being inserted? Are most bits inserted correctly or are most bits random?
The article recommends that the patches be encrypted when being distributed, this doesn't make it any harder to reverse engineer them.
Just install the patch on a box and do a before/after diff...
Altough a centralized auth system isn't ideal, it is still the best solution so far for this amount of users.
Security issues: how many security issues where found in windows or openssl, vs. how many in passport? Do you have any hard numbers?
Privacy issues: Regulation agencies are working closely with Passport to set a good industry standard. Can you clarify what privacy issues you were thinking of?
Let's see if SharedID or TypeKey manage to handle millions of user, for free, no licensing fee and with a good uptime (above 99.9).