3 February 2012

Mail Markup Language

Benefits and Potential

Legal Status

What is it?

Intention

Business Solutions

Security

Making web applications safe is in the best interest of all organizations and the general economy. Providing a clearly defined set of web application security best practices will advance security professionals' ability to anticipate and rapidly address potential threats to their enterprise. Yuval Ben-Itzhak, CTO and Co-Founder KaVaDo

Current Security State of the Web (part 1 of 3)

  1. Symantec Internet Security Threat Report, Trends for 2010
  2. Norton Study Calculates Cost of Global Cybercrime: $114 Billion Annually

Current Security State of the Web (part 2 of 3)

  1. McAfee Threats Report: First Quarter 2011
  2. Sophos: Security Threat Report Q1 08

Current Security State of the Web (part 3 of 3)

  1. CSO Online: Software Vulnerability Disclosure: The Chilling Effect
  2. Shawn Henry, Executive Assistant Director - FBI: Responding to the Cyber Threat

Security - OWASP Top 10 for 2010 1

  1. A1: Injection
  2. A2: Cross-Site Scripting (XSS)
  3. A3: Broken Authentication and Session Management
  4. A4: Insecure Direct Object References
  5. A5: Cross-Site Request Forgery (CSRF)
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage
  8. A8: Failure to Restrict URL Access
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS)
  3. A3: Broken Authentication and Session Management
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF)
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF)
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management - This problem may get worse if email address alone is used for authentication, but otherwise this will see significant resolution
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF)
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management - This problem may get worse if email address alone is used for authentication, but otherwise this will see significant resolution
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF) - Mail Markup Language can elminate this threat
  6. A6: Security Misconfiguration
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management - This problem may get worse if email address alone is used for authentication, but otherwise this will see significant resolution
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF) - Mail Markup Language can elminate this threat
  6. A6: Security Misconfiguration - This threat can only be solved by proper security management, however the heightened security posture provided by Mail Markup Language will offer some mitigation in this area
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management - This problem may get worse if email address alone is used for authentication, but otherwise this will see significant resolution
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF) - Mail Markup Language can elminate this threat
  6. A6: Security Misconfiguration - This threat can only be solved by proper security management, however the heightened security posture provided by Mail Markup Language will offer some mitigation in this area
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection - Not a client-side related issue, though it can be largely nullified by Mail Markup Language as strongly encourages sharing of public keys in advance of PKI encryption
  10. A10: Unvalidated Redirects and Forwards
  1. A1: Injection - Solved on the client-side where the threat is least severe
  2. A2: Cross-Site Scripting (XSS) - Mail Markup Language can elminate this threat
  3. A3: Broken Authentication and Session Management - This problem may get worse if email address alone is used for authentication, but otherwise this will see significant resolution
  4. A4: Insecure Direct Object References - NA, not client related
  5. A5: Cross-Site Request Forgery (CSRF) - Mail Markup Language can elminate this threat
  6. A6: Security Misconfiguration - This threat can only be solved by proper security management, however the heightened security posture provided by Mail Markup Language will offer some mitigation in this area
  7. A7: Insecure Cryptographic Storage - NA, not client-side related
  8. A8: Failure to Restrict URL Access - NA, not client-side related
  9. A9: Insufficient Transport Layer Protection - Not a client-side related issue, though it can be largely nullified by Mail Markup Language as strongly encourages sharing of public keys in advance of PKI encryption
  10. A10: Unvalidated Redirects and Forwards - This technology will not stop websites from redirecting to malicious websites, but it can partially elminate this problem by encouraging use of email opposed to the web
  1. OWASP Top Ten Project

Mail Markup Language and Security

  1. No convention to supply scripting in the context of the document
  2. Strongly encourages PKI encryption.
  3. No malicious redirection in the context of email.
  4. Mandatory media type description and then can only be executed as that described media type.
  5. Email is inherently private
  1. No convention to supply scripting in the context of the document
  2. Strongly encourages PKI encryption.
  3. No malicious redirection in the context of email.
  4. Mandatory media type description and then can only be executed as that described media type.
  5. Email is inherently private

Nonrepudiation

Analytics

Because web analytics tools are more complex than chisels, we have leapt to the hopeful conclusion that the action of buying and installing a web analytics tool is a guarantee of online success. Insight and action are expected to be delivered by the tool, without any assistance from humans (except for buying and installing). And that's why web analytics tools are seen to fail. June Li, Click Insight

Analytics without Scripting or Cookies

In a properly designed email environment there is no need for script, tracking pixels, cookies, or other artifacts. Users and data can be tracked in one of three ways.

  1. On the email server - Email servers provide a completely different purpose than web servers. Email servers, from the perspective of content and media, should be thought of as an invisible proxy where analytics can be gathered, similar to Adobe Insight. The only difference is that the data would be more reliable on email as everything is captured without a tracking pixel.
  2. Through logging of email accounts - This would be comparable in function and limitation to web session tracking from the webserver.
  3. Tracking pixel in the content body - Spammers and marketers already do this. Without something like Mail Markup Language this is the only option for email. This is substantially less reliable than the other options and is equivalent to web analytics.

Why is analytics so different in email?

Short answer:

Short answer: different transmission model

Short answer: different transmission model

  1. Email servers know who you are by your email address
  2. Email servers are in the middle of the transmission

Short answer: different transmission model

  1. Email servers know who you are by your email address
  2. Email servers are in the middle of the transmission

Where as web servers…

  1. Don't know and don't care who you are
  2. Are a terminal point in the transmission
  3. Only job is to respond to requests and then forget about you

Simplified Email vs Web Diagrams

