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

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 dialogs blocking user experience

[Darin Adler]

> 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 dialogs blocking user experience

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of

> The problem you describe above was addressed by Apple in iOS 9.3 and also
> in Safari 9.1 on Mac. That release changed the style of JavaScript alerts so
> that they are less likely to appear to come from Safari, the operating system,
> or Apple. They look more like part of a webpage, and no longer interfere
> with closing a tab or webpage, using the back button to leave the webpage,
> or using the smart search field to enter a new search or website address.

Yes, this is pretty great! +Avi, who sits next to me on the Chrome team, has 
started a similar project for Chrome, inspired very much by Safari's example: 
https://docs.google.com/document/d/1wtV5rmLhbf1OZkbg7crtCt6h1mMtig_ctTQt3BLLEIU/edit?pref=2=1

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.

Maybe we could consider adding language like "this must not block navigation or 
other parts of the user interface" to step 6, now that more browsers appear to 
be moving in that direction. But practically these changes are mostly being 
driven by browsers interested in improving the user experience for their users, 
and trying to hurry up that process by adding spec language seems like it 
wouldn't accomplish much.

> I don’t think that’s the same topic, though, as what this thread was 
> originally
> about.

I forked the thread, since this topic seems sufficiently interesting on its own.