"James A. Donald" <[EMAIL PROTECTED]> writes:
>2. Html encourages legitimate businesses to use complicated and obfuscated
>actual targets for their urls, indistinguishable from those used by phishers.
I think a more general extension of this is "HTML allows the use of
arbitrarily sophisticated pre
--
Travis H. wrote:
What changed when going from ASCII text to HTML in emails that makes
phishing so much more of a problem?
1. Html obfuscates the actual target of a url.
2. Html encourages legitimate businesses to use complicated and
obfuscated actual targets for their urls, indistinguis
That is a nice trick, but that still may not work entirely: if i make sure
my untrusted app always opens in maximized mode, the untrusted decoration (in
your case a big black border which actually _disappears_) may be unnoticed
along the edges of the screen; if my app then simulates the whole desk
James A. Donald wrote:
> --
> One needs to differentiate dialogs brought up from within the browser
> client, which are trustworthy unless one is infected with malware,
> from popups brought up by some other web page. (Of course if popups
> are disabled except for specific sites, this is consid
In one environment I worked in, it was important that people know what
kind of data they were looking at. The way they solved it was to put a
green colored border and label on one kind of data, and a red border and
different label on another kind of data. This reduces usable screen area
a bit, bu
Piers Bowness wrote:
> This is concept is surprisingly complex. Once the attacker sees the
"secure" dialog, > what prevents them from using the same techniques
and/or code to create a visually > > identical spoof?
(Hi Piers!)
I actually dealt with this in a former job, where I wrote a proxy
fo
--
Bowness, Piers wrote:
> Once the attacker sees the "secure" dialog, what prevents them from
> using the same techniques and/or code to create a visually identical
> spoof? There have been several OS-level designs to create
> hardware-supported secure dialogs. Needless to say, these schemes
This is concept is surprisingly complex. Once the attacker sees the
"secure" dialog, what prevents them from using the same techniques
and/or code to create a visually identical spoof? There have been
several OS-level designs to create hardware-supported secure dialogs.
Needless to say, these schem
--
One needs to differentiate dialogs brought up from within the browser
client, which are trustworthy unless one is infected with malware,
from popups brought up by some other web page. (Of course if popups
are disabled except for specific sites, this is considerably less of a
problem.)
How
