24 ms·

The email address format is so useful for domain-based identity. We still haven't squared Zooko's Triangle. What is the practical way to get a function like "d

The email address format is so useful for domain-based identity. We still haven't squared Zooko's Triangle. What is the practical way to get a function like "document was sent with best effort for some legal purpose to a known party"? Are we just stuck with "login to the secure messaging site" emails from our banks?

tptacek 9y ago
Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.
- slavik81 9y ago
  There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox. How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel? My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser developers telling you to avoid browsing unknown websites, so they were forced to build a good sandbox. But, I don't really know. I'm just really disappointed by OS security.
  - tptacek 9y ago
    There's an enormous difference, and it's not just the sandbox; it's also that the viewer application is: * Written in a language other than C * Doesn't have any access to your local system by design, not as a consequence of sandbox rules * Is maintained serverside, so everyone gets patched instantly
    - slavik81 9y ago
      Regarding your first point, would a website written in C and compiled to JavaScript have the same security issues? I'm wondering whether a middle layer can fix the problems you have with C, or if they're inherent to any use of the language.
  - sjwright 9y ago
    It's the operating system's job to protect itself from userland, as well as to protect userland from other userlands. It's generally not its job to protect your documents from your applications. Normal people don't worry about malware rooting their OS. Normal people worry about malware ruining their un-backuped photos and work docs, something that few operating systems dare protect users from. (Which is why the iOS model of computer security is IMO a sleeper breakthrough, and why I always always recommend iPads/Chromebooks to people I wouldn't trust to not download Comet Cursor.)
    - dredmorbius 9y ago
      Except that we went through this in the 1990s and: 1. Highly-interactive, programmatic, cross-connected documents were (security-wise) a Very Bad Thing. 2. Secure systems divorced viewing of documents from either editing them or running code. Mostly. Windows didn't do this, and ended up with massive security issues, but the systems were largely not massively interconnected. Yes, they were on business LANs, and yes, there were connections to some other systems (largely through email), but not today's "everything is on the Web and you're connecting to 100s or 1,000s of remote sites daily". Unix systems, generally, did enforce separation. They were also typically more interconnected (remote filesystems, ftp, telnet, early SSH, early Web), but there was some sanity in data/code separation. Unix systems could produce and view Postscript and PDF documents. Windows systems ... mostly couldn't. If you wanted to view a Word document, you either printed it out, or you opened it in MS Word. Microsoft did, yes, make a read-only viewer application. If you tried to, say, scroll through a document by hitting the spacebar, it would pop up a dialog telling you you couldn't edit the document. Every. Fucking. Time. You. Hit. Space. I nuked that mofo so fast. "less" with catdoc or mswordview worked well enough for me. I'm not claiming that 1990s Unix / Linux systems had sufficient process/data separation or sandboxing for today's network environments. They didn't (and we've got the scars to show for it). But they were following a more appropriate tack, and did in general foster environments where documents weren't openly dangerous. (Again: mostly, there were exceptions, but they also pushed limits and took things in directions that weren't generally intended by the software designers, in sharp contrast to Windows.)
- dvanduzer 9y ago
  I guess I'm asking if you've written Signal or any other mode of secure messaging into a contract explicitly, in some kind of sufficient notice clause.
cmroanirgo 9y ago
> The email address format is so useful for domain-based identity. Agreed. But this is also where the problems of spam begin. Perhaps if we chose to 'phase out' MX records in DNS for something new, say 'MSG'. A domain could then have an MX as well as a MSG server... A local MTA would route to the 'new shiny messaging system', so that clients could use the one system to read emails. Remote MTAs could also lookup and see if there's a 'MSG' on the receiving end and talk to it instead, rather than the designated MX, increasing the security. (In this case the sending user would still be sending via a normal email client) Ideally, everyone will migrate over to MSG, upgrading the world smoothly. (I figure something like this has already been tried tho...?) 2c.
- dvanduzer 9y ago
  Bayesian filters solved this problem. My only email volume problem anymore is entirely opt-in / self inflicted. Some percentage of global bandwidth is still wasted on spam, but it is a vanishingly small proportion of traffic for that to matter anymore. ¯\_(ツ)_/¯

