Sur-prise sur-prise sur-prise

What's the point of having money if it's not safe, at least from the time you take possession of it until the time you spend it?

... of the Dane." -Rudyard Kipling

Rudyard Kipling, Dane-Geld, A.D. 980-1016

It is always a temptation to an armed and agile nation
    To call upon a neighbour and to say: --
"We invaded you last night--we are quite prepared to fight,
    Unless you pay us cash to go away."

And that is called asking for Dane-geld,
    And the people who ask it explain
That you've only to pay 'em the Dane-geld
    And then you'll get rid of the Dane!

It is always a temptation for a rich and lazy nation,
    To puff and look important and to say: --
"Though we know we should defeat you, we have not the time to meet you.
    We will therefore pay you cash to go away."

And that is called paying the Dane-geld;
    But we've proved it again and again,
That if once you have paid him the Dane-geld
    You never get rid of the Dane.

It is wrong to put temptation in the path of any nation,
    For fear they should succumb and go astray;
So when you are requested to pay up or be molested,
    You will find it better policy to say: --

"We never pay any-one Dane-geld,
    No matter how trifling the cost;
For the end of that game is oppression and shame,
    And the nation that pays it is lost!"

And now for a lame humor interlude...

The NSA never met a data that it didn't like.

We now resume our regular /. programming

You can't trust USB devices these days either.

How about an offline machine that encrypts and prints the encrypted email either as text or as an easy-to-scan graphic and a scanner on the sending computer to scan it in as a graphic, mail the graphic to the recipient, and let him do the de-rasterizing and decrypting?

For receiving mail, have a 3rd computer that is air-gapped from the other two that has a scanner attached to it.

Yeah, it's hard, and yeah, it paints a target on your back about as much as using TOR would, but it would be immune from the "poisoned USB port" attack.

The solution is to make it easy to do and hard to corrupt.

If Yahoo published an API for web-browser plugins and provided their own open-source reference implementation, or better yet if they handed off maintenance to a strongly-pro-strong-encryption entity, then both goals would be achieved.

Want to send an email encrypted for the first time in a given web browser on a given computer while logged in as a given user? Yahoo would direct you to either take the easy route and download a plugin from the pro-strong-encryption group's web site, invite you to read instructions for installing your own plugin, or invite you to upload or paste in a pre-encoded message. Yahoo could also present an option for "non-senstive email" where you just tick a checkbox that says "encrypt before delivery." If you have never created a public key, it would either invite you to upload a public key or warn you that the copy in your "sent" folder would be stored without any additional encryption.

Need to read an encrypted email or read something you've sent that's stored in your sent folder encrypted with your public key on a web browser/computer/user-login that isn't set up for Yahoo PGP yet? Yahoo would direct you to take the same steps as above or invite you to view or download the encrypted message so you could decrypt it with a different program locally.

What would the plugin do?

For receiving, it would decrypt the message using your locally stored, password-protected private key.

For sending, it would encrypt the message once for each recipient and once for you. It would mark the messages with a common X-header so the Yahoo server would know that when it stored all of these outgoing messages in the user's "sent" folder, it would be able to show only the one encrypted with the user's public key in the default view, with links to the other, unreadable copies in case the sender needed those copies later.

1. Is the goal to provide real end-to-end protection where even Yahoo can't help the government snoop even if compelled to by law? That is hard.

2. Is the goal to prevent the government from snooping without involving Yahoo - that is, to make sure mail transiting between Yahoo servers and between Yahoo and other email server and Yahoo and those sending or receiving messages is encrypted? This may help a little but using https: and secure smtp between mail servers gets you most of the way there.

3. Is the goal to prevent the government from snooping without involving either the sender's computer, the recipient's computer, Yahoo, or if the recipient trusts his mail provider with the private keys, the recipient's mail provider? If so, then PGP with Yahoo having either the private keys or a means to compromise the recipient's computer will meet Yahoo's needs.

I suspect Yahoo wants at least #2 but probably #3.

As long as Yahoo is up-front with what they are delivering and doesn't gloss over important details, #2 or #3 could be useful and better than what's out there now.

Example press release:

THE_FUTURE - YAHOO_HQ - Yahoo is proud to announce PGP-encrypted email.

Yahoo is proud to announce PGP-encrypted email. Yahoo has partnered with FOO, BAR, and BAZ to provide a public-key registration service. Users can upload their public keys to FOOBARBAZPGPKEYREGISTRY.com. Yahoo users who wish to send encrypted mail to anyone with a registered public key can do so easily.

For those needing the same level of security as PGP, Yahoo has published specifications for plug-ins to existing PGP software. For those whose don't need quite the same level of security, Yahoo offers plugins for all popular web browsers to make sending and receiving PGP-signed easy.*

Why are we doing this? INSERTMARKETINGSPEAKHERE.

* Using the Yahoo plugin decreases security: Due to the nature of plugins, it is technically possible for Yahoo to deliver a plugin which compromises the user's security. Yahoo will make every effort to not do this unintentionally and will intentionally do this only pursuant to a legal process. For this reason, customers who wish to prevent being affected by such a court-ordered compromise should use software that is not published by Yahoo to send and receive PGP messages through Yahoo. The source code for the standard versions of all PGP-related Yahoo plugs can be found at FOOBARBAZPGPKEYREGISTRY.com/Yahoo/software .

Unless of course someone wants to keep you quiet more than the NSA wants you to talk (see: cement boots).

