Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment: Heartbleed - how it could have been found (Score 0) 53

by dwheeler (#49431707) Attached to: Heartbleed One Year Later: Has Anything Changed?
My article How to Prevent the next Heartbleed lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.

Comment: Have a billion speakers (Score 1) 626

At one time a number of constructed languages were created and got some speakers (including Esperanto). But relatively few people learn a language just for fun (yes, I know about Klingon and Elvish, but they will not be replacing English). Most people will only learn a language if they have a strong need to USE that language to communicate with some large group of people. Esperanto is actually much easier to learn than English; it's a reasonable constructed language. I spent a little time learning some of it, and I appreciate its clever approaches to making it easier to learn (e.g., the "mal-" prefix). The problem is that you can only speak with other Esperanto speakers in it. English is a mess of complications, like all natural languages. In some ways English is easier; in others it is harder. But when you learn English, you can talk to the other 1 billion people who can speak English as a first or second language. For most people, THAT is what makes English worth learning. Again, you normally learn a language specifically so you can communicate with others. Chinese actually has more speakers than English, but they are concentrated in China; worldwide, it's easier to find an English speaker than any other specific language. If you want an easier-to-learn language than standard English, you might consider an English-based controlled language like "Basic English" or the "Special English" used by Voice of America ; these are more complicated than Esperanto, but you can talk with many more speakers. I can imagine "mostly compatible with existing English" could be a necessary criteria for "new" constructed language, if you need to create one at all.

Comment: Apache has mod_spdy (Score 3, Insightful) 147

I agree that Apache web server support is vital if HTTP/2 is to get much use. That said, the mod_spdy plug-in for Apache supports SPDY, and has been accepted into Apache trunk. See: http://googledevelopers.blogsp...

Since HTTP/2 is based on SPDY, it seems likely that this plug-in will be tweaked to support HTTP/2. That said, I suspect the Apache Foundation would say something like, "patches welcome".

Comment: Words have meanings (Score 1) 112

by dwheeler (#49103073) Attached to: TrueCrypt Audit Back On Track After Silence and Uncertainty

The vast majority of people who use the term "open source software" use it with roughly the same meaning as OSI does, which is all that matters. You can confirm this with a quick Google search. Also, note that many organizations that require something to be be "open source software" will point to the OSI definition.

By the commonly-used definition of "open source software", you MUST be able to fork the project and maintain your own version. You cannot legally do that with TrueCrypt, therefore, by definition it is not open source software. Case closed.

Comment: TrueCrypt is not open source software. (Score 5, Interesting) 112

by dwheeler (#49097033) Attached to: TrueCrypt Audit Back On Track After Silence and Uncertainty

TrueCrypt isn't open source software, in spite of the author incorrectly claiming it is. More detail is here, which the author could have learned in 2 minutes of Googling: ... for your amusement, I have quoted it below:

TrueCrypt was released under the "TrueCrypt License" which is unique to the TrueCrypt software. It is not part of the pantheon of widely used open source licenses and is not a free software license according to the Free Software Foundation (FSF) license list, as it contains distribution and copyright-liability restrictions. As of version 7.1a (the last full version of the software, released Feb 2012), the TrueCrypt License was Version 3.0.

Discussion of the licensing terms on the Open Source Initiative (OSI)'s license-discuss mailing list in October 2013 suggests that the TrueCrypt License has made progress towards compliance with the Open Source Definition but would not yet pass if proposed for certification as Open Source software.

According to current OSI president Simon Phipps: is not at all appropriate for [TrueCrypt] to describe itself as "open source." This use of the term "open source" to describe something under a license that's not only unapproved by OSI but known to be subject to issues is unacceptable.

As a result of its questionable status with regard to copyright restrictions and other potential legal issues, the TrueCrypt License is not considered "free" by several major Linux distributions and is therefore not included in Debian, Ubuntu, Fedora, openSUSE, or Gentoo.

The wording of the license raises doubts whether those who use it have the right to modify it and use it within other projects. Cryptographer Matthew Green noted that "There are a lot of things [the developers] could have done to make it easier for people to take over this code, including fixing the licensing situation", and speculates that since they didn't do those things (including making the license more friendly), their intent was to prevent anyone from building on their code in the future.

End of life and license version 3.1

The 28 May 2014 announcement of discontinuation of TrueCrypt also came with a new version 7.2 of the software. Among the many changes to the source code from the previous release were changes to the TrueCrypt License — including removal of specific language that required attribution of TrueCrypt as well as a link to the official website to be included on any derivative products — forming a license version 3.1.

On 16 June 2014, the only alleged TrueCrypt developer still answering emails, replied to an email by Matthew Green about the licensing situation. He is not willing to change the license to an open source one, believes that Truecrypt should not be forked, and that if someone wants to create a new version they should start from scratch.

Comment: Don't give your bitcoins to someone else!! (Score 3, Interesting) 148

by dwheeler (#49020847) Attached to: Alleged Bitcoin Scam Leaves Millions Missing

If you transfer bitcoins to some other organization, then THEY have the bitcoins, not you. If you just want to give money to someone else, there are easier ways to do that than by using bitcoin :-).

it seems to me that if you want to use bitcoins, then you should keep the bitcoins in YOUR OWN wallet and under your OWN control until you want to spend them. Don't hand your bitcoins to a so-called "bank", a "trading company", or anyone else unless you purpose is to GIVE THEM the money. I don't know how successful bitcoins will be in the long term, but if they succeed it will be because people seriously protect the bitcoins.

Comment: 90 days is really long (Score 5, Informative) 263

by dwheeler (#48830951) Attached to: Google Releases More Windows Bugs
90 days is really long. The US CERT vulnerability disclosure policy is 45 days as described in (see that more more details). The problem is that you have to balance two conflicting needs; in the words of the CERT, "the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively."

Comment: Leap seconds work just fine (Score 1) 289

by dwheeler (#48749037) Attached to: Extra Leap Second To Be Added To Clocks On June 30
Leap seconds work perfectly well for most situations. If you need precision monotonically-increasing seconds, use TAI time (or "GPS time", which is at a fixed offset from TAI). Leap seconds keep atomic clocks and the real world reasonably synchronized; any other approach will have its own problems.

Comment: Do anthromorphise! (Score 3, Insightful) 303

by dwheeler (#48727553) Attached to: Anthropomorphism and Object Oriented Programming

Don’t anthropomorphize computers, they hate that notes that most developers do use anthropomorphic language. I think there are probably a variety of good reasons for it, too. Here's one speculation: When we communicate with a human, we must use some language that will be more-or-less understood by the other human. Over the years people have developed a variety of human languages that do this pretty well (again, more-or-less). Human languages were not particularly designed to deal with computers, but languages have been honed over long periods of time to discuss human behaviors and their mental states (thoughts, beliefs, goals, and so on). In any case, the problem isn't anthropomorphic language, it's the use of a bad analogy.


Fraud, Not Hackers, Took Most of Mt. Gox's Missing Bitcoins 108

Posted by timothy
from the shocked-simply-shocked dept.
itwbennett writes Nearly all of the roughly $370 million in bitcoin that disappeared in the February 2014 collapse of Mt. Gox probably vanished due to fraudulent transactions, with only 1 percent taken by yet-to-be-identified hackers, according to a report in Japan's Yomiuri Shimbun newspaper, citing sources close to a Tokyo police probe. The disclosure follows months of investigations by police and others into the tangled mess surrounding the disappearance of the 650,000 bit coins.

Comment: Case sensitivity is a good idea (Score 1) 148

by dwheeler (#48660373) Attached to: Critical Git Security Vulnerability Announced

Case sensitivity is a good idea. The problem is that trying to do "case insensitive" matching depends on the locale. If you send your files to someone else, whether or not they are the "same" depends on your locale if you're serious. For Turkish users, 'i' and dotted 'I' are the same if you're considering them as case-sensitive; for many other languages and users, the dots create DIFFERENT characters. And if you're trying to make this "easy" it doesn't go far enough; Latin "a" usually looks the same as Cyrillic "". So please don't say "users can't tell the difference" - they ALREADY can't tell the difference visually, and naive solutions do not begin to address it. At least you can visually see the difference betweeen "Picture" and "picture", and in any case, users typically just click on the item and move on.

I think it would be a GOOD idea to require that Unix-like filenames be legal UTF-8 sequences (since you then know how to display them), and then reject filenames that are not UTF-8. But that's much less intrusive than filename mangling.

That said, it's too late to fix Windows, so if you're going to run on Windows you have to deal with the problem as it is.

Comment: Excellent! Finally, standard formats (Score 1) 40

by dwheeler (#48618153) Attached to: ODF Support In Google Drive
This is excellent news. It's absurd that so many typical documents are stuck in proprietary formats. As stuff changes we should be able to read older documents using any tool we'd like. This is a major step along the way; there are now even more systems that support open document format. Congrats to Google!

Comment: Parentheses (Score 1) 62

by dwheeler (#48593373) Attached to: Kawa 2.0 Supports Scheme R7RS

Most software developers will take one look at the excessive parentheses required for Kawa and Scheme and say "nuke it from orbit". Even Lisp advocates like Paul Graham admits that syntax like "(* (+ 1 2) (- 5 4))" is painful to deal with.

Thankfully, there *are* solutions for Scheme: SRFI-105 and SRFI-110 (which I co-authored). These are extensions to Scheme that let you keep meta programming (and syntax tree editing in an editor) with readable syntax. To my knowledge Kawa doesn't implement them, but they could be added.

Science and religion are in full accord but science and faith are in complete discord.