Intent to Implement and Ship: Limit JavaScript dialogs to 100 characters

[Avi Drissman]

Contact emails

a...@chromium.org

Spec

The relevant link is https://html.spec.whatwg.org/#dom-alert .

Summary

http://crbug.com/587962

JavaScript dialogs (and I'm including alert(), confirm(), and prompt() in the discussion here) are used for two things on the Modern Web: 1. JavaScript tutorials. 2. Scamming users. 

Their use in scams is a severe and ongoing problem. We have made multiple attempts to rein them in before, and sites have continued to abuse them. Sites have 1) abused bugs in our shared implementation with onbeforeunload 2) put up walls of text to push the "please stop it" button offscreen 3) used absurdly-long hostnames to push the "please stop it" button offscreen 4) timed themselves to avoid being stopped by our "please stop it" button 5) used wildcard DNS to avoid our origin restrictions on the "please stop it" button, and those are just the ones I can remember.

These functions were designed in the early web where the ability they granted to web pages to escape the browser chrome wasn't an issue. But it is a huge and ongoing issue today. Ask ConOps.

The spec already allows us to block dialogs at our discretion. In https://html.spec.whatwg.org/#dom-alert , the spec says for step 3 for alert(), confirm(), and prompt():

"Optionally, abort these steps."

"Optionally, return false and abort these steps."

"Optionally, return null and abort these steps."

Given that the spec already allows us discretion to block dialogs entirely, IMO a decision to restrict the number of characters displayed in them is entirely spec-compliant.

Motivation

Users are being harmed by bad actors. This mitigates much of the abuse of the API by bad actors.

Interoperability and Compatibility Risk

I'm not aware of any other browser doing this.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/587962

Link to entry on the feature dashboard

This is a change to existing behavior that remains spec-compliant. I don't believe it requires a feature dashboard entry.

Requesting approval to ship?

Yes.

[Alex Russell]

Another use of these sorts of dialogs is onbeforeunload prompting to prevent data loss and explain the implications of navigation to users. Admittedly this isn't a great experience, but I'm wondering if/how this factors into your plans.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

I totally support trying something aggressive here.  I've seen even moderately tek-savvy users become afraid of using the web when they see such dialogs.

The fact that such scams appear to work indicates that alert and friends are a poorly designed platform feature - blur the line between system and application.

