Re: Disavowing Legal Liability [OT]

> The "two factors of uncertainty" really aren't. We successfully deliver a

The point I was making is that your company has taken *a calculated risk* of
someone not being able or wanting to fulfill the strict requirements for
your service, which now seems to be hitting you rather hard. I have been
taught the Web programming philosophy of never relying on anything that is
not under my control, with my control ending at the server. Any data being
sent or not sent from the Client is not under my control. I wanted to
realize a login system relying on Cookies for a customer but was warned that
the Cookies could be changed or simulated and that I should never trust
Referrer or User-Agent strings because they are just text being sent that
does not necessarily have to have any meaning. And this is not only of
philosophical nature but of a very practical one. I am quite familiar with
Java Servlets, Active Server Pages, PHP and so on. All of them make it quite
easy to use Cookies without ever thinking about how they work. You just call
the appropriate methods and they are sent to the Client and you expect them
to be sent back the next time. But that's the whole problem.
As a webmaster I have learned to expect the unexpected which in this case is
that I might receive garbage or nothing at all. You can simulate this using
the WinNT Telnet client on Port 80 and will see for yourself that this
indeed is a factor of uncertainty and deep security concern. For my main
customer at the moment it is important to have a broad range of users access
its site. So from the beginning we also had to keep in mind Lynx, set-top
boxes (MHP has just been agreed on today) and users with "weird" settings.
No user could be blocked off just because he was not using IE8 or
JavaScript9 or Java 3.4.5; others made their site only accessible with IE4+
and Flash5 and called us crazy, but our concept of ignoring statistics and
common practices has now proved to be good, as visitors do use public
systems using old browsers even if some industry statistics show large
numbers of IE5 and N6 users.
All this precautionary work of mine has been a pain in the neck so that I do
not understand people that have taken the easiest way at that particular
moment and are surprised to fall on their nose and now start making a big
fuss about it, blaming others for their own decisions. (you might not be
responsible for your company's decision, but there are others I have talked
to)

I don't see any substantial difference between Cookies and JavaScript. Both
can be disabled or not supported and are not part of the widely adopted
HTTP. And both are being changed - I'm thinking of RFC 2109 vs. RFC 2965
(Oct. 2000) here.

I'm not saying P3P was easy to implement. But I can tell you the current
draft is rather simple compared to some of the first drafts that required
active HTTP negotiation between Client and Server! ;-)
And in the end, W3C is not responsible for any particular P3P user agent
implementation accepting or not accepting any particular policy that should
actually work.

> BTW, Andreas... I hope I didn't come off to rough. I have tried hard to
get
> this working and seem to have the CP 'right' now, yet no success. To hear
> 'track session a different way' was only frustrating. We have considered
> that, but can't right now and never foresaw such a difficulty with such a
> simple technology.

And no, I am not angry and hope not to offend you by anything specific I
write. The two of us have different angles of view on this subject and I am
just freely writing my opinion (just as you are), which of course is not
independant of my ways of work as not being a Third Party but a "First
Party", if one can say so. I respect your view and situation and would
surely try to help you implement P3P and work around the IE problems if I
had knowledge of how to do this in the situation you described. Concerning
IE6's support of CPs I regret not being of any help at this moment as I am
currently waiting for the Windows 2000 version of IE6 to be released through
Windows Update to not loose the Win2k-specific features.

Me too, I have had serious problems while implementing P3P. Some of those I
traced back to UTF-8 BOMs. ;-) Another problem was putting the Headers out
there without using Apache's mod_header or any equivalent. Currently I'm in
the process of migrating the site to a new location, currently having to
rewrite the P3P policies and all HTML references to them.

Did I say you SHOULD track sessions a different way? :) I'm quite sure I
only said, in other words, that if you insisted on using only Cookies you
would have to live with the consequences resulting from rejected Cookies
back then, now and from now on in case you didn't provide an alternative way
of moving your data around.


Last but not least I do need to share one additional point that is not
directly related to the user agent part I talked of earlier. One of my
customers has most of its computers sealed off with what they call a data
airbag. It's a hardware device by a Taiwanese company built into the
computer that caches all data written to hard-drive. If the computer is
turned off and switched on again the data is lost. I had worked out a Forum
for them that relied on Cookies but it showed it was not of any use because
all the Cookies were lost each day although users were using the latest
browsers. That, for my part, was a strong reason against Cookies in my
particular situation.


Andreas Färber

Received on Thursday, 20 September 2001 18:24:06 UTC