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 <da...@apple.com> wrote:

> > On Apr 14, 2016, at 2:17 PM, Arvind Nigam <arvind.ni...@gmail.com>
> 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 <https://support.apple.com/en-us/HT203987>.
>
> — Darin

Re: [whatwg] JavaScript dialogs blocking user experience

[Arvind Nigam]

> The problem you describe above was addressed by Apple in iOS 9.3 and also in
Safari 9.1 on Mac.

My iPad is on iOS 9.3.1, but I was using the UC browser at the time.

I couldn't relocate the exact scamjam page I saw in the morning, but found
this url of a company that supposedly "helps" people fix the issue on their
phones somehow:

http://guides.yoosecurity.com/how-to-remove-fbi-warning-message-from-iphoneipad/
(This
page is safe, ordinary wordpress/blog.)

Their post is fairly recent. And they have a few screenshots of the modal
that people see so I'm guessing that this is still a problem for a lot of
users out there; and is big enough to warrant/sprout/support scammy
businesses like that.

- a

On 14 April 2016 at 16:25, Darin Adler  wrote:

> > On Apr 14, 2016, at 1:04 PM, Domenic Denicola  wrote:
> >
> > I'm not sure whether this has much of a spec impact. The spec already
> allows great leniency in these areas; e.g.
> https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3
> and the "optionally" in step 7. If any browser has qualms with the current
> language and would like it to be more flexible, we're certainly open to
> that, in the same spirit as the semi-recent
> https://github.com/whatwg/html/pull/714.
>
> Here are two things we might want to address in the specification—not sure
> either is practical:
>
> - Find some place to emphasize the importance of having UI driven by a
> webpage not seem to come from the browser or operating system and not block
> user interface that lets a user “leave”. Documenting this kind of thing
> makes it more practical to build a new browser engine, cutting down on the
> “unwritten lore” needed to make an acceptable user experience. I think
> making this clear is important for the Simple Dialogs feature, but also
> many other features such as full screen modes. Maybe this calls for a
> section like the “Security and privacy” section someone wrote for
> registerProtocolHandler?
>
> - This one is even more “aspirational”: Clarify the relationship between
> multiple webpages that are separately running JavaScript. When content from
> the same website is open in multiple windows, the ancient classic version
> of these Simple Dialogs functions in the oldest web browsers accidentally
> guaranteed that everything in both windows was paused until the user
> responded. I think it would be good if there was some way we could clearly
> state to website authors that this is not the case any more. Ideally we
> would find a way to make it practical to quickly discover if a website
> author accidentally relied on something like that, but I am not optimistic
> that we can.
>
> — Darin

Re: [whatwg] JavaScript Hovers and Back Button

[Arvind Nigam]

Hi,

Unlike others on this thread I'm a little more ordinary user of the web.
Came across one such modal just today!

So thank you for reporting this.

I wish to add that this issue is a bit more annoying on mobile: both on
iPad and iPhone. I guess the behavior on Android phones too will also be
the same, but this needs validation.

Once the webpage loads, it goes into a JS invoked confirm/ok modal that
would not relent -- not without seeking credit card info or something else
to let you off the hook. The site that I saw today was somehow phishing a
*.gov url too, using serious/ even scary warnings with quotes from Federal
Law / websites... :-)

The only way out then was to delete the browser from my iPad and reinstall
it clean.


Cheers,

On 14 April 2016 at 10:45, Yay295  wrote:

> *Windows*
> IE11, Chrome: Navigation buttons are blocked while modal dialog is shown.
> Firefox: Navigation buttons remain usable.
>
> On Thu, Apr 14, 2016 at 8:34 AM, Majid Valipour 
> wrote:
>
> > > A very common abuse is that when pulling the mouse to hit the back
> > > button because you are not interested in a page, a hover comes up and
> > > when the hover comes up, the back button no longer works.
> >
> > Does 'hover' refer to modal dialog e.g., window.alert?
> > That is the only way I know that you can block a user to click back
> button.
> > Here is a simple page that does this: http://jsbin.com/fuwosaxefa
> >
> > That behavior is a side-effect of how a browser may decide to implement
> > modal dialog which is dependent also on the OS. I tested a few browsers
> on
> > Linux & Mac and this is what I found:
> >
> > *Mac*
> > Firefox, Chrome, Safari: Navigation buttons are usable while modal dialog
> > is shown.
> > *Linux*
> > Chrome: Navigation buttons are block while modal dialog is shown.
> > Firefox: Navigation buttons remain usable.
> > *Windows*
> > 
> >
> > Perhaps this is worth a non-normative note in the spec in "user-prompt"
> > section [1]
> >
> > [1] https://html.spec.whatwg.org/multipage/webappapis.html#user-prompts
> >
> > Majid
> >
> > On Thu, Apr 14, 2016 at 4:38 AM Delfi Ramirez 
> > wrote:
> >
> > > Agree.
> > >
> > > May it be done within the History API spec?
> > >
> > > Just wondering.
> > >
> > > ---
> > >
> > > Delfi Ramirez
> > >
> > > My digital signature [1]
> > >
> > > +34 633 589231
> > >  del...@segonquart.net [2]
> > >
> > > twitter: delfinramirez
> > >
> > >  IRC: segonquart Skype: segonquart [3]
> > >
> > > http://segonquart.net
> > >
> > > http://delfiramirez.info
> > >  [4]
> > >
> > > On 2016-04-13 21:44, Michael A. Peters wrote:
> > >
> > > > It needs to be made very clear as a web standard that no JavaScript
> > > action can disable UI functions such as the back button.
> > > >
> > > > A very common abuse is that when pulling the mouse to hit the back
> > > button because you are not interested in a page, a hover comes up and
> > when
> > > the hover comes up, the back button no longer works.
> > > >
> > > > This is a browser UI issue but it needs to specified that browsers
> must
> > > not disable the back button in response to JavaScript. The web is
> enough
> > of
> > > a cesspool as it is.
> > >
> > >
> > > Links:
> > > --
> > > [1] http://delfiramirez.info/public/dr_public_key.asc
> > > [2] mail:%20del...@segonquart.net
> > > [3] skype:segonquart
> > > [4] http://delfiramirez.info
> > >
> >
>