But what exactly is your proposal (sorry can't check the bug right now due to monorail transition)?  Truncate the message?  Suppress showing such dialogs?  Do we have any metrics about how often such long dialogs are shown?  Will you generate a console warning with details to help legitimate developers?  I'm sure there are at least some legacy sites (maybe internal IT apps) relying on this, have any thoughts on how to mitigate the pain for them?

Rick

[David Benjamin]

On Thu, Feb 18, 2016 at 6:52 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Another use of these sorts of dialogs is onbeforeunload prompting to prevent data loss and explain the implications of navigation to users. Admittedly this isn't a great experience, but I'm wondering if/how this factors into your plans.

onbeforeunload handlers don't call alert or confirm (or at least they really shouldn't; I don't know off-hand whether we forbid those APIs in beforeunload). Instead they return a string and the browser drives the prompt. There's a separate thread which proposes ignoring that string altogether:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/YIH8CoYVGSg

[Avi Drissman]

Please see my other intent thread for my plans for onbeforeunload: https://groups.google.com/a/chromium.org/d/msg/blink-dev/YIH8CoYVGSg/Di7TsljXDQAJ

[Avi Drissman]

My current CL is https://codereview.chromium.org/1711863004/ which generated some discussion about where in the stack to do truncation, whether we need to log, etc.

I'm not proposing dropping the dialogs, just truncating the text inside. My argument is that because the spec allows me to drop the dialogs, I'm within my rights, spec-wise, to truncate the message that they show.

Right now we have no metrics. I'm open to having a JS console warning for truncated messages. I don't know how many legacy sites have dialogs that take up the screen with text.

[Ilya Grigorik]

On Thu, Feb 18, 2016 at 3:52 PM, 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Another use of these sorts of dialogs is onbeforeunload prompting to prevent data loss and explain the implications of navigation to users. Admittedly this isn't a great experience, but I'm wondering if/how this factors into your plans.

If you're relying on onbeforeunload to prevent data loss, then you're failing miserably already. Some browsers don't fire it at all. On mobile, the event never fires if the app is already in the background (e.g. app switch, swipe away, killed by OS, etc). Recent test results: https://www.igvita.com/2015/11/20/dont-lose-user-and-app-state-use-page-visibility/

FWIW, I'd like to see us kill beforeunload entirely. It's a broken mechanism and a security liability.

[Elliott Sprehn]

This needs to warn in the console, we should also bring it up with public-webapps. This is a fundamental web API change that will probably want to be added to the spec since realistically Chrome is big enough that if we limit it to 100 chars all other browsers will need to as well otherwise any important content down there will be lost for some percentage of users. I know the spec is vague, but in the real world browsers are all pretty consistent.

I think this also needs a use counter for how often we'd hit the 100 char limit. Also have you talked to the localization folks? Some languages (ex. German) have very long words. Truncating like this may break something important like someone's bank website.

I'd really want to see how often this hits before we do it. ex. alert() is used on 0.1150% of page views according to chromestatus which is super high.

[Elliott Sprehn]

On Thu, Feb 18, 2016 at 4:01 PM, Avi Drissman <a...@chromium.org> wrote:

My current CL is https://codereview.chromium.org/1711863004/ which generated some discussion about where in the stack to do truncation, whether we need to log, etc.

I'm not proposing dropping the dialogs, just truncating the text inside. My argument is that because the spec allows me to drop the dialogs, I'm within my rights, spec-wise, to truncate the message that they show.

That's not how the web works. Specs are frequently vague, that doesn't mean you can just change things without breaking huge numbers of pages either because they depend on Chrome specific behavior, or because all browsers are actually consistent even though the spec allows flexibility.

We hit this all the time, for example when messing with setTimeout which the spec gives pretty broad flexibility to mess with, but in reality if you do lots of content breaks.

Yeah it sucks, but it's the price for being the most successful app platform on the planet. :)

- E

[Avi Drissman]

Here's my specific problem:

Because JavaScript alerts are synchronous, they cannot be given app-modal UI (see http://crbug.com/456). So scam websites (e.g. https://blog.malwarebytes.org/fraud-scam/2016/02/tech-support-scammers-use-new-browser-trick-to-defeat-blocking/) keep slamming JavaScript dialogs in the users' faces to harrass them into surrendering control of the computer.

Having a JavaScript dialog that takes up the entire screen is one of the things that scam sites do in order to cow the user into submission. Is there a cutoff where we can say, hey, let's cut it off there? 500 characters? 1k?

If a website gives us a 20M string, we surely wouldn't put up a dialog with that much text. Where do we draw the line and truncate it? Surely it's not a question of whether we should.

Avi

[Jeremy Roman]

What about displaying the message in a scrollable box if it's above a certain length? Would that make it less intimidating and easier to close?

[Rick Byers]

+1.  See http://www.chromium.org/blink#TOC-Policy-for-shipping-and-removing-web-platform-API-features for the principles here.  It says we seek to balance moving the web forward (which this clearly does) and compatibility/interoperability.  Specs are just a (imperfect) tool for helping to achieve interop and compat.

That said, with a bit of diligence I suspect this won't be too hard to pull off respectfully. Eg. add a length histogram, pick a value that's initially conservative (eg. The longest 1% of alerts), add a console warning, do a bit of developer outreach (which will mostly happen for you by filing a chromestatus entry), gather feedback in beta, and iterate (maybe lowering the threshold over time as our confidence increases). 

If we can find what seems to be a sweet spot that reduces abuse without much compat fallout, then it'll probably be easy to get such a threshold written into the spec.

Rick

[Avi Drissman]

We already do put it into a scrolling box.

I misunderstood the current code; we already limit the text to 2000 characters. Can we dial that down? Should we put this proposal aside until we have a histogram to look at?

[Matt Falkenhagen]

(Probably needless clarification): this intent is about "system" dialogs from alert/confirm/prompt, and has nothing to do with the <dialog> element, which is rendered as an element in the page and doesn't escape the browser chrome.

[Jochen Eisinger]

We can't guarantee to show all characters, so putting in a limit is reasonable.

For the exact value, can we add a histogram for M50 to see what a safe cutoff would be?

[Philip Jägenstedt]

If a big part of the problem is the size of the alert box, then perhaps the height should also be limited? In other words, add a histogram for the number of linebreaks in the string? I'd half expect that a good eventual limit is x characters, but that x linebreaks is still way too much.

[Avi Drissman]

Jochen:

A histogram is a good idea.

Philip:

The problem is the way that dialogs allow malicious websites to present a wall of text to the user that blocks all their browsing. (https://blog.malwarebytes.org/fraud-scam/2016/02/tech-support-scammers-use-new-browser-trick-to-defeat-blocking/)

----

I'm going to put in a histogram and come back to this Intent with some data.

Avi

[Avi Drissman]

Philip, Jochen pointed out that I'd missed the point of the height. Ugh, too early in the morning for me to be working. Yes, I will be sure to histogram the linebreak count, too.

[Ian Clelland]

The 'scam website stops user from leaving page' issue is not about alert() dialogs, though. That's an abuse of onbeforeunload, and there are probably better methods to deal with that than arbitrarily truncating text. (I don't know any reason that a bad actor couldn't do exactly what they're doing today, with a twitter-length string instead)

The MDN page on onbeforeunload[1] notes that FF is dealing with this by not even raising the "leave this page?" dialog if the page hasn't been interacted with. It also notes that

"Since 25 May 2011, the HTML5 specification states that calls to window.alert(), window.confirm(), and window.prompt() methods may be ignored during this event. See the HTML5 specification for more details."

[1] https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload

On Fri, Feb 19, 2016 at 10:57 AM, Avi Drissman <a...@chromium.org> wrote:

[stepien...@gmail.com]

Why not truncate at a certain limit AND show an inline "... Show more" button?

[Brandon Jones]

Because then every scam site will pop up alerts starting with "Important security alert! Click 'Show More' for full details!"

[Avi Drissman]

On Fri, Feb 19, 2016 at 11:09 AM, Ian Clelland <icle...@chromium.org> wrote:

The 'scam website stops user from leaving page' issue is not about alert() dialogs, though. That's an abuse of onbeforeunload

Nowadays they are, but that's mostly because we fixed the bugs in alert(). I work on the JavaScript alert code, and I have seen them both.

If we lock down onbeforeunload (which is what I'm asking for in my other Intent), the scam sites will switch to alert dialogs, so we do need to be ready for that.

Avi 

[tom.p...@free.fr]

Isn't this all going a little too far?

I mean, not everybody wants to use some userland library to interact with their users. I use alert() and confirm(), and it's fine. I don't want browser vendors to get in my way when I'm trying to use such basic stuff.
The real issue here is these native solutions' misuse and (understandably) bad image. The existing checkbox allowing users to hide further dialogs from the current website is the way to go; it's up to users to decide if they want dialogs from this site/app any longer, which they won't in case of abuse. BTW, userland solutions do NOT provide this to the end user.

Don't kill native dialogs, please - make 'em better, and I'm talking standards-level better. Get Mozilla, Microsoft, Opera, the goddamn W3C involved, and make it better, but don't kill it, that's really half-arsed and disrespectful of the Web standards IMHO.

[PhistucK]

On Mon, Feb 22, 2016 at 1:36 PM, <tom.p...@free.fr> wrote:

BTW, userland solutions do NOT provide this to the end user.

Note that they do not need to provide this... The user can simply close​ the tab and be done with it, unlike with alert().

That is exactly the beauty of it. :)

Anyway, Chrome has implemented alert() in an abusive way (it ridiculously locks the entire browser) and now the team wants to get rid of it (or cripple it), instead of spending (probably a lot of) time fixing it.

While it is a bad API, it is here to stay for the time being and the browser should handle it better.

☆PhistucK

[tom.p...@free.fr]

Checking the box on an alert() lets you keep the tab minus the prompts ;)
Rebuilding native stuff in userland isn't quite my definition of beauty, but well, let's agree to disagree.

You have a point about the way these are implemented; I don't think it's a Chrome-only problem, I honestly don't know about the spec but it could surely be better, which is the reason why I don't think such initiatives are the way to go.
I'm unaware of Chrome's (or any browser's) development schedule and can't possibly imagine what I suggest implies, but I'm convinced this API's fate is of importance regarding the Web's future, which it should be (again, IMHO) a part of.

Thank you!

[Torne (Richard Coles)]

alert() and confirm() are synchronous JS calls, which means that the JS execution in the tab must be halted until the user responds. This limits the possible choices of implementation significantly, and makes it extremely difficult to mka

Chrome has only one main JS thread per renderer process, and so when any tab using that renderer calls alert(), *every tab* in that renderer must be halted until the user responds to the dialog, whichever tabs that happens to be (other tabs showing the same site, often; script-linked tabs invoked by window.open, or even totally unrelated tabs that are just sharing a renderer because the maximum number of renderers is already running). In a non-multiprocess browser this is even more difficult as they typically just have one JS main thread for the entire browser, and so all tabs will be blocked.

There's not really any way to improve this significantly while preserving the property that alert() and confirm() are synchronous. Introducing an asynchronous equivalent of these APIs would be a lot of work to provide something that developers probably won't use (typically developers use synchronous APIs like these *because* they're synchronous and that's the property they want) - if they were happy with an async version they would probably already be using a DOM-based dialog that they can customise the UI for and doesn't block the browser.

[Daniel Bratell]

On Fri, 19 Feb 2016 00:21:12 +0100, Avi Drissman <a...@chromium.org> wrote:

Contact emails

a...@chromium.org

Spec

The relevant link is https://html.spec.whatwg.org/#dom-alert .

Summary

http://crbug.com/587962

JavaScript dialogs (and I'm including alert(), confirm(), and prompt() in the discussion here) are used for two things on the Modern Web: 1. JavaScript tutorials. 2. Scamming users. 

(3. Debugging)

Given that the spec already allows us discretion to block dialogs entirely, IMO a decision to restrict the number of characters displayed in them is entirely spec-compliant.

Where do you propose to implement this? In the Chrome UI or deeper down where it affects all Chromium based products? I wonder because I'm not sure Opera is affected by the same issues. At least we seem to use tab local alerts instead of locking the whole browser so a user that feels unhappy with the alerts can just close the tab. (Yes, I'm aware of why some people think the dialog has to be app modal; in short - I disagree)

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Boris Zbarsky]

On 2/22/16 7:17 AM, Torne (Richard Coles) wrote:
> In a non-multiprocess browser this is even more
> difficult as they typically just have one JS main thread for the entire
> browser, and so all tabs will be blocked.

Firefox in non-multiprocess mode scopes alerts to a single tab.

It's not fully sync in the sense that script can run in _another_
window/tab and poke at this one, but we judged that to be a lesser evil
than blocking the world. Note that blocking the world is pretty
user-hostile even with caps on the alert string and whatnot.

-Boris

> (typically developers use synchronous APIs like these *because* they're synchronous
> and that's the property they want)

Typically developers do it because they just haven't thought that much
about it.

-Boris

[Torne (Richard Coles)]

On Mon, 22 Feb 2016 at 13:04 Boris Zbarsky <bzba...@mit.edu> wrote:

On 2/22/16 7:17 AM, Torne (Richard Coles) wrote:
> In a non-multiprocess browser this is even more
> difficult as they typically just have one JS main thread for the entire
> browser, and so all tabs will be blocked.

Firefox in non-multiprocess mode scopes alerts to a single tab.

It's not fully sync in the sense that script can run in _another_
window/tab and poke at this one, but we judged that to be a lesser evil
than blocking the world.  Note that blocking the world is pretty
user-hostile even with caps on the alert string and whatnot.

Oh, sorry; didn't know that. Thanks for the correction!

-Boris

> (typically developers use synchronous APIs like these *because* they're synchronous
> and that's the property they want)

Typically developers do it because they just haven't thought that much
about it.

I'm maybe not as optimistic; the issues with showModalDialog, sync XHR, etc make it look to me like a lot of web developers *do* want blocking sync APIs for things, and those people seem like the ones who are most likely to actually be using, say, confirm() for purposes other than temporary debugging..

 

-Boris

[Jochen Eisinger]

The tab modal implementation also has the issue that one tab can keep another one hostage: https://bugzilla.mozilla.org/show_bug.cgi?id=727801

[Boris Zbarsky]

On 2/22/16 8:43 AM, Torne (Richard Coles) wrote:
> I'm maybe not as optimistic; the issues with showModalDialog, sync XHR,
> etc make it look to me like a lot of web developers *do* want blocking
> sync APIs for things

Oh, I think they do. I just don't think they necessarily think about
what "blocking" means in practice and in many cases don't care about the
strictest and most theoretically pure definition of it. It turns out
that blocking the current thread of execution in that one global and
preventing event delivery to that one tab (which is what Firefox does)
is fine in the vast majority of cases.

-Boris

[Boris Zbarsky]

On 2/22/16 8:48 AM, Jochen Eisinger wrote:
> The tab modal implementation also has the issue that one tab can keep
> another one hostage: https://bugzilla.mozilla.org/show_bug.cgi?id=727801

The specific one in Firefox does, true.

-Boris

[PhistucK]

Of course there is a way. Even graying out the tab content of related tabs would be better than locking the entire browser. This API has a really bad user experience because of design decisions by Chrome, rather than only a bad (minus the "really", which is important here, because the "really" part is exactly what makes it abusive) user experience that it could have been (not locking the entire browsers, but only tabs of the same process).

Options totally exist (and Firefox has done it in some fashion and they seem to get away with it), but are simply not prioritized.

☆PhistucK

--

[Dimitri Glazkov]

LGTM to add histograms and get a bit more data on the types of dialogs the users see.

:DG<

[Dimitri Glazkov]

Also, please, please please, let's split up discussions not related directly to this intent into separate threads.

:DG<

[PhistucK]

How are they not directly related? If this is not application modal, this intent is pretty much unnecessary.

☆PhistucK