Hushmail did some stuff client-side. In order to be immune from government interference, Yahoo webmail would have to be similar.

To be trusted for receiving mail, they would need to release an open-source web plugin or local application that hooked into the web browser to do the decrypting client-side, OR have encrypted message be downloadable but not directly readable within the web browser.

Bonus points if the client-side software is developed by a well-respected known-to-value-freedom 3rd party using a standardized API.

I never thought I'd see those words used literally like that.

Memo to self: Do NOT, repeat, do NOT call the next skinny woman I see "massive" - being technically correct won't get me a date.

Bitcoin transactions are already traceable in the blockchain. The information is already there to declare that a given transaction is "null and void" and identify all bitcoins that were affected by that transaction and void them or if they have been co-mingled with valid coins and re-issued, declare all of the progeny of that mixing as having a total value equal to the non-tainted transactions, i.e. these coins would have a "lesser value" than a regular coin.

The problems are not purely technical - they are social and managerial:

The social problem is this:
* Would we rather have a system where crooks can get away with stealing and washing funds and take the risk that OUR funds may be stolen (the current system),
or,
* Would we rather have a system where crooks and those who deal with "shady characters" know they might wind up with worthless coin, thereby disincentivizing this kind of activity, at the cost that anybody at any time may wind up having their coinage de-valued or voided because it was found to be stolen in a transaction days, months, or years ago?

The managerial problem is this:
* Do we want to have a system in which "the community" endorses a coin's devaluation or voiding, and if so, how would that decision be made?
* Do we want a system in which individuals decide for themselves if they want to accept "dirty money" and merely provide them with a means to determine if a given BC is tainted or not?

The latter option is something that anyone can do for themselves today at least in principle:

I can decide that I refuse to accept any BC if it has a certain known-evil transaction in its blockchain history. Yes, this will require me to do a lot of work before accepting any transaction, but in principle, I could do it. If a lot of heavy hitters started doing this - or if major countries started requiring businesses in their country to check coins against a government-run blacklist before accepting them - then this will become a reality even if the majority of the BC community doesn't support the idea.

I guess the questions are:

* Does the community want to "head off" the "individual choice"/"nationally mandated choice" option by doing the work needed to have a community-managed coin-invalidation system?
* Does the community want to maintain the status quo, knowing that the "individual choice"/"nationally mandated choice" option is likely in the future?
* Does the community want to take technical and other measures to make any kind of coin-invalidation system so impractical that it won't be done in the foreseeable future or at least take measure to make it infeasible to invalidate coins that have been through more than a few transactions and/or who have been reported as stolen more than a few hours ago?

Our laws make a mockery of themselves.

This would be a good time to use jury nullification, if the opportunity presents itself.

Okay, so they say it will be backed by "liquid assets" but unless those assets have a relatively stable value and the government doesn't fall into the temptation of debasing this new currency, it's going to be just another case fiat currency.

However, if it's backed by gold, US dollars, or some other reasonably-stable commodity AND there is no debasing, then we will have the digital equivalent of a "gold certificate," "US dollar reserve certificate," or "whatever-certificate" that people can trust. Well, the can trust it at least as much as they can trust the mathematical principles and as much as they can trust the government not to manipulate the blockchain or whatever the blockchain-equivalent will be for this new digital currency.

Oh how I wish you could tell us who you used to work for. Unfortunately, as soon as you do, /. is going to get a subpeona for your IP address, and your ISP will get a supeona for your personal information, and... well, it could get ugly.

If the student's goals are to get a marketable career that will last at least until his next career, he needs to learn whatever employers will want him to know, not whatever is deemed the one true definition of computer science.

If the student's goals are to think and act like a computer scientist or a master engineer he needs to take the appropriate classes and gain the appropriate experience.

Anyone who wants to "think like a computer scientists studying memory management" should know and understand the memory management of not only assembler but also other languages that handle memory in other ways, such as traditional C or managed-memory languages like Java. They should also know how different hardware architectures present memory to applications - is the assembler code really running on the bare metal or is the microcode or hardware-virtualization-layer playing games behind your back?

Likewise, the student who wants to think like a master engineer needs to know enough to say "I will choose library A, compiler B, and run-time implementation C, middleware layer D, operating system E, and hardware F over others because together, they provide the best balance of speed, cost, maintenance, ease of programming, and other factors compared to competing products." For some applications, "knowing enough" means knowing enough about memory management to recognize when memory will be an issue that requires engineering attention/optimization and when it won't be an issue.

Here's a trivial example of how the passage of just two years from 1983 to 1985 changed the need to grok memory management:

In 1983, the early public release of MacPaint running on the early public release of MacOS is said to have used all but 384 bytes of the 128KB of the original Macintosh's RAM. Granted, it relied heavily on the routines that were in the original Mac's 64KB of ROM and it used its own spiritual analog of "disk-based memory" by storing most of the image on the floppy drive instead of in RAM. How did it do this? In addition to being written with a significant amount of assembly language code, it's my understanding that either MacPaint or the ROM routines or both used some very tight loops that, if memory were not so tight, would have been "unrolled" for the sake of speed. Today, or for that matter even 2 years later when RAM was relatively plentiful and cheap, a similar program could have been written in a high-level language without any fancy programming and without the need to "page out" the parts of the image that were not visible on the screen. The very task that required intimate knowledge of memory management in 1983 no longer required this knowledge in 1985.

Useful links:

* https://en.wikipedia.org/wiki/...
* http://www.computerhistory.org...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...

and links embedded in the pages listed above