Re: Color Management for iPad? / securiry issues
Re: Color Management for iPad? / securiry issues
- Subject: Re: Color Management for iPad? / securiry issues
- From: Jan-Peter Homann <email@hidden>
- Date: Tue, 09 Aug 2011 10:21:04 +0200
Hello to all,
Like Graeme, Toms arguments concerning ICC-profiles and security issues
for mobile devices are not convincing me:
1) W3C Standards are allowing explicitly the usage of ICC-profiles in
documents for the web
2) Basic ICC support in Browsers for desktop systems like e.g. Safari
and exist since two years
Tom, is your intention as an member of the ICC board, that W3C should
change the existing web standards for mobile devices, by not allowing
ICC-profiles to be embedded in content, which is rendered on the client
side ?
Regards
Jan-Peter
Am 09.08.11 01:27, schrieb Graeme Gill:
Tom Lianza wrote:
Hi,
There are two distinct issues here. On the server side, one assumes that
the builder of the web page is responsible for content so security per se is
not that much of an issue, except that the ICC profile allows for
proprietary tags so by definition, there is a potential issue with unknown
BINARY data and a potential for downstream corruption.
I don't really see this. Proprietary tags exist within the tag framework,
and can/will be ignored.
On the client side,
if you are going to execute a fully color managed workflow inside the
application, the web application/browser, must interact with specific client
generated data, this is a security no-no. There are fairly well defined
mechanisms for accepting specific client data (desktop physical extent, etc)
that is absolutely necessary for the browser to run. Opening and capturing
an ICC profile is NOT one of those secure API's.
Sorry, I'm not really following you. There is no need for client
data like a source ICC profile to be taken within a secure context (kernel).
System services for such things can (should!) run as user mode.
It isn't that difficult to parse an ICC profile in secure manner
(ie. avoiding any possibility of buffer or integer overflow) if
the right approach is taken.
different APIs for color management, so the code that was specifically
designed to be non-OS specific suddenly becomes very specific. If you look
into the WebKit code, you will see some of the specific issues. It can be
handled on a platform, by platform basis, but it is quite a bit of work.
That seems to be the story with color though, programmers are lazy about it.
They're lazy in understanding it, lazy in using API's that exist,
and lazy in standardising it. If all you are dealing with is RGB display systems,
and the hardware folks have made them (sort of) respond a bit like sRGB,
then it's tempting simply to ignore the whole thing (which seems what's
happened with iOS).
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
---------- Please note the new adress --------------
homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden