- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 24 Dec 2013 19:55:43 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Robert O'Callahan <robert@ocallahan.org>, public-fx <public-fx@w3.org>, www-style <www-style@w3.org>
On Dec 13, 2013, at 11:47 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Fri, Dec 13, 2013 at 1:48 PM, Robert O'Callahan <robert@ocallahan.org> wrote: >> On Sat, Dec 14, 2013 at 8:11 AM, Tab Atkins Jr. <jackalmage@gmail.com> >> wrote: >>> That's silly. There's no reason to break currentcolor just because >>> :visited is being used. Plus, depending on implementation strategy, >>> actually getting the sanitized color is expensive (as you have to >>> rerun style matching, excluding all rules with :visited in their >>> selectors). >> >> FWIW, it's essential that getting the sanitized value be exactly as >> expensive as getting the regular value. Otherwise you open yourself to >> timing attacks. > > Bah, that's true. That means tracking two values for anything that > needs sanitization, unfortunately. I really wish to have currentColor behave in a way that it does not reveal any secured information. If we do not find an agreement, a way to limit the security restriction further would be to the following: For feFlood and feDropShadow: If the value for the ‘flood-color’ property computes to ‘inherit’ or ‘currentColor’ the feFlood filter primitive must be marked as tainted. For fe*Lighting: If the value for the ‘lighting-color’ property computes to ‘inherit’ or ‘currentColor’ the feFlood filter primitive must be marked as tainted. It is already rare that people use inherit or currentColor for the named properties. Thankfully, both properties are not inherited. Would that be exceptable for now? Greetings, Dirk > > ~TJ
Received on Tuesday, 24 December 2013 19:56:25 UTC