[This is getting a little bit off-topic for CHI-WEB. If anyone feels
disturbed, please tell me so we can take this to private email.
Nevertheless I feel that security definitely is/should be an issue
in CHI when privacy or financial concerns are involved.]
derek bambach <[log in to unmask]> writes:
> At 10:13 PM 8/26/98 +0200, Jo Meder wrote:
> it's not a question of application vs. OS-level security - it is a
> problem inherent in the way the web works and the way browsers work.
I beg to differ. You *cannot* have any kind of security that is worth
being called that way if your OS is insecure. Once you have a (reasonably)
secure OS you can continue and implement (or use already present) secure
protocols for communication across networks. Anything else, especially
implementing a simulation of security atop a heap of insecure software
effectivley says you're declaring your customers too stupid for you to
bother with real security: "If they accept the simulation as "good enough"
why not pass it as actually secure."
> the fact that you can "back up" to a previous page is a serious design
> concern when you are dealing with time-critical data.
Sorry to interrupt you, but you *cannot* do anything time-critical
with TCP/IP since this protocol does not guarantee delivery of data
within a certain window. Sure, you can again simulate this, by
providing appropriate fallback measures like updating stock-prices and
issuing a warning if the transaction takes too long.
> "backing up" is not inherently bad -
You only have a problem with backing up if you stick to classical
application models while programming for the internet. This does not
work, never did and never will given current transmission protocols.
> it's just that we are using the web to deliver more then just
> research papers, so backing up becomes a little more touchy.
Would you please stop trying to belittle others from your oh so
superior point of a "web application designer"? This distinction
between "application" and "research papers" is as much a strawman as
the famous "purist vs. bleeding edge" discussion on abuse of
structural markup for presentational issues.
> you may not trust the web to do financial transactions, which is fine, but
> the industry is betting on the fact that hundreds of millions of people
> WILL do financial transactions on the web.
So "the industry" is betting on the stupidity of the people. You seem
to be telling me that people don't know anything about security in
networked transactions and therefore don't need it. Please tell me I
misunderstood you, please!
> and further, they will be doing it *before* the web is significantly
> more advanced.
There is no need for "the web" to advance. Use a reasonably secure
OS. Use SSL. Use strong encryption. Given these you could even allow
changing computers during a transaction.
> no, but i CAN ensure that a page that has time-critical information or
> personal (confidential) information never caches in the first place
Sorry, but you can't. And even if you could, what can you do about all
the computers your confidential data passes on the way to your
customer?
> - so it CAN"T come out of the cache when you "go back" - it has to
> come from the server again. and if it's a secure session, this can
> DEFINATELY cause problems.
You know, using a browser is not the only way to access information
stored on a computer. If I really were eager to access confidential
information on someone elses computer - which I am not - I'd really
know better than to use a browser. So know you're not only declaring
your customers stupid, you're doing the same for potential intruders.
> HTML/HTTP (and IP protocals in general) are *not* suited for what we
> are using them for. BUT we *are* using them and will continue to
> expand how we use them.
I guess you know the saying about the person only possesing a hammer:
all the world is a nail to him.
> we cannot alter the fundamental process of HOW you buy or sell a security
> (i suppose we could lobby the SEC and the federal gov't, but that seems
> like a bit of a waste of time, dont you think?). so what would you suggest?
As I said before: Use something different. At least use a Java-Client
that utilizes strong encryption, that stores decoded data only as long
as it is absolutely necessary, don't claim security where there is none.
[personal abuse snipped]
> i think when a 100 billion dollar bank comes to you and says
> "build us an internet-based securities trading system" we say SURE. YES.
> WOULD YOU LIKE FRIES WITH THAT? we dont say "no sorry, the only way we
> could design it would be kind of offensive to your end users."
This is, in case you didn't notice, not about "nice" or "offensive"
design anymore. This is about design that passes the notion of being
secure while actually being as insecure as it can get.
> do you really think the financial services industry thinks they are
> not going to be successful?
They're inviting any lawsuit you can imagine if they go along your
lines.
> do you really think that all web trading applications are going to
> fail??
Where did I suggest that? I simply questioned the way to design such
applications you seem to favour.
> for as long as the log-in session is valid.
So how do you determine when a "log-in session" is no longer valid on
a stateless protocol? This is not technically feasable.
> who are we to tell end users that they HAVE TO upgrade.
So you sacrifice security to a lie. Fine. Go ahead. I should start looking
around for someone using your products. My dream might come true and I
might be rich sooner than I expected.
> you're talking about a population with an attention span of about 13
> seconds.
Hmm, perhaps you're right. Perhaps someone who cannot be bothered to
pay attention for more than 13 seconds deserves to be ripped of.
> >Use something else.
> sure. just as soon as you invent it for us.
It's all there: asymetric strong encryption, reasonably secure os,
encrypting protocols, no need for me to invent something. (Shows that
you really know what you're talking about.)
Jo
|