SMTP transfer model image/svg+xml SMTP transfer model Alessandro Vesely en SMTP Submit LMTP MTA MUA MSA MDA MX Blue arrows can be done with SMTP variations. 8 June 2010 Mail Exchanger (MX) Mail Submission Agent (MSA) Mail Transfer Agent (MTA) Mail Delivery Agent (MDA) Internet Mail User-Agent (MUA) Mail User-Agent (MUA)

HTTP transfer model image/svg+xml SMTP transfer model Alessandro Vesely en HTTP Request Response WUA Blue arrows can be done with SMTP variations. 8 June 2010 Web Server Web User-Agent Internet 1) GET Request 2) GET Response

  1. SMTP transfer model

Accessibility

The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect. Tim Berners-Lee, Co-inventor HTML and Founder of World Wide Web Consortium

What is accessibility?

  1. Accessibility is the means of providing common or alternative access to a person, place, or thing regardless of barriers from disability or inequal resource distribution.
  2. In the context of structured data, such as markup languages, accessibility is the marriage between document semantics, valid syntax, and alternative descriptions for media.

Accessibility Violations Are Expensive

  1. Sitepoint: Target Settles Accessibility Lawsuit for $6 Million
  2. Minneapolis / St. Paul Business Journal: Delta hit with $2M DOT disabilities violations fine
  3. NPR: Unfriendly Skies? Blind Passengers Sue United
  4. Law Office of Lainy Feingold: Accessibility Lawsuit Filed Against JetBlue Airways

Why is accessibility so hard on the web?

  1. Web browsers will parse anything. Proper use of syntax, much less validation, is just not important to the web.
  2. Only 4.13% of 3+ million analyzed web pages passed validation 1
  3. There is no technology requirement for accessibility on the web. It is only a business/legal requirement.
  4. Corruption and ignorance of the technology produces a culture that severely underestimates requirements planning and misrepresents the role of the technology
  1. MAMA: Markup Validation Report

Mail Markup Language and Accessibility

  • In XML any syntax violation results in a completely broken document, so syntax violations will never accumulate
  • The specification requires that instances of Mail Markup Language validate against the defining schema
  • A semantic structure is defined and enforced by the schema
  • In XML any syntax violation results in a completely broken document, so syntax violations will never accumulate
  • The specification requires that instances of Mail Markup Language validate against the defining schema
  • A semantic structure is defined and enforced by the schema
  • Mail Markup Language makes it frustrating and challenging to violate accessibility

Inherent Privacy

Privacy is not something that I'm merely entitled to, it's an absolute prerequisite. Marlon Brando, Actor

Privacy Is Not Security

Email is Private, Web is Public

Web Privacy Failure (part 1 of 2)

  1. Judith Sjo-Gaber, Bloomberg - The Real Cost of Privacy, Protecting Yourself

Web Privacy Failure (part 2 of 2)

  1. Schneier on Security: The "Hidden Cost" of Privacy
  2. Robert Gellman, Privacy and Information Policy Consultant: Privacy, Consumers, and Costs

Why has privacy on the web failed?

  1. Tanzina Vega and Verne Kopytoff, New York Times: Web Advertisers Fear Effects of Do-Not-Track System

Web Privacy: Case In Point

It is perfectly legal to access the private accounts of strangers provided the authentication data is retrieved from the web. The following is an example.

  1. Search Google using Google Diggity1 for source code with keywords amazon cloud.
  2. In the returned source code look for a secret key and an authorization key to allow automated access.
  3. If the authorization information is not found in the first search result then try the next source code result.

This unauthorized access is legal because the web is inherently public and authorization was disclosed in that public medium. The Amazon Terms Of Service2 and the Service Level Agreement3 offer no recource for this. With such access I can take your data and delete your account, legally.

  1. Google Diggity
  2. Amazon Web Services - Terms of Service
  3. Amazon EC2 - Service Level Agreement

Immunity From Web-Focused Legislation

A service provider shall take technically feasible and reasonable measures designed to prevent access by its subscribers located within the United States to the foreign infringing site (or portion thereof) that is subject to the order, including measures designed to prevent the domain name of the foreign infringing site (or portion thereof) from resolving to that domain name's Internet Protocol address. Such actions shall be taken as expeditiously as possible, but in any case within 5 days after being served with a copy of the order, or within such time as the court may order. H.R.3261, Stop Online Piracy Act

Email = Due Process, Web = Civil Liability

Ownership

Data ownership refers to both the possession of and responsibility for information. Ownership implies power as well as control. The control of information includes not just the ability to access, create, modify, package, derive benefit from, sell or remove data, but also the right to assign these access privileges to others. David Loshin President, Knowledge Integrity, Inc.

Web Service Providers Are the Data Owners

Google's New Universal Terms of Service

Privacy From New Google TOS

  1. Google Terms of Service

Semantic Data

The Semantic Web is a web of data. There is lots of data we all use every day, and it is not part of the web. I can see my bank statements on the web, and my photographs, and I can see my appointments in a calendar. But can I see my photos in a calendar to see what I was doing when I took them? Can I see bank statement lines in a calendar? Why not? Because we don't have a web of data. Because data is controlled by applications, and each application keeps it to itself. Semantic Web Activity, World Wide Web Consortium

Semantic Web and WWW, Not Compatible

  • The primary technology, RDF, was initially completed in 1999 and the vision for the Semantic Web was formalized in 2001.
  • The primary technology, RDF, was initially completed in 1999 and the vision for the Semantic Web was formalized in 2001.
  • More than a decade later there is still no semantic web.

Why did the semantic web fail?

Semantic Web Email

Summary