tptacek 9y ago

Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.

slavik81 9y ago
There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox. How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel? My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser developers telling you to avoid browsing unknown websites, so they were forced to build a good sandbox. But, I don't really know. I'm just really disappointed by OS security.
- tptacek 9y ago
  There's an enormous difference, and it's not just the sandbox; it's also that the viewer application is: * Written in a language other than C * Doesn't have any access to your local system by design, not as a consequence of sandbox rules * Is maintained serverside, so everyone gets patched instantly
  - slavik81 9y ago
    Regarding your first point, would a website written in C and compiled to JavaScript have the same security issues? I'm wondering whether a middle layer can fix the problems you have with C, or if they're inherent to any use of the language.
- sjwright 9y ago
  It's the operating system's job to protect itself from userland, as well as to protect userland from other userlands. It's generally not its job to protect your documents from your applications. Normal people don't worry about malware rooting their OS. Normal people worry about malware ruining their un-backuped photos and work docs, something that few operating systems dare protect users from. (Which is why the iOS model of computer security is IMO a sleeper breakthrough, and why I always always recommend iPads/Chromebooks to people I wouldn't trust to not download Comet Cursor.)
  - dredmorbius 9y ago
    Except that we went through this in the 1990s and: 1. Highly-interactive, programmatic, cross-connected documents were (security-wise) a Very Bad Thing. 2. Secure systems divorced viewing of documents from either editing them or running code. Mostly. Windows didn't do this, and ended up with massive security issues, but the systems were largely not massively interconnected. Yes, they were on business LANs, and yes, there were connections to some other systems (largely through email), but not today's "everything is on the Web and you're connecting to 100s or 1,000s of remote sites daily". Unix systems, generally, did enforce separation. They were also typically more interconnected (remote filesystems, ftp, telnet, early SSH, early Web), but there was some sanity in data/code separation. Unix systems could produce and view Postscript and PDF documents. Windows systems ... mostly couldn't. If you wanted to view a Word document, you either printed it out, or you opened it in MS Word. Microsoft did, yes, make a read-only viewer application. If you tried to, say, scroll through a document by hitting the spacebar, it would pop up a dialog telling you you couldn't edit the document. Every. Fucking. Time. You. Hit. Space. I nuked that mofo so fast. "less" with catdoc or mswordview worked well enough for me. I'm not claiming that 1990s Unix / Linux systems had sufficient process/data separation or sandboxing for today's network environments. They didn't (and we've got the scars to show for it). But they were following a more appropriate tack, and did in general foster environments where documents weren't openly dangerous. (Again: mostly, there were exceptions, but they also pushed limits and took things in directions that weren't generally intended by the software designers, in sharp contrast to Windows.)
dvanduzer 9y ago
I guess I'm asking if you've written Signal or any other mode of secure messaging into a contract explicitly, in some kind of sufficient notice clause.

cmroanirgo 9y ago

> The email address format is so useful for domain-based identity. Agreed. But this is also where the problems of spam begin. Perhaps if we chose to 'phase out' MX records in DNS for something new, say 'MSG'. A domain could then have an MX as well as a MSG server... A local MTA would route to the 'new shiny messaging system', so that clients could use the one system to read emails. Remote MTAs could also lookup and see if there's a 'MSG' on the receiving end and talk to it instead, rather than the designated MX, increasing the security. (In this case the sending user would still be sending via a normal email client) Ideally, everyone will migrate over to MSG, upgrading the world smoothly. (I figure something like this has already been tried tho...?) 2c.

dvanduzer 9y ago
Bayesian filters solved this problem. My only email volume problem anymore is entirely opt-in / self inflicted. Some percentage of global bandwidth is still wasted on spam, but it is a vanishingly small proportion of traffic for that to matter anymore. ¯\_(ツ)_/¯