Re: [whatwg] JavaScript dialogs blocking user experience

[Darin Adler]

> On Apr 15, 2016, at 1:58 PM, Arvind Nigam  wrote:
> 
> On mobile the browser goes totally unresponsive and the infinite-loop of 
> modal confirmations is literally inescapable.

I’ll drop this thread after this, but what I wanted to say is this:

This extremely bad experience described here is a result of choices made by the 
developers of the web browsers, not something intrinsic to mobile or inevitable.

It just so happens that all the people developing these browsers made the same 
kind of mistake. The mistake can easily be fixed in each browser.

— Darin

Re: [whatwg] JavaScript dialogs blocking user experience

[Darin Adler]

> On Apr 15, 2016, at 1:58 PM, Arvind Nigam  wrote:
> 
> While I understand your inclination towards Apple Safari, it is out of 
> question that people won't use other browsers like the Chrome or Firefox or 
> even the UC browser to surf the web. 

The problem you complained about is fixed in the browser I was recommending. 
But not fixed in the browser you were using. So all that stuff you are saying 
about “the only way out is to delete the browser” is true about UC Web but not 
about the latest version of the browser I was recommending.

— Darin

Re: [whatwg] JavaScript dialogs blocking user experience

[Arvind Nigam]

> It’s too bad you were using the UC browser. If you had been using
> Safari you would not have been trapped by the scam. If you continue to
> prefer the UC browser over Safari then you should consider how to let
> the developers know you would like to see this improved.


Oh, I love the Safari, but...

> "If you had been using Safari you would not have been trapped by the scam.
"

False dichotomy here?

While I understand your inclination towards Apple Safari, it is out of
question that people won't use other browsers like the Chrome or Firefox or
even the UC browser to surf the web.

---

*The issue:*

The original issue that I reported on this thread was to make the top-level
functionality of browsers remain "available" during execution of the
javascript modal. In other words the controls "back, forward, change tab or
close tab" shouldn't be hijackable by a measly modal -- no matter what the
intent of a page is; to scam or not is immaterial.

*Why so?*
Because the annoyance (Unlike as reported on the original mail thread from
which this one was forked) on tablets and smartphones is worse than it is
on the desktops, where at least the user has an option to shut down or kill
the browser by killing a process.

On mobile the browser goes totally unresponsive and the infinite-loop of
modal confirmations is literally inescapable. You cannot switch tabs, go
back or close the window/tab. Closing and re-opening the browser doesn't
help either. It only comes back to the same unresponsive state.

The only way out then is to delete the browser and reinstall it with clear
history.

And that's not a pretty picture :-).

Cheers, m
---

On 15 April 2016 at 11:36, Darin Adler  wrote:

> > On Apr 14, 2016, at 2:17 PM, Arvind Nigam 
> wrote:
> >
> > My iPad is on iOS 9.3.1, but I was using the UC browser at the time.
>
> It’s too bad you were using the UC browser. If you had been using Safari
> you would not have been trapped by the scam. If you continue to prefer the
> UC browser over Safari then you should consider how to let the developers
> know you would like to see this improved.
>
> > I'm guessing that this is still a problem for a lot of users out there
>
> No question about it. The kind of mitigation we are discussing is valuable
> to reduce the effectiveness of JavaScript dialogs as part of this, but I’m
> sure the folks perpetrating fraud will find new effective ways to do so.
> For example, nothing in browser technology can prevent a webpage from
> displaying a misleading message that tries to trick you into thinking your
> device is broken or was taken over.
>
> Apple support has a webpage with some advice on this topic that is updated
> from time to tome .
>
> — Darin

Re: [whatwg] JavaScript dialogs blocking user experience

[Nils Dagsson Moskopp]

Darin Adler  writes:

>> On Apr 15, 2016, at 9:35 AM, Nils Dagsson Moskopp 
>>  wrote:
>> 
>> Clearly distinguishing between browser chrome and the current document
>> interface-wise can be helpful here. While it is incredibly easy to fool
>> people in general, browsers that automagically hide the address bar also
>> hide information about the state of the browser program. The browser
>> still has a state, but it forces the user to remember or deduce it.
>
> Which browsers automagically hide the address bar?

