Burning-After-Reading Element

HTML
1

Burning-After-Reading Element

Author: DONG Wenyu, Chinamobile

1, Requirements
In services like social web, e-commerce or web-based messaging, people need browsers to make sure that some specific sensitive data will be destroyed after being presented for a period of time and cannot be recovered by the recipient users. Such data are called to be Burning-After-Reading. Obviously Burning-After-Reading data shall not be downloaded, stored or forwarded. Exemplar cases can be sharing private photos between intimate friends, copyright protection, and sharing bank accounts or other certificates in e-commerce.

Burning-After-Reading requires native support of browsers, and shall not rely on JavaScript since JavaScript can be manually disabled.

2, Procedure
It requires two phases to fetch a Burning-After-Reading element.
(1) Phase 1: Metadata Declaration
To prevent feeding non-applicable browsers with Burning-After-Reading elements, web servers shall place metadata in the original HTML instead of Burning-After-Reading contents.

(2) Phase 2: Fetching Burning-After-Reading elements
Browser gets metadata of Burning-After-Reading elements.
a) If the browser supports Burning-After-Reading, by analyzing the metadata, it can derive the real URI of the Burning-After-Reading elements, issue a subsequent HTTP request which will succeed in the verification process by the web server, and fetch, present and then destroy the Burning-After-Reading elements.
b) Otherwise, the browser cannot derive the URI, or the URI is incorrect and will fail in the verification process by the web server. Thus the browser cannot get the desired Burning-After-Reading elements

3, Specification
(1) Metadata
A new element is introduced as metadata of Burning-After-Reading.
< Burning-After-ReadingMeta URIBase=”xxxx” version= “yyy” challenge=”zzz” />
URIBase: URI base of the Burning-After-Reading element.
Version: relating to policies to fetch Burning-After-Reading elements. For example
Version…Policies
1.0…Simplified Burning-After-Reading. Fully rely on the browser’s willingness and cooperation to achieve Burning-After-Reading, no challenge-response required.
2.0…Testified Burning-After-Reading (solution XXX). Ensure the browser’s capability to support Burning-After-Reading by employing challenge-response (solution XXX)
3.0…Testified Burning-After-Reading (solution YYY). Ensure the browser’s capability to support Burning-After-Reading by employing challenge-response (solution YYY)
Challenge: challenge parameters

< Burning-After-ReadingMeta> shall support attributes like ‘hidden’ to make it invisible.

(2) Subsequent HTTP request
The browser derives the real URI with necessary results for challenging, from the version and challenging parameters. The browser issues a subsequent HTTP request like:
http://…/derived-uri?BARResp=derivedresp
BAFResp: the results as response to the challenging, which will be used by the web server to testify.

(3) Burning-After-Reading elements
A new element is introduced to represent Burning-After-Reading contents. For example,
< Burning-After-Reading disptime=”xxx” >
< DIV>……< /DIV>
< / Burning-After-Reading >
disptime: the time period of displaying before the content is destroyed.

It is recommended that < Burning-After-Reading> shall be only accessible by the browser itself, and shall not be accessible by JavaScript exploring the DOM tree.

4, Use cases
(1) Simplified Burning-After-Reading
The simplified Burning-After-Reading policy does not require challenging-response procedure. So relevant fields are optional.
a) Original HTML:
< !—when version=1.0, challenge can be neglected. This element is invisible -->
< Burning-After-ReadingMeta URIBase=”xxxx” version= “1.0” hidden=”true”/>
b) Subsequent HTTP request:
In this case, no response result is required.
c) http://…/derived-uri
d) Burning-After-Reading content:
< !-- destroy after 10 sec of displaying -->
< Burning-After-Reading disptime=”10” >
< DIV>……< /DIV>
< /Burning-After-Reading>

(2) Testified Burning-After-Reading
The testified Burning-After-Reading policy requires challenging-response procedure.
a) Original HTML:
< !—when version=2.0, challenge can be neglected. This element is invisible -->
< Burning-After-ReadingMeta URIBase=”xxxx” version= “2.0” challenge=”abcdefg1234567” hidden=”true”/>
Note: “abcdefg1234567” is the mock example of challenge parameter.

b) Subsequent HTTP request:
In this case, the response result is required.
http://…/ derived-uri?BARResp=7654321gfedcba
Note: “7654321gfedcba” is the mock example of response result.

c) Burning-After-Reading content:
< !-- destroy after 10 sec of displaying -->
< Burning-After-Reading disptime=”10” >
< DIV>……< /DIV>
< /Burning-After-Reading>

1 Like
2

This is DRM, and effectively impossible.

3

hi, how is the WEB’s general philosophy about DRM ? ignore DRM at all ? or where can i find some clues? thank you

4

DRM is impossible (without removing the concept of computer ownership entirely). The attempts at it that exist in the web platform are limited to decoding video, which customers demand on pain of switching browsers, and which there is no other alternative. In other words, it’s extremely high-value for browsers to support, despite the high costs, plus browsers don’t actually care whether the DRM is broken or not - they just care that they’ve implemented it well enough that videos play.

Implementing DRM for a low-value feature that doesn’t work even on native apps (see all the Snapchat-capturing tools), and for which there is the expectation that it’s actually secure and unbreakable, is exceedingly unlikely.

5

I agree that a DRM solution here is both implausible and undesirable. But what about the simpler notion of indicating ephemerality in a way that isn’t guaranteed? I think there are privacy advantages to such a feature (like in Snapchat) even when everyone accepts that it’s possible to take screenshots.

That said, I think site developers could build ephemeral messaging in specific applications/websites using JavaScript. Are there any use cases where it would make sense for it to be a specific element and have the browser do the ephemeral disposing?

6

the timing for any such proposed disposing needs to be adjustable, as per http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-required-behaviors

1 Like