If someone uses your open access point for nefarious means, you have a defence -- "But anyone could have done that".
If someone uses your 'secured' access point for nefarious means, your defence requires a jury to understand the ease with which (say) WEP can be cracked.
And as someone who has no intention to use my network for child pornography, phishing, launching DDoS attacks, or violating copyright laws, this is entirely meaningless. The likelihood of spammers and others using my WiFi connection, should I leave it unsecured in this densely-populated and highly technical area, really is not negligible -- and in any event is infinitely greater than the probability of me engaging in such incriminating activities myself, which is identically zero.
Seriously, I get the whole plausible deniability / civil disobedience argument, but the truth is that the majority of the things one might get in trouble for on the Internet are illegal for a reason. Seriously, has it become passé to admit that you have no business trying (for example) to crack someone's web server in the first place?
These open WiFi thought experiments seem to neglect the fact that the only sure way to stay out of such trouble is to not break the law in the first place, and then to secure your wireless access point so that nobody else can do so using your Internet connection, either.
Go and find such music for yourself, out of RIAA's way.
I specifically mentioned Arcade Fire, which is on an independent label. Offhand it seems that indie rock/pop bands are just as likely to engage in this "loudness warfare" as their big-label counterparts. It's less prominent with jazz music, fortunately (indie or otherwise), and classical music is of course safe from this treatment.
Oh, and finally, I don't get what you mean by "to normalize the volume levels of CDs and other digital media". There's something that we musician or audio engineers call "normalizing" but it has nothing to see with your interpretation, so I don't see what you're speaking about, honestly. Would you force anyone to do something against their will, I really don't get what you wish here.
What I'm suggesting is a standardized RMS level for CD audio. For instance, the Dolby Digital standard specifies a reference level of -20 dBfs (RMS). You can call it forcing engineers to do something "against their will" if you want, but I think that this sort of thing really does belong in the standard, and apparently I'm hardly the only one who thinks so. We've certainly seen the ugly consequences of not including it in the standard...
Let the good music not use global compression, and the bad music use it. That's life you know. If some disc is primarily made to be listened at the same time in clubs, bars or public transport, compression is necessary and loudness war a mere corollary.
Audio CDs are first and foremost for individual customers and for airplay. The present overcompression fad has nothing to do with bars and public transport, it has to do with making your song sound louder than the ones that play before and after it on the radio -- or on the sampler at the music store, or in iTMS, or wherever else a potential customer might hear it. (And for the kind of compression actually required in bars and the like, a decent receiver can do that for you, or anybody with a copy of Audacity could create a specially compressed version of the album on behalf of the bar or the label.)
Let the good music not use global compression, and the bad music use it. That's life you know.
The problem is that, in the real world, quite a lot of the good music does get overcompressed for the digital master. And that's why I often buy vinyl instead, even given the medium's inherent disadvantages.
One thing records do have going for them is that they tend to be mastered, counterintuitively, with a wider dynamic range than contemporary CDs. Of course, this is a product of human decisions, not the media
That's it exactly. A hot CD doesn't do justice to bands like Arcade Fire, so I'm willing to go out of my way to get the vinyl versions of certain albums even if it means I now have to worry about things like dust and needle wear. I'd prefer that the studios just digitally master these things correctly in the first place, but that's not going to happen as long as the engineers feel compelled to make their songs sound the "loudest" on the radio; and that won't stop until we can agree on a way to normalize the volume levels of CDs and other digital media.
Right up to the moment they use an undelete tool on your laptop and find the formerly uninstalled encryption program on your hard drive....
No, you're missing the point. TrueCrypt can provide plausible deniability as to the existence of an encrypted volume even if it's known that you're using TrueCrypt.
Re:The best tools stay out of the way...
on
Goodbye Cruel Word
·
· Score: 1
Well, I started using Pages back in February of 2005, so I guess Microsoft had something to emulate for at least a couple of years.
Fortunately they've so far refrained from "emulating" Pages's lack of support for bibliographies and equations.
How would that help? They wouldn't even troubleshoot on a system like Linux.
That's sort of the point, in a way. The more people use FOSS operating systems, the more blindingly obvious it becomes to the media distribution companies that insisting their wares be copy-protected down to levels as absurd as restricted memory and hardware access -- a scheme which the FOSS systems will not choose to enforce -- is, from a market perspective, a losing proposition.
At that point you can't even call it a website any more; it's just a graphical.NET application that happens to be delivered over HTTP.
And yes, the same is absolutely true for pure-Flash websites, too. But this is made slightly less onerous because Adobe provides versions of the Flash plugin for Linux and OS X that are ostensibly on par with the Windows version, and Adobe doesn't lock you into a single platform for developing Flash apps -- unlike Microsoft, Adobe's end game is not to create a sea of de-facto "standard" applications for which the company's own operating system is the best, or only, choice.
To the best of my knowledge, Firefox typically does not leak memory, at least in the conventional sense that references to memory are erroneously discarded and unused allocated memory cannot be freed. Instead, the actual heart of the issue is supposedly memory fragmentation:
As the linked article suggests, memory fragmentation can be reduced by replacing heap allocations with stack variables, where possible, in hotspots such as the JavaScript engine. As for the heap allocations that cannot be dealt away with in this manner, effort can be made to group them together such that they are less likely to cause fragmentation.
I think you're entirely missing the point here. Sure we've always been free to dual-license things, but many people just aren't good at writing copyright notices and the like. This essentially provides content providers and potential licensers with a consistent user interface within which to operate.
Imagine that a publisher sees a really insightful code example in a blog entry on Erlang, which he thinks would make an excellent addition to an upcoming book. But the blog's author hasn't made clear whether this work can somehow be licensed for commercial use; or even if he has, the publisher might be having a hard time parsing the author's legalese. The publisher very well might just give up on it rather than go through the effort of contacting and negotiating with the author, and in the end both the publisher and the author lose out. On the other hand, if the author can just put a Creative Commons CC+ button on the page, the publisher can see it immediately and think: "I've seen this before and I know what it means. This work can be licensed, I can click here to find out what it will cost, etc."
This protocol continues Creative Commons' legacy of making public licensing accessible to the common man. And I think it's an excellent idea.
You do realize that English is a living language, and that a word's meaning is ultimately a function of its popular usage:
ag-nos-tic
2. Doubtful or noncommittal: "Though I am agnostic on what terms to use, I have no doubt that human infants come with an enormous 'acquisitiveness' for discovering patterns" (William H. Calvin).
-- The American Heritage Dictionary
The presentation itself (OGG Theora video available here) included an interesting quote from Tim Sweeney, creator of the Unreal Engine: "Shared state concurrency is hopelessly intractable."
The point expounded upon in the presentation is that when you have thousands of mutable objects, say in a video game, that are updated many times per second, and each of which touches 5-10 other objects, manual synchronization is hopelessly useless. And if Tim Sweeney thinks it's an intractable problem, what hope is there for us mere mortals?
The rest of this presentation served as an introduction to the Erlang model of concurrency, wherein lightweight threads have no shared state between them. Rather, thread communication is performed by an asynchronous, nothing-shared message passing system. Erlang was created by Ericsson and has been used to create a variety of highly scalable industrial applications, as well as more familiar programs such as the ejabberd Jabber daemon.
This type of concurrency really looks to be the way forward to efficient utilization of multi-core systems, and I encourage everyone to at least play with Erlang a little to gain some perspective on this style of programming.
For a stylish introduction to the language from our Swedish friends, be sure to check out Erlang: The Movie.
A possible "good" use for it might be at street crossings to warn pedestrians of changes in the traffic lights.
That would be amazing. These days the visually impaired rely on somewhat ambiguous and rather quiet "buzzers" to alert them to the changing states of crosswalks. These buzzers aren't always installed, either, partially because of their limitations. Imagine if the crosswalk could very audibly tell pedestrians when they have the right-of-way, without disturbing others in nearby businesses and apartments?
Now that you mention it, I'm sure that the technology will be used for this once the price comes down enough...
They give you a "Gene Explorer" that allows you to do a search in your genome to find out if you have a certain gene (e.g., you just heard on the news that Gene XYZ has been linked to Alzheimer's Disease).
Oh boy... this is going to take hypochondria to a new level.
(I'm no expert on this by any means, but I hope I can partially answer your question...)
When a file is encrypted through a strong algorithm and there are private keys between the parts, it is still necessary to add something like MD5 to preserve integrity?
I'm not sure I completely understand what you mean by "private keys between the parts." But if you mean entirely symmetric encryption, then in many circumstances a cryptographic signature -- and therefore a hash function to produce the signature -- is unnecessary, as an attempt to tamper with a transmission without knowing the secret key would result in meaningless gibberish on the receiving end. The major caveat is that, in the context of such a message, random data must be easily recognizable as meaningless gibberish: this will be the case if the transmission is a plaintext written message or something structured (XML, a structured binary format, etc). But if the transmission is of some sort of arbitrary data, then an attacker might be able to do some damage simply by tricking the receiving end into interpreting essentially random (from the attacker's perspective) data as a valid input from a trusted sender. Replay attacks can also be a threat, and cryptographic signatures are often used to prevent them, but it's sort of a separate issue...
Where hash functions and signatures really come into play is in public-key cryptography: here anyone can encrypt a message (actually, encrypt a symmetric key which was used to encode a message) to the recipient, so the fact that a message is properly encrypted is meaningless and additional means are required to demonstrate that the message came from a trusted party -- however "trusted party" may be defined.
MD5 collision attacks aren't really new, although this is a powerful example. An equally meaningful example of a collision attack on the algorithm, in the form of two different PostScript files with the same MD5 hash, was provided at least two years ago (IIRC).
The key to understanding the limits of this demonstration's significance is to realize that a collision attack is quite different from a prefix attack. These researchers were able to create a pair of executables having the same hash value by specially constructing them as such; crafting a new executable to match a specific hash value corresponding to some other party's executable is vastly more difficult to achieve.
So while this demonstrates MD5 to be useless for uses where the purported signatory is to be included in our threat analysis -- as has already been demonstrated to us by other researchers -- the algorithm is still relatively safe if our only goal is to ensure that a given executable almost certainly came from a specific party (rather than showing that it is a specific executable from said party). In other words, one could conceivably use MD5 to verify that the Ubuntu packages on that FTP server were in fact produced by Canonical. So no, demonstration does not mark MD5 as completely useless for code signing; the most common applications of code signing are entirely unconcerned with collisions in the hash function.
In conclusion: the title is terribly misleading, or possibly just misinformed. Boo! Hiss!
The reason that the PC did so well is widely accepted to be the platform's open nature, thanks to Compaq and the other IBM-PC clones. The hardware, operating system, and software were all, to the greatest reasonable extent, interoperable and interchangeable; this resulted in a thriving marketplace of ideas that drove the whole platform forward.
We haven't seen this in the cell phone world yet, especially in the US, because of the closed nature of the system. Up to the present, network carriers, cell phone hardware, and mobile operating systems are locked together. Users and developers aren't free to have their way with the system; worse, your cellular network operator often has the ability to remotely override your software and do nasty things like install roving bugs for the FBI. The phone can't become a universal computing platform to rival the PC until control is handed over to users and third-party developers.
In this regard, the iPhone is a step in exactly the wrong direction. But overall, I think the industry is headed the right way: Just recently we saw news that Verizon plans to open its network to third-party devices. And Google's Linux and Java-based Android could be exactly the software platform we've all been waiting for. The times are a-changin'...
The point is that Asus's failure to release the source code to asus_acpi (and other GPL-derived software) means that, should a user decide to install the latest Ubuntu over the machine's default operating system, he or she loses whatever compatibility enhancements Asus made to the ACPI code in order to make Linux run well on this device. In essence, better battery life -- or whatever specific benefit Asus's modifications provide -- constitute a lock-in to Asus's particular Linux distribution, until Asus fulfills their legal obligations and releases the source code so that other distributions can incorporate it.
Disclaimer: I cannot say to what extent Asus has embraced-and-extended the GPL software on this device first-hand, because I don't own one; nor would I ever consider buying one unless the company changes its current attitude toward pirating open source software. This action violates the most fundamental principles under which Linux and other GPL software has thrived.
This isn't meant as one of those haughty, holier-than-thou remarks that it might initially sound like: The best solution is to run your mail user agent yourself, on your own hardware. Really.
These days it's easy to find an old PC or Mac / Soekris box / Linksys router and install OpenBSD or Linux on it. Then you not only have a more powerful and secure router than you started out with, you also have a general-purpose Unix server at your disposal; set up a free dynamic DNS account from DynDNS.com or the likes (in conjunction with the ddclient update script from the OpenBSD ports tree or Debian repositories) and OpenSSH, and you have a secure and efficient way to log into this system from anywhere on the public Internet. That's one step away from a remote access mail client with far greater security than any web-based company will provide you.
A few pointers:
Set up daily, automatic backups of your mail folders with rsync! Don't lose your mail.
You'll need a command-line mail user agent so that you can access all this by SSH. Mutt is my favorite, but others swear by Pine or the Emacs client.
You can use msmtp to relay, and fetchmail to download, your messages from a remote server; or you can set up your own mail service if your ISP allows it. Consider using procmail to sort incoming messages.
Configure S/KEY passwords on your home server: this way you can login from a somewhat untrusted client, yet rest assured that your password cannot be surreptitiously cached and used again.
Access your mail on the server as a non-wheel user. Now even if somebody does compromise that account (a risk that is, in my opinion, far lower than the risk taken in using web-based systems), they will not have immediate control over the entire system.
Carry Putty around with you on your USB memory device, in case you need to login from a Windows client. Putty is much smaller and more manageable than keeping your own personal copy of Firefox, and it will happily run from the USB stick without any installation or modification required.
Install GPG on the server and import your keyrings.
This approach has a number of advantages over using any third-party web based system. The most obvious one is that in this configuration, GPG runs entirely on the server, keeping your encryption keys safe from untrusted clients. Also, because you are not using a web application, this system is immune to CSRF and XSS attacks. And OpenSSH offers a wide variety of authentication options, many of them far more secure in real-world scenarios than the simple username/password schemes implemented by most web apps.
Real information security takes real work, and as Hushmail has so kindly demonstrated for us, it isn't sound to exclude your own hosting company from your threat analysis. Why not simplify things and host part of your mail system yourself - the part that matters, where your encryption keys are stored and your messages are cached. Sure, it won't protect you from every vector of attack; but if your system does get attacked, it will be much more difficult for the attacker to do so entirely behind your back.
I'm not claiming that such a setup is for everyone. But if you want better security than what Hushmail was able to provide, this is what you need to do. If this is more work than you're willing to put in, it important to realize what you're giving up, and that there are no vastly "better alternatives" in the web-based secure email cottage industry. Or in other words: if you want something done right, do it yourself.
That's an interesting straw man you've drawn up. Personally, I don't know anybody who purchased a Mac because he or she thought it was somehow immune to all forms of malware.
I agree with the parent poster in a sense. OK, they don't really "deserve" to be infected, but there is a fundamental limit to what current computer security models are able to achieve. This infection doesn't occur through the exploit of some flaw in the web browser or OS X, it's pure social engineering. The malware gets installed just like any valid software package would; if the computer's administrator cannot be relied upon to intelligently differentiate between trustworthy and untrustworthy software, then all other technical countermeasures aside, there is absolutely no hope of keeping that system secure.
I've never ever ever heard an end user observe that programs on Mac OS X "crash more" or "install adware more" than programs on XP or Vista. This could change, but when is it going to happen and how?
There's no question that buffer overruns are at least as big a problem for Apple as they are for Microsoft. Just ask QuickTime. We could argue all day over why they aren't as widely exploited on OS X for now, but whatever the reason, it's no excuse for being complacent about the problem.
These vendors don't give a flying fuck about.NET, and won't probably ever, and we have yet to see any.NET or managed-runtime competitors for them.
In much the same way that Adobe and Microsoft don't give a flying fuck about Cocoa on OS X. Today's new software is by and large being developed on Cocoa and.NET; but of course all the big legacy applications are still based on the older frameworks, on their respective operating systems.
Anyway, there's a whole lot more to a managed runtime like.NET than the corresponding security against memory corruption (which even by itself is significant). For example:
Portability. Suppose the PC industry altogether decided to switch from the x86 architecture to PowerPC. For pure.NET applications, we wouldn't have to suffer the burden of running them in Microsoft's anti-Rosetta until native PowerPC versions were shipped by each vendor; as long as there is a.NET runtime on that processor architecture, the apps would "just work", no fat binaries needed. A managed virtual runtime helps future-proof applications against unknown hardware requirements and advances.
Type safety. Program behavior can be better verified under the memory-safe conditions of a managed runtime. This may eventually lead to widespread changes in hardware and software architecture. See the Singularity project for more information.
Interoperability. Microsoft's CLI in particular provides a unified approach for handling exceptions, garbage collection, method invocation, and data passing in environments containing code written in a variety of languages.
Fine-grained security..NET's Code Access Security provides fine-grained control through code validation and call stack inspection.
It's not just "safety snobs" who see the managed runtime as the future. There's a whole world of benefit to be had in abstracting bytecode from the CPU, replacing some of the rigid complexity of the hardware with software's power and flexibility. And if the managed runtime proponents turn out to be right, Apple will have lot of catch-up work to do...
You seem to have misunderstood me; "first-class" wasn't a reference to the quality of the languages or runtimes. I was pointing out that no such framework is currently a first-class citizen on OS X: Python applications rely on a third-party Objective-C bridge to access the Cocoa frameworks. There's a whole lot more to being a first-class language/runtime than being installed by default.
That's not to say there aren't more fundamental problems with the notion of Python as a potential competitor to.NET, however, such as the fact that unlike in Java and.NET, Python's global interpreter lock mechanism prevents true SMP parallelism. (There's a reason that IronPython is so popular: people want to combine the excellent Python language and standard library with the frankly much more advanced and better performing.NET CLR.) Ruby's interpreter is even worse, although YARV might go a ways towards improving that, assuming it comes out with the next Ruby release as promised.
As Siracusa's review spells out, Apple's direction right now is that OS X is Cocoa is Objective-C. There's no managed runtime so technologically and strategically integrated into OS X as.NET is into Windows.
Slashdot Mirror
And as someone who has no intention to use my network for child pornography, phishing, launching DDoS attacks, or violating copyright laws, this is entirely meaningless. The likelihood of spammers and others using my WiFi connection, should I leave it unsecured in this densely-populated and highly technical area, really is not negligible -- and in any event is infinitely greater than the probability of me engaging in such incriminating activities myself, which is identically zero.
Seriously, I get the whole plausible deniability / civil disobedience argument, but the truth is that the majority of the things one might get in trouble for on the Internet are illegal for a reason. Seriously, has it become passé to admit that you have no business trying (for example) to crack someone's web server in the first place?
These open WiFi thought experiments seem to neglect the fact that the only sure way to stay out of such trouble is to not break the law in the first place, and then to secure your wireless access point so that nobody else can do so using your Internet connection, either.
I specifically mentioned Arcade Fire, which is on an independent label. Offhand it seems that indie rock/pop bands are just as likely to engage in this "loudness warfare" as their big-label counterparts. It's less prominent with jazz music, fortunately (indie or otherwise), and classical music is of course safe from this treatment.
Oh, and finally, I don't get what you mean by "to normalize the volume levels of CDs and other digital media". There's something that we musician or audio engineers call "normalizing" but it has nothing to see with your interpretation, so I don't see what you're speaking about, honestly. Would you force anyone to do something against their will, I really don't get what you wish here.What I'm suggesting is a standardized RMS level for CD audio. For instance, the Dolby Digital standard specifies a reference level of -20 dBfs (RMS). You can call it forcing engineers to do something "against their will" if you want, but I think that this sort of thing really does belong in the standard, and apparently I'm hardly the only one who thinks so. We've certainly seen the ugly consequences of not including it in the standard...
Let the good music not use global compression, and the bad music use it. That's life you know. If some disc is primarily made to be listened at the same time in clubs, bars or public transport, compression is necessary and loudness war a mere corollary.Audio CDs are first and foremost for individual customers and for airplay. The present overcompression fad has nothing to do with bars and public transport, it has to do with making your song sound louder than the ones that play before and after it on the radio -- or on the sampler at the music store, or in iTMS, or wherever else a potential customer might hear it. (And for the kind of compression actually required in bars and the like, a decent receiver can do that for you, or anybody with a copy of Audacity could create a specially compressed version of the album on behalf of the bar or the label.)
Let the good music not use global compression, and the bad music use it. That's life you know.The problem is that, in the real world, quite a lot of the good music does get overcompressed for the digital master. And that's why I often buy vinyl instead, even given the medium's inherent disadvantages.
That's it exactly. A hot CD doesn't do justice to bands like Arcade Fire, so I'm willing to go out of my way to get the vinyl versions of certain albums even if it means I now have to worry about things like dust and needle wear. I'd prefer that the studios just digitally master these things correctly in the first place, but that's not going to happen as long as the engineers feel compelled to make their songs sound the "loudest" on the radio; and that won't stop until we can agree on a way to normalize the volume levels of CDs and other digital media.
There's a great YouTube video on this subject: "The Loudness War"
In that case all of us Mac users are screwed; every single copy of OS X comes with tcpdump.
No, you're missing the point. TrueCrypt can provide plausible deniability as to the existence of an encrypted volume even if it's known that you're using TrueCrypt.
Fortunately they've so far refrained from "emulating" Pages's lack of support for bibliographies and equations.
That's sort of the point, in a way. The more people use FOSS operating systems, the more blindingly obvious it becomes to the media distribution companies that insisting their wares be copy-protected down to levels as absurd as restricted memory and hardware access -- a scheme which the FOSS systems will not choose to enforce -- is, from a market perspective, a losing proposition.
At that point you can't even call it a website any more; it's just a graphical .NET application that happens to be delivered over HTTP.
And yes, the same is absolutely true for pure-Flash websites, too. But this is made slightly less onerous because Adobe provides versions of the Flash plugin for Linux and OS X that are ostensibly on par with the Windows version, and Adobe doesn't lock you into a single platform for developing Flash apps -- unlike Microsoft, Adobe's end game is not to create a sea of de-facto "standard" applications for which the company's own operating system is the best, or only, choice.
To the best of my knowledge, Firefox typically does not leak memory, at least in the conventional sense that references to memory are erroneously discarded and unused allocated memory cannot be freed. Instead, the actual heart of the issue is supposedly memory fragmentation:
http://blog.pavlov.net/2007/11/10/memory-fragmentation/
As the linked article suggests, memory fragmentation can be reduced by replacing heap allocations with stack variables, where possible, in hotspots such as the JavaScript engine. As for the heap allocations that cannot be dealt away with in this manner, effort can be made to group them together such that they are less likely to cause fragmentation.
I think you're entirely missing the point here. Sure we've always been free to dual-license things, but many people just aren't good at writing copyright notices and the like. This essentially provides content providers and potential licensers with a consistent user interface within which to operate.
Imagine that a publisher sees a really insightful code example in a blog entry on Erlang, which he thinks would make an excellent addition to an upcoming book. But the blog's author hasn't made clear whether this work can somehow be licensed for commercial use; or even if he has, the publisher might be having a hard time parsing the author's legalese. The publisher very well might just give up on it rather than go through the effort of contacting and negotiating with the author, and in the end both the publisher and the author lose out. On the other hand, if the author can just put a Creative Commons CC+ button on the page, the publisher can see it immediately and think: "I've seen this before and I know what it means. This work can be licensed, I can click here to find out what it will cost, etc."
This protocol continues Creative Commons' legacy of making public licensing accessible to the common man. And I think it's an excellent idea.
That's all right, just wait until we're all using supercapacitor-powered laptops...
You do realize that English is a living language, and that a word's meaning is ultimately a function of its popular usage:
ag-nos-tic 2. Doubtful or noncommittal: "Though I am agnostic on what terms to use, I have no doubt that human infants come with an enormous 'acquisitiveness' for discovering patterns" (William H. Calvin). -- The American Heritage DictionaryOddly enough, I just watched a presentation about this very topic, with an emphasis on Erlang's model for concurrency. The slides are available here:
http://www.algorithm.com.au/downloads/talks/Concurrency-and-Erlang-LCA2007-andrep.pdf
The presentation itself (OGG Theora video available here) included an interesting quote from Tim Sweeney, creator of the Unreal Engine: "Shared state concurrency is hopelessly intractable."
The point expounded upon in the presentation is that when you have thousands of mutable objects, say in a video game, that are updated many times per second, and each of which touches 5-10 other objects, manual synchronization is hopelessly useless. And if Tim Sweeney thinks it's an intractable problem, what hope is there for us mere mortals?
The rest of this presentation served as an introduction to the Erlang model of concurrency, wherein lightweight threads have no shared state between them. Rather, thread communication is performed by an asynchronous, nothing-shared message passing system. Erlang was created by Ericsson and has been used to create a variety of highly scalable industrial applications, as well as more familiar programs such as the ejabberd Jabber daemon.
This type of concurrency really looks to be the way forward to efficient utilization of multi-core systems, and I encourage everyone to at least play with Erlang a little to gain some perspective on this style of programming.
For a stylish introduction to the language from our Swedish friends, be sure to check out Erlang: The Movie.
That would be amazing. These days the visually impaired rely on somewhat ambiguous and rather quiet "buzzers" to alert them to the changing states of crosswalks. These buzzers aren't always installed, either, partially because of their limitations. Imagine if the crosswalk could very audibly tell pedestrians when they have the right-of-way, without disturbing others in nearby businesses and apartments?
Now that you mention it, I'm sure that the technology will be used for this once the price comes down enough...
Well hey, don't blame it on Ubuntu; blame it on Apple for choosing hardware without decent open-source driver support.
(So he says as he types this on his mac...)
Oh boy... this is going to take hypochondria to a new level.
(I'm no expert on this by any means, but I hope I can partially answer your question...)
When a file is encrypted through a strong algorithm and there are private keys between the parts, it is still necessary to add something like MD5 to preserve integrity?I'm not sure I completely understand what you mean by "private keys between the parts." But if you mean entirely symmetric encryption, then in many circumstances a cryptographic signature -- and therefore a hash function to produce the signature -- is unnecessary, as an attempt to tamper with a transmission without knowing the secret key would result in meaningless gibberish on the receiving end. The major caveat is that, in the context of such a message, random data must be easily recognizable as meaningless gibberish: this will be the case if the transmission is a plaintext written message or something structured (XML, a structured binary format, etc). But if the transmission is of some sort of arbitrary data, then an attacker might be able to do some damage simply by tricking the receiving end into interpreting essentially random (from the attacker's perspective) data as a valid input from a trusted sender. Replay attacks can also be a threat, and cryptographic signatures are often used to prevent them, but it's sort of a separate issue...
Where hash functions and signatures really come into play is in public-key cryptography: here anyone can encrypt a message (actually, encrypt a symmetric key which was used to encode a message) to the recipient, so the fact that a message is properly encrypted is meaningless and additional means are required to demonstrate that the message came from a trusted party -- however "trusted party" may be defined.
Err, "prefix attack"? It's too early in the morning for me to be posting to Slashdot...
pretext attack, for the record.
MD5 collision attacks aren't really new, although this is a powerful example. An equally meaningful example of a collision attack on the algorithm, in the form of two different PostScript files with the same MD5 hash, was provided at least two years ago (IIRC).
The key to understanding the limits of this demonstration's significance is to realize that a collision attack is quite different from a prefix attack. These researchers were able to create a pair of executables having the same hash value by specially constructing them as such; crafting a new executable to match a specific hash value corresponding to some other party's executable is vastly more difficult to achieve.
So while this demonstrates MD5 to be useless for uses where the purported signatory is to be included in our threat analysis -- as has already been demonstrated to us by other researchers -- the algorithm is still relatively safe if our only goal is to ensure that a given executable almost certainly came from a specific party (rather than showing that it is a specific executable from said party). In other words, one could conceivably use MD5 to verify that the Ubuntu packages on that FTP server were in fact produced by Canonical. So no, demonstration does not mark MD5 as completely useless for code signing; the most common applications of code signing are entirely unconcerned with collisions in the hash function.
In conclusion: the title is terribly misleading, or possibly just misinformed. Boo! Hiss!
The reason that the PC did so well is widely accepted to be the platform's open nature, thanks to Compaq and the other IBM-PC clones. The hardware, operating system, and software were all, to the greatest reasonable extent, interoperable and interchangeable; this resulted in a thriving marketplace of ideas that drove the whole platform forward.
We haven't seen this in the cell phone world yet, especially in the US, because of the closed nature of the system. Up to the present, network carriers, cell phone hardware, and mobile operating systems are locked together. Users and developers aren't free to have their way with the system; worse, your cellular network operator often has the ability to remotely override your software and do nasty things like install roving bugs for the FBI. The phone can't become a universal computing platform to rival the PC until control is handed over to users and third-party developers.
In this regard, the iPhone is a step in exactly the wrong direction. But overall, I think the industry is headed the right way: Just recently we saw news that Verizon plans to open its network to third-party devices. And Google's Linux and Java-based Android could be exactly the software platform we've all been waiting for. The times are a-changin'...
The point is that Asus's failure to release the source code to asus_acpi (and other GPL-derived software) means that, should a user decide to install the latest Ubuntu over the machine's default operating system, he or she loses whatever compatibility enhancements Asus made to the ACPI code in order to make Linux run well on this device. In essence, better battery life -- or whatever specific benefit Asus's modifications provide -- constitute a lock-in to Asus's particular Linux distribution, until Asus fulfills their legal obligations and releases the source code so that other distributions can incorporate it.
Disclaimer: I cannot say to what extent Asus has embraced-and-extended the GPL software on this device first-hand, because I don't own one; nor would I ever consider buying one unless the company changes its current attitude toward pirating open source software. This action violates the most fundamental principles under which Linux and other GPL software has thrived.
This isn't meant as one of those haughty, holier-than-thou remarks that it might initially sound like: The best solution is to run your mail user agent yourself, on your own hardware. Really.
These days it's easy to find an old PC or Mac / Soekris box / Linksys router and install OpenBSD or Linux on it. Then you not only have a more powerful and secure router than you started out with, you also have a general-purpose Unix server at your disposal; set up a free dynamic DNS account from DynDNS.com or the likes (in conjunction with the ddclient update script from the OpenBSD ports tree or Debian repositories) and OpenSSH, and you have a secure and efficient way to log into this system from anywhere on the public Internet. That's one step away from a remote access mail client with far greater security than any web-based company will provide you.
A few pointers:
This approach has a number of advantages over using any third-party web based system. The most obvious one is that in this configuration, GPG runs entirely on the server, keeping your encryption keys safe from untrusted clients. Also, because you are not using a web application, this system is immune to CSRF and XSS attacks. And OpenSSH offers a wide variety of authentication options, many of them far more secure in real-world scenarios than the simple username/password schemes implemented by most web apps.
Real information security takes real work, and as Hushmail has so kindly demonstrated for us, it isn't sound to exclude your own hosting company from your threat analysis. Why not simplify things and host part of your mail system yourself - the part that matters, where your encryption keys are stored and your messages are cached. Sure, it won't protect you from every vector of attack; but if your system does get attacked, it will be much more difficult for the attacker to do so entirely behind your back.
I'm not claiming that such a setup is for everyone. But if you want better security than what Hushmail was able to provide, this is what you need to do. If this is more work than you're willing to put in, it important to realize what you're giving up, and that there are no vastly "better alternatives" in the web-based secure email cottage industry. Or in other words: if you want something done right, do it yourself.
That's an interesting straw man you've drawn up. Personally, I don't know anybody who purchased a Mac because he or she thought it was somehow immune to all forms of malware.
I agree with the parent poster in a sense. OK, they don't really "deserve" to be infected, but there is a fundamental limit to what current computer security models are able to achieve. This infection doesn't occur through the exploit of some flaw in the web browser or OS X, it's pure social engineering. The malware gets installed just like any valid software package would; if the computer's administrator cannot be relied upon to intelligently differentiate between trustworthy and untrustworthy software, then all other technical countermeasures aside, there is absolutely no hope of keeping that system secure.
There's no question that buffer overruns are at least as big a problem for Apple as they are for Microsoft. Just ask QuickTime. We could argue all day over why they aren't as widely exploited on OS X for now, but whatever the reason, it's no excuse for being complacent about the problem.
These vendors don't give a flying fuck aboutIn much the same way that Adobe and Microsoft don't give a flying fuck about Cocoa on OS X. Today's new software is by and large being developed on Cocoa and .NET; but of course all the big legacy applications are still based on the older frameworks, on their respective operating systems.
Anyway, there's a whole lot more to a managed runtime like .NET than the corresponding security against memory corruption (which even by itself is significant). For example:
It's not just "safety snobs" who see the managed runtime as the future. There's a whole world of benefit to be had in abstracting bytecode from the CPU, replacing some of the rigid complexity of the hardware with software's power and flexibility. And if the managed runtime proponents turn out to be right, Apple will have lot of catch-up work to do...
You seem to have misunderstood me; "first-class" wasn't a reference to the quality of the languages or runtimes. I was pointing out that no such framework is currently a first-class citizen on OS X: Python applications rely on a third-party Objective-C bridge to access the Cocoa frameworks. There's a whole lot more to being a first-class language/runtime than being installed by default.
That's not to say there aren't more fundamental problems with the notion of Python as a potential competitor to .NET, however, such as the fact that unlike in Java and .NET, Python's global interpreter lock mechanism prevents true SMP parallelism. (There's a reason that IronPython is so popular: people want to combine the excellent Python language and standard library with the frankly much more advanced and better performing .NET CLR.) Ruby's interpreter is even worse, although YARV might go a ways towards improving that, assuming it comes out with the next Ruby release as promised.
As Siracusa's review spells out, Apple's direction right now is that OS X is Cocoa is Objective-C. There's no managed runtime so technologically and strategically integrated into OS X as .NET is into Windows.