Old versions of Android scrolled the address bar with the content and I
found posts that said that “window.scrollTo(0, 1);” could hide the bar.

>
>> I think a good thing would be to keep browser applications' interfaces
>> stable and not change things for the sake of change with every upgrade.
>
> I believe we are talking about changes that are needed to improve clarity and 
> security.
>
> This is a straw man. I can’t think of any browser that changes things
> “for the sake of change with every upgrade”.

I cannot think of one as well, but desktop environments often change
things around without changing actual functionality much – making it
harder for users to use the software. For example, GNOME removed the
traditional menubar in favor of a “miscellanous” menu bar, then changed
its icon from a gear into a “hamburger” icon (≡). And OS X 10.7 (Lion)
introduced a leather texture for iCal that as far as I know makes no
functional difference and removed it again in OS X 10.9 (Mavericks).

>
> — Darin

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] JavaScript dialogs blocking user experience

[Darin Adler]

> On Apr 15, 2016, at 9:35 AM, Nils Dagsson Moskopp 
>  wrote:
> 
> Clearly distinguishing between browser chrome and the current document
> interface-wise can be helpful here. While it is incredibly easy to fool
> people in general, browsers that automagically hide the address bar also
> hide information about the state of the browser program. The browser
> still has a state, but it forces the user to remember or deduce it.

Which browsers automagically hide the address bar?

> I think a good thing would be to keep browser applications' interfaces
> stable and not change things for the sake of change with every upgrade.

I believe we are talking about changes that are needed to improve clarity and 
security.

This is a straw man. I can’t think of any browser that changes things “for the 
sake of change with every upgrade”.

— Darin

Re: [whatwg] JavaScript dialogs blocking user experience

[Nils Dagsson Moskopp]

Darin Adler  writes:

>> On Apr 14, 2016, at 2:17 PM, Arvind Nigam  wrote:
>> 
>> My iPad is on iOS 9.3.1, but I was using the UC browser at the time.
>
> It’s too bad you were using the UC browser. If you had been using
> Safari you would not have been trapped by the scam. If you continue to
> prefer the UC browser over Safari then you should consider how to let
> the developers know you would like to see this improved.
>
>> I'm guessing that this is still a problem for a lot of users out there
>
> No question about it. The kind of mitigation we are discussing is
> valuable to reduce the effectiveness of JavaScript dialogs as part of
> this, but I’m sure the folks perpetrating fraud will find new
> effective ways to do so. For example, nothing in browser technology
> can prevent a webpage from displaying a misleading message that tries
> to trick you into thinking your device is broken or was taken over.

Clearly distinguishing between browser chrome and the current document
interface-wise can be helpful here. While it is incredibly easy to fool
people in general, browsers that automagically hide the address bar also
hide information about the state of the browser program. The browser
still has a state, but it forces the user to remember or deduce it.

Phishing works by confusing the user about the state a program has. Many
accessability or security woes can be reduced to hidden state. Tracking
using cookies works so well because browsers usually hide cookie state.

I think a good thing would be to keep browser applications' interfaces
stable and not change things for the sake of change with every upgrade.

>
> Apple support has a webpage with some advice on this topic that is
> updated from time to tome .
>
> — Darin

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] JavaScript dialogs blocking user experience

[Darin Adler]

> On Apr 14, 2016, at 2:17 PM, Arvind Nigam  wrote:
> 
> My iPad is on iOS 9.3.1, but I was using the UC browser at the time.

It’s too bad you were using the UC browser. If you had been using Safari you 
would not have been trapped by the scam. If you continue to prefer the UC 
browser over Safari then you should consider how to let the developers know you 
would like to see this improved.

> I'm guessing that this is still a problem for a lot of users out there

No question about it. The kind of mitigation we are discussing is valuable to 
reduce the effectiveness of JavaScript dialogs as part of this, but I’m sure 
the folks perpetrating fraud will find new effective ways to do so. For 
example, nothing in browser technology can prevent a webpage from displaying a 
misleading message that tries to trick you into thinking your device is broken 
or was taken over.

Apple support has a webpage with some advice on this topic that is updated from 
time to tome .

— Darin