At 01:14 AM 8/28/98 +0200, Jo Meder wrote:


you are confused. you seem to think that because we are using a web browser
to deliver financial information that it is not secure. how could we have
gotten approved by government regulators and licensed by some of the
world's largest financial institutions if we weren't building a secure
system? that's rediculous. every one of your arguments seems to imply we
are putting information thru unsecure channels. you do not need a java
client to have an HTTPS session or to deliver secure data. we don't need to
store much on the end user's machine at all, but if we did it would be
encrypted (just like the cookie is encrypted). we've never been hacked.
security of the system is not an issue we struggle with - there are much
more difficult design problems then that.

whether we open multiple browser windows or not is a much more critical
design concern, for exmaple.



>> 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."

what "simulation" are you talking about? i have no idea what you are
talking about at all. "real" security? tell me *anything* about the
security protocols in our system - anything at all. please.




>> 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.


that is meaningless. you CAN do time- critical reporting on the web - if i
give you a stock quote now that says $10 a share, and i give you a quote in
2 minutes that says $10.75 a share (already delivered and displayed on your
browser), i dont want you to "back up" to a screen that looks remarkably
similar, but has that $10 a share price on it, because that would be wrong.
see? if you go back, because the page was not cached (yes, i *can* do
that), you DO NOT get the page from the cache - you initiate a new server
call and get a whole new stock quote. brilliant, i know.

you'd better tell all those programmers and venture capitalists who are
sinking billions of dollars and hours into real-time audio/video delivery
systems that you "*cannot* do anything time-critical with TCP/IP". they
seem to think they can.



>> "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.

what? classical application models? internet programming? why are you
making this so complicated? the ONLY problem with backing up is how
browsers behave when you do it. sometimes backing up will give you a valid
web page with useful or "correct" information, and sometimes backing up
will give you an invalid page or 'expired' data. it's that simple - nothing
more, nothing less - and that, in and of itself, is not even a problem.

the only problem is CONTEXT (or content) related - that is, in some cases
(a research paper) it doesnt matter if you back up to an "old" version of a
page - the content couldn't have changed so it doesn't matter if it comes
out of the cache or off the server. but in other cases, the content COULD
have changed, so it DOES matter if you back up to an "old" version. and in
other cases still, it matters so much, that we dont let it happen - there
is no "old" version of the page to back up to. current or expired data has
nothing to do with classical application models, internet programming, or
transmission protocols. expired is expired.




>> 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.


The distinction between "application" and "research papers" is valid
(though not as extremist or polorized as your "purist vs. bleeding edge"
analogy). a research paper is a static information space that you can
navigate through in any direction, from any start point to any end point.
that might make it a little confusing, but you COULD do it and you COULD
get everything there is to get out of that site by interacting with it that
way. correct? no matter what order you read the pages of "Mody Dick", if
you read all the pages you've read all the book, and you can probably piece
together the story, even if it's not perfect.

an application is NOT a static space - it has specific requirements and
demands a specific sequence of interactions to work at all, much less work
correctly. the "direction" you proceed thru the application, and how
current or expired the screen data is, does matter. you just can't do it in
any order you would like. The distinction between "application" and
"research papers" is valid to an interactive media designer.





>> 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!


what is insecure? why are you harping on security issues? we have worked
out all the security concerns we can identify at this time, and have
designed around certain problems precisely by doing things you dont' seem
to approve of (like not caching pages, opening second browser windows so
the user doesn't loose a secure session, etc). so far, over 100,000 bank
accounts run on our software and none of them have been hacked or lost money.


>
>> 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.

well OF COURSE we use SSL and strong encryption. but we can't dictate the
OS - that's the whole point of the web - it's platform independent - i dont
care if you are on a pc, a mac, a unix box, lynx, a java browser, an
x-windows terminal or a PDA. it works regardless. "use a resonably secure
OS?" - if you are OS centric, why are you working on web-based material?



>> 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?

yes, i can code a page so it doesn't cache.

and obviously, all the data passing between computers is encrypted, and
what's more, we dont' even deliver "pages" that exist somewhere else - they
are generated on the fly by a host of CGI's and other application code that
lives distributed on numerous (secure) servers. the "page" you finally see
is a uniquely generated and encoded document that would have no meaning as
something to "go back" to - it would have a unique name that would no
longer be valid because it would have been coded to expire.



>
>> - 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.

we dont' store any usable or recognizable data on your computer. that would
be stupid from a design point of view long before it would be stupid from a
security point of view. the point of the system is that you can access your
accounts from anywhere you can get on the web with a secure browser - not
from a specific machine. that's sort of why the web is cool.
machine-specific client software fails outside of an enterprise environment
for delivering these type of services (and that is what the web is becoming
all about - delivering services as much, if not more, then content).




>
>> 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.

you act like we are writing sophisticated applications in HTML. we write
real applications in real programming languages. HTML/HTTPS is purly a
delivery channel, not a processing environment.





>> 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.


we dont claim security where there is none. our systems our very secure and
have have passed every relevent audit - please feel free to tell us
anything that is insecure in the interaction design of our system. "java
client" does not automatically equal security. it does automatically equal
"burdon on your end user", however.



>> 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.

no, wrong, wrong, and no. system not insecure. how many ways do i have to
say that? design not insceure. design only offends you because it opens
second browser. design not insecure. system not insecure. system never
compromised. never hacked. system is, in fact, highly praised by industry
analysts. do your research.




>> 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.

i dont think so. our client's lawyers dont seem that concerned, either.




>> 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.

i thought you were questioning the fact that the design opens multiple
browser windows. you haven't asked a single thing about other functions or
behaviors of the system (but you seem to be able to generalize a few
comments about the "back" behavior of browsers into a sweeping indictment
of system security - i would love to see your analysis of this).






>> 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.

nobody's lying, and you'd end up in jail for attempted theft and unlawful
entry into a propriatary computer network (definately not for successful
entry into said network). but hey - give it your best shot.



>> 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.

that's a great attitude. our clients dont seem to be complaining, and none
of our end-users feels like they're being ripped off. in fact, we save them
money. everybody's happy except you.



>> >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.)

i feel a lot more enlightened - i'll run down to the software architechture
designers and tell them they should use encryption in our products - what a
novel idea!!! shall i assume that you have conceeded the 'multiple browser
windows' argument since you seem to have quietly dropped it in favor of a
misguided personal attack over a completely inaccurate assessment of security?


derekj


---------------------------------------------------------------
derek h. bambach                    [log in to unmask]
interface architect                            404.812.6767

security first technologies, inc.
3390 peachtree rd, suite 1700
atlanta, ga 30326-1108