#WhatsApp is being educated in full-disclosure

The first lesson is always the hardest…

via WhatsApp Status Changer.

Since a while there are rumors about leaks in the ‘amazing’ and free-to-use app WhatsApp. The engineers of WhatsApp are telling their customers that they will fix it as soon as possible while it’s been a long time now. So on this website we will show you one of the major leaks of WhatsApp. You can simply change anyone’s status message by just entering the phone number of the person and the new status message. Just try it out and you’ll see the status being changed directly.

Confirmed: #XSS in #Tweetdeck reading #Facebook feeds to Web client

UPDATE: Context and background now posted at Computerworld.

Following on from the discovery and the previous posting, see below; original content is in my feed somewhere but looks like:

<iMg Src=http://localhost/nope.gif onerror='javascript:alert("happy now ben?")'>

Twitter have had XSS bugs before, not Tweetdeck as far as I am aware – but then they used to have a proper client as opposed to a web interface.

Graham Cluley will doubtless be along shortly to tell us how [insert product name here] can protect us from all the stupid things that programmers do and fix only once.


Faint possibility of #XSS in Web #Tweetdeck client via #Facebook? #security

UPDATE: Confirmed. See this posting. Hat tip to @glynwintle for inspiring me to get off my arse and at least write it up.

I really can’t be arsed to investigate this one, but I raise it for general interest.

See this screencap:

At the top my original tweet as-rendered by web-tweetdeck client, wherein I type HTML as part of a tweet.

Immediately below is the tweet same reflected back from my twitter-send-to-facebook-feed then sucked back in by tweetdeck and rendered in the web client.

Something, somewhere, has decided that my in-tweet HTML deserves to be rendered.

It could be that there is a whitelist, but if there is it’s not very clever:

Let me repeat what I’ve written in this blog before – ANYTHING that takes my tweet content and tries to interpret it is doing it at its own risk.

Tweets should be taken and treated and rendered opaquely.

Compare the onMouseOver bug from last year.

Performance Art: Why Secure E-mail Never Went Mainstream…

…or “Why Johnny doesn’t want to encrypt.”

There’s been a been a thread on Perry Metzger’s “CRYPTOGRAPHY” maillist, about “Why the poor uptake of encrypted email?”.

There was the usual citation of “Why Johnny Can’t Encrypt” (summary: cryptography is hard for people to grasp and harder for programmers to make user-friendly) – but because of my work on Adriana’s Mine Project I see another reason which is not really covered in the paper.

To try drive the point home I submitted my response encrypted under rot13, and bless him Perry was kind enough to post it on verbatim without querying it.

So what I have done by “protecting” that message with cryptography is deny it indexing by Google (cf: deny it integrated search like Spotlight) – make it harder to find, read, quote… all the same side-effects that “secure” e-mail imposes upon a secure e-mail’s recipients in pursuit of solving a transport security problem.

I attach the (unencrypted) body of the e-mail, below; the final few paragraphs are the key ones for the next decade of computing.

I believe there are some fundamental axioms, or postulates of computing that are flat-out wrong – or will be, soon – but which strongly inform our notions of “how computing should be”; to me these are like the the “parallel postulate” of Euclidean geometry – when they fall, when the world suddenly sees their “self-evident” nature is false, then exciting things will happen.

What are these computational parallel-postulates? Stuff like:

  1. users can’t be online 24×7 (cf: ADSL, hosting providers)
  2. (also phrased as) connection time is prohibitively expensive (ie: dial-up)
  3. users are not able / not allowed to serve information to third-parties (cf: blogs, feeds, apache)
  4. users can’t afford to host a server to act upon their behalf (cf: hosting, iPhone)
  5. users can’t store heaps of data (cf: terabyte hard disks)
  6. secure end-to-end communication is not possible between servers / across the internet (cf: im, skype)
  7. the client-server programming model means we should implement hierarchies, not peer-to-peer meshes (iTunes Store vs: Bittorrent) [updated 1]
  8. the web is a series of hierarchies, not a mesh (also known as the “deep linking is bad” argument) [updated 2]
  9. computers need to be rebooted daily/weekly [updated 3]

[ed: I am adding extra entries to the above list, denoted with square brackets]

…and a host of others; I could spend a day enumerating these fallacies and defunct limitations. Almost the entire identity-provider industry is based upon numbers 1, 3, 4 and 6 – whilst people gape at the extraordinary power of Bittorrent and the shocking proposition of OpenID without seeing them as logical consequences of overturning numbers [1,2,3,5,7] and [3,4,6] respectively.

This is one of the reasons I like The Mine Project – it kicks over a bunch of those rules – most, perhaps all of them – and in such a new space very exciting things may happen.

Anyway – herewith the e-mail:

Beyond the “Why Johnny” paper – focusing upon usability – I think there is a higher problem of interoperability and information-access at play here.

There can be no access to your mail without use of a client if you are using cryptography – even ROT13 – and this alone is a big problem, because mediated access to your e-mail is *really* painful.

For some 15 years I used mh/nmh/exmh (latterly with fetchmail), then moved to Mail.app, recently tried Thunderbird for a few months, and am re-considering nmh for long-term archiving of e-mail. I also use my iPod, three laptops with varying species of Unix, and a 3G phone to access e-mail. Occasionally I still copy stuff out of /var/mail/.

I would have suffered immensely were I required to use a particular crypto-enabled client to deal with my e-mail at each stage, or were I required to use historical crypto-clients to access older mails.

Anyone whose college thesis is in WordPerfect on a 5.25″ floppy at the back of a closet somewhere, should understand this problem.

To this day Project Gutenberg uses flat ASCII as a lowest common denominator format, and similarly I need my e-mail in the simplest form so that I can grep it, perl it, quote it and search it.

So “why has encrypted e-mail failed?” I suspect that static data encryption revolts against the nature of personal communication and the needs of personal information re-use.

For comparison, consider the convergence of instant messaging and e-mail – they are becoming ever more alike, but the former mostly relies upon end to end transport security, often assuming that the privacy of logs at either end are at the whim of *that* user.

For some reason this works rather well; as security geeks we complain about it, but there have been many times when Skype has bailed me out of trouble with its ability to drill through almost anything and provide me with messaging and file-transfer.

Similarly AIM, Jabber, GChat – all of which I happily run with OTR – give me necessary mostly-secure communication.

In the world of e-mail the problem is that the end-user inherits a blob of data which was encrypted in order to defend the message as it passes hop by hop over the store-and-forward SMTP-relay (or UUCP?) e- mail network… but the user is left to deal with the effects of solving the *transport* security problem.

The model is old. It is busted. It is (today) wrong.

It’s like ordering lobster bisque, and having a live lobster turn up at your table; what you want is in there – heavily armored – and yes you can render what you receive into what you actually desire; BUT it’s messy and you’re really stuck unless you have a mouli, a saucepan and a small PGP hotplate at hand.

And of course you have to archive copies of the lobster, not the soup.

S/MIME and its bretheren exist to simultaneously address the security of [both] data in motion and data at rest – but people don’t want the latter in the form that it provides, because it inhibits interoperability and usability at a level above the “this software sucks” matter…

And if the “data in motion”/”end to end” security issue is being addressed by things like IM/OTR and Skype, then perhaps “secure” e-mail will soon go the way of Telnet and FTP?