W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14364] Add an API to make appcache support caching specific URLs dynamically

From: <bugzilla@jessica.w3.org>
Date: Fri, 07 Oct 2011 12:35:39 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RC9eN-00054y-79@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364

Philipp Hagemeister <phihag@phihag.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phihag@phihag.de

--- Comment #2 from Philipp Hagemeister <phihag@phihag.de> 2011-10-07 12:35:38 UTC ---
Wouldn't that allow anyone to hijack a website forever?

1. Attacker temporarily gains control over the content of http://example.com/ ,
and writes

<html manifest="data:text/cache-manifest;base64,Q0FDSEUgTUFOSUZFU1QK">
example.com defaced!
</html>

2. User visits http://example.com/, puts the page in appcache.

3. Rightful owner of example.com regains control (or domain ownership changes
if the domain was hijacked, ...).

4. User visits http://example.com/, still sees defacement.

How can the rightful owner of example.com ever serve the user anything?


On the other hand, locking the content (and scripts) of a website forever could
also provide benefits to a carefully-engineered project. JavaScript on the page
could somehow download the new version, cryptographically verify it (beyond
SSL, which may be compromised by .gov actors, like google.com in Iran
recently), and only then update to the new version.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 7 October 2011 12:35:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC