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>
