If the algorithm is secure, you have to keep your own key
Of course, hushmail's original selling point was that you _do_ keep your own key, or at least your key's AES-encrypted while on their servers and not decrypted there. That's the story that most people here about the service, even now.
However, at some point in the not-too-distant past, hushmail added a new service that didn't require a java applet to work, but that does require them to have your key. They're not forthcoming enough (IMO) about the difference between the two services.
Of course, with the applet they could give you a new one that sends them the decrypted key - I'm not sure of the legality of them doing so, even with a court order.
If I were them, I'd wipe the private key that's used to sign the applet. That way, if they're ever forced to do this, they'd have to use a different signing certificate, and the users (at least those who had checked the 'always trust applets from Hush Communications' checkbox the first time they signed in) would get an unexpected security dialog. Those of us who are paranoid could then choose not to use the fishy version.
What do you expect when you PRIVATE key is stored somewhere you do not control access to? kind of dumb, if you ask me.
Except, according to hushmail's docs, that's not the case. They may have your private key, but according to the docs, it's AES-encrypted with your passphrase, and never leaves your local machine in any other state. That doesn't seem so dumb.
How did this happen? Fuck knows. It isn't supposed to be possible. Hushmail's system was supposedly designed so that they couldn't do this, even if they wanted to. Perhaps one of them was running with an incredibly weak passphrase and hushmail cracked it on behalf of the feds...? All I can think of.
No mater how secure a company claims to be, you can't expect them to not fallow the law.
The point is that according to hushmail's end-user documentation, *they can't do this*.
Hushmail supposedly store everything, including your key, encrypted. The encrypted key is sent to an applet running on your computer, which decrypts it *locally* without sending a copy of your passphrase to the server. If you send e-mail to another hushmail user (as was the case in this instance) it is supposed to be encrypted with their public key *before it leaves your computer*.
If all of this was true, hushmail would not have been able to supply the FBI with the documents they did.
I think that was Hydra. Multics only added one level of indirection and that's still in use today on modern architectures (segment selector architecture, similar to 80286 et al).
MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS i assure you that just as of now there are more than one project for an emulator (even hardware) are on the works in the half-dark recesses of many college/private sector labs.
Indeed. Give a few students a handful of months and access to some reasonably large FPGAs, and I'm sure we'll have something convincing.
Contracts must be a two way street to be legally binding.
Non-compete agreements are not contracts, but covenants, which are different.
I would say that I'm not a lawyer, but I'm not a fucking lawyer and so I don't have to put stupid legalese into my posts!
That's fine until somebody treats advice you give as legal advice, gets screwed over, and then sues you. Then, you'll probably wish you said you weren't a lawyer.
I'm sure they mean eliminating halogenated organic compound or something similar Otherwise I think eliminating halogens from chips themselves is just a drop in the ocean. A deep, halogen salt enriched ocean.
Halogens are elements. Halogenated organic compounds are compounds that contain halogens. In order to eliminate halogens from the chip, they'll have to eliminate all compounds of halogens. I'd have thought that was fairly obvious...?
Annotations were added in 1.5, so I have no idea what you mean by "the annotation processing API".
I mean the package javax.annotation.processing, used to produce compile-time annotation processor plugins.
Having actually used java.io.Console, it's no better than System.in/System.out which have existed forever.
Except that it provides a crucial capability that is not possible with System.in and System.out: reading of passwords with echo disabled. Seriously, this capability alone is enough to persuade those of using Java for writing command-line system applications to upgrade.
As for subpixel rendering, you have to be kidding. First, Java has supported anti-aliasing since 1.2
Subpixel rendering and anti-aliasing are very different systems.
and secondly I'm fairly certain that Apple's Java used their font rendering in the Mac OS Swing PLAF anyway.
If it does, it's highly unusual. None of the Windows, Solaris or Linux ports do this. I can't confirm either way, though, because I'm not using an Apple system. Here (where I use Windows and Linux predominantly), 1.6 is a clear improvement.
Amen! I also love how the phone has a knack for running out of memory right when an important call comes in. There's nothing more frustrating than a ringing phone that won't show me the phone screen and where the buttons suddenly don't work.
This is one of the brilliant things about PalmOS: you can write a program that will run on it _without using any memory at runtime_. Because it can run programs straight off flash, without having to load them into RAM.
OK, so PalmOS has/had a lot of problems, but why are mobile operating systems still being developed that treat their flash devices as if they were just a disk...?
What does Java 6 offer that you can't download a library to do in Java 5?
Subpixel rendering in AWT/Swing applications. java.io.Console. The annotation processing API. I'm sure there are others, but those are the only ones I've made use of.
Good point, but one also has to consider the fact that written Japanese, like most written languages that use ideographs, has a high information density (assuming high kanji to kana ratio) per unit of screen area, making it better in conveying information on a small screen.
Japanese writing is not ideographic. It uses a syllabic representation, with some single-syllable words using a visual representation of the concept.
Contrary to popular opinion, there are no fully ideographic writing systems. Chinese is the closest that has ever existed, which is a syllabic representation like Japanese, but as almost all Chinese words are a single syllable (this is an over-simplification) it comes close.
Just because its a blog doesnt it make any less real than posting it as leaflets on lampposts.
If the accusations are true, than they will lose. If they arent, they have every right to defend themselves against this libel.
That's not entirely true. There's a defence to libel called "honest opinion", which basically means that the statements made are clearly intended to be interpreted as opinion rather than absolute statements of fact. This does, in fact, mean that blogs (a medium that is commonly used for distributing opinions) are harder to show libel in than pamphlets (which are usually intended to be interpreted as fact).
This blog, with article titles like "FASCIST STATE RISING!!" and "More Work for Erik the Destroyer!" is clearly dealing in opinion.
Because "exxon" has no meaning in any language on earth except in reference to the oil company, any use of the name will necessarily be associated with (thus cause confusion with) the company.
A standup comedian ran a joke, that went like this: "There's a new swear word in the Inuit language. Exxon."
You telling me that that's a trademark infringement?
Except when I'm working on it, Magic-1 is connected to the net. It serves web pages at [censored], and by clicking here you can telnet in and play Original Adventure or run a few other old classics such as Eliza, Conway's Life or Hunt the Wumpus. To log in, use the id "guest" and the password "magic". Before the Minix port was completed, Magic-1 was running a very simple homebrew operating system. It also had a simple guestbook program. Many thousands of people have telnetted into Magic-1 from around the world, and between 2004 and the summer of 2007 they left 1388 guestbook messages.
I removed the URL because I'd hate to be responsible for the Magic-1's untimely death by fire (although the site is down at the moment anyway). Anyway, that is some seriously impressive stuff.
Telnet works though.
magic-1:/usr/home/guest # dhrystone Dhrystone(1.1) time for 3634 passes = 7.35 This machine benchmarks at 493 dhrystones/second
Slashdot Mirror
If the algorithm is secure, you have to keep your own key
Of course, hushmail's original selling point was that you _do_ keep your own key, or at least your key's AES-encrypted while on their servers and not decrypted there. That's the story that most people here about the service, even now.
However, at some point in the not-too-distant past, hushmail added a new service that didn't require a java applet to work, but that does require them to have your key. They're not forthcoming enough (IMO) about the difference between the two services.
If you use their client-side Java applet to do the encryption on your computer - as they strongly recommends that you do - then this is not an issue.
If they "strongly recommend" this, why is it off by default?
Of course, with the applet they could give you a new one that sends them the decrypted key - I'm not sure of the legality of them doing so, even with a court order.
If I were them, I'd wipe the private key that's used to sign the applet. That way, if they're ever forced to do this, they'd have to use a different signing certificate, and the users (at least those who had checked the 'always trust applets from Hush Communications' checkbox the first time they signed in) would get an unexpected security dialog. Those of us who are paranoid could then choose not to use the fishy version.
What do you expect when you PRIVATE key is stored somewhere you do not control access to? kind of dumb, if you ask me.
Except, according to hushmail's docs, that's not the case. They may have your private key, but according to the docs, it's AES-encrypted with your passphrase, and never leaves your local machine in any other state. That doesn't seem so dumb.
How did this happen? Fuck knows. It isn't supposed to be possible. Hushmail's system was supposedly designed so that they couldn't do this, even if they wanted to. Perhaps one of them was running with an incredibly weak passphrase and hushmail cracked it on behalf of the feds...? All I can think of.
No mater how secure a company claims to be, you can't expect them to not fallow the law.
The point is that according to hushmail's end-user documentation, *they can't do this*.
Hushmail supposedly store everything, including your key, encrypted. The encrypted key is sent to an applet running on your computer, which decrypts it *locally* without sending a copy of your passphrase to the server. If you send e-mail to another hushmail user (as was the case in this instance) it is supposed to be encrypted with their public key *before it leaves your computer*.
If all of this was true, hushmail would not have been able to supply the FBI with the documents they did.
OS/360 required 1,200 man-years of work
That's a myth.
(Sorry. Bad joke, but I couldn't resist it.)
I think that was Hydra. Multics only added one level of indirection and that's still in use today on modern architectures (segment selector architecture, similar to 80286 et al).
MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS
i assure you that just as of now there are more than one project for an emulator (even hardware) are on the works in the half-dark recesses of many college/private sector labs.
Indeed. Give a few students a handful of months and access to some reasonably large FPGAs, and I'm sure we'll have something convincing.
And it's Multivac not MULTIVAC!
http://www.scribd.com/doc/3407/The-Last-Question
You know, given the whole scribd / Asimov / Doctorow thing, I'm rather surprised that's still up there.
Non-compete agreements are not contracts, but covenants, which are different.
I have never heard that theory before. I think you're a bit mistaken, covenants are generally part of property law, not contract law.
Here are a lot of lawyers who disagree with you.
It will still use RAM. What about stack and heap memory? Maybe it's not loading the program into RAM, just allocating work memory?
Both are a fixed size, and it will terminate existing applications to start a new one, so it is always possible to start a new application.
Contracts must be a two way street to be legally binding.
Non-compete agreements are not contracts, but covenants, which are different.
I would say that I'm not a lawyer, but I'm not a fucking lawyer and so I don't have to put stupid legalese into my posts!
That's fine until somebody treats advice you give as legal advice, gets screwed over, and then sues you. Then, you'll probably wish you said you weren't a lawyer.
IANAL; this is not legal advice.
This is why I have my gender in my signature
Wait. What signature?
Oh, yes, I remember. Slashdot accounts have _signatures_ and there's an option to turn them _off_. I'd forgotten about that.
Sorry. Back to your regularly scheduled flame war^W^Wdebate.
...faster and less leaky...
What a coincidence! Precisely the traits that I look for when switching condom brands!
In that case, may I suggest you try some high-K metal-gate condoms?
Intel engineers should not be allowed to name the new chip lines after their D&D characters.
Err... like most recent Intel chip codenames, Penryn is a place.
I'm sure they mean eliminating halogenated organic compound or something similar Otherwise I think eliminating halogens from chips themselves is just a drop in the ocean. A deep, halogen salt enriched ocean.
Halogens are elements. Halogenated organic compounds are compounds that contain halogens. In order to eliminate halogens from the chip, they'll have to eliminate all compounds of halogens. I'd have thought that was fairly obvious...?
Annotations were added in 1.5, so I have no idea what you mean by "the annotation processing API".
I mean the package javax.annotation.processing, used to produce compile-time annotation processor plugins.
Having actually used java.io.Console, it's no better than System.in/System.out which have existed forever.
Except that it provides a crucial capability that is not possible with System.in and System.out: reading of passwords with echo disabled. Seriously, this capability alone is enough to persuade those of using Java for writing command-line system applications to upgrade.
As for subpixel rendering, you have to be kidding. First, Java has supported anti-aliasing since 1.2
Subpixel rendering and anti-aliasing are very different systems.
and secondly I'm fairly certain that Apple's Java used their font rendering in the Mac OS Swing PLAF anyway.
If it does, it's highly unusual. None of the Windows, Solaris or Linux ports do this. I can't confirm either way, though, because I'm not using an Apple system. Here (where I use Windows and Linux predominantly), 1.6 is a clear improvement.
Amen! I also love how the phone has a knack for running out of memory right when an important call comes in. There's nothing more frustrating than a ringing phone that won't show me the phone screen and where the buttons suddenly don't work.
This is one of the brilliant things about PalmOS: you can write a program that will run on it _without using any memory at runtime_. Because it can run programs straight off flash, without having to load them into RAM.
OK, so PalmOS has/had a lot of problems, but why are mobile operating systems still being developed that treat their flash devices as if they were just a disk...?
What does Java 6 offer that you can't download a library to do in Java 5?
Subpixel rendering in AWT/Swing applications. java.io.Console. The annotation processing API. I'm sure there are others, but those are the only ones I've made use of.
Seriously. This guy's been Chicken Littling everthing for years now. When was the last time he was actually dead-on 100% right about something?
On the other hand, he does seem to be actually dead-on 100% wrong more times than can be attributed to chance alone.
Good point, but one also has to consider the fact that written Japanese, like most written languages that use ideographs, has a high information density (assuming high kanji to kana ratio) per unit of screen area, making it better in conveying information on a small screen.
Japanese writing is not ideographic. It uses a syllabic representation, with some single-syllable words using a visual representation of the concept.
Contrary to popular opinion, there are no fully ideographic writing systems. Chinese is the closest that has ever existed, which is a syllabic representation like Japanese, but as almost all Chinese words are a single syllable (this is an over-simplification) it comes close.
Just because its a blog doesnt it make any less real than posting it as leaflets on lampposts.
If the accusations are true, than they will lose.
If they arent, they have every right to defend themselves against this libel.
That's not entirely true. There's a defence to libel called "honest opinion", which basically means that the statements made are clearly intended to be interpreted as opinion rather than absolute statements of fact. This does, in fact, mean that blogs (a medium that is commonly used for distributing opinions) are harder to show libel in than pamphlets (which are usually intended to be interpreted as fact).
This blog, with article titles like "FASCIST STATE RISING!!" and "More Work for Erik the Destroyer!" is clearly dealing in opinion.
IANAL; this is not legal advice; etc.
Because "exxon" has no meaning in any language on earth except in reference to the oil company, any use of the name will necessarily be associated with (thus cause confusion with) the company.
A standup comedian ran a joke, that went like this: "There's a new swear word in the Inuit language. Exxon."
You telling me that that's a trademark infringement?
Memory chips are visible in this picture and are a set of 8 HM628512(A/B)LP chips.
Too late!
Except when I'm working on it, Magic-1 is connected to the net. It serves web pages at [censored], and by clicking here you can telnet in and play Original Adventure or run a few other old classics such as Eliza, Conway's Life or Hunt the Wumpus. To log in, use the id "guest" and the password "magic". Before the Minix port was completed, Magic-1 was running a very simple homebrew operating system. It also had a simple guestbook program. Many thousands of people have telnetted into Magic-1 from around the world, and between 2004 and the summer of 2007 they left 1388 guestbook messages.
I removed the URL because I'd hate to be responsible for the Magic-1's untimely death by fire (although the site is down at the moment anyway). Anyway, that is some seriously impressive stuff.
Telnet works though.
magic-1:/usr/home/guest # dhrystone
Dhrystone(1.1) time for 3634 passes = 7.35
This machine benchmarks at 493 dhrystones/second