Require user gesture for navigator.vibrate in cross-origin iframes #25
Comments
|
An update: For now, the vibrate function could be turned on by the web site owners (See https://bugs.chromium.org/p/chromium/issues/detail?id=623682): Also we are working on implementing iframe attribute for feature policy (please see https://github.com/WICG/feature-policy/ and crbug.com/682258), and you might be able to enable vibrate for any iframe in future by something like: <iframe src=... enable="vibrate"></iframe>. |
|
Hi @lubin2010, I consider that maybe a year ago malicious vibration was a big issue but today programmatic advertising tools and ecosystem allow avoiding this kind of content to be displayed in publishers easily, making this modification no sense pretty soon. Nevertheless, if you are still interested in blocking it, in order to allow our format and future advertising formats using vibration (like embedded games advertising) in current publishers I propose a "vibrate" by default "Feature-Policy" This way when publisher consider that this kind of advertising is arriving to its website and it is annoying their users, it can block/disable temporarily or in a definite way by adding "Feature-Policy:{"vibrate":[]}" as you propose. If you do the way you are proposing now, millions of websites should be modified to allow this kind of creativities to work, causing a big damage to the evolution of engaging creativities. As I told above, this kind of malicious vibration will disappear as soon as Sell Side Platforms and Demand Side Platforms detect it. Consider also that such malicious vibration ads have to pay the publisher to be published so there will be two cases:
That's the way on my opinion. |
|
There's some reports of potentially legitimate future use cases being broken by this. For example, maybe it's possible that users want to interact with an interactive ad which can be more engaging with vibration without the publisher / ad network needing to opt-in specifically. Less controversially, an embedded map may want to provide haptic feedback when the user is interacting with it. Is it really worth the cost to require the embedder in such a case to opt-in specifically? For existing deployments explicit opt-in to enable a new feature like haptic feedback may be very difficult in practice. The primary benefit of this intervention is for the case where the user has not (and will not) explicitly interact with the iframe at all. In those cases I feel we should continue to block vibration. What exactly is it that Firefox is doing here, they've got some sort of enabling mechanism, right? Can we find the engineers involved and ask for their input? How about relaxing this restriction so that vibration can succeed after the frame has processed SOME task that was triggered by user activation? I.e. after the user taps (but not just because they scrolled) the iframe becomes active. |
|
@bzbarsky (from Mozilla), Do you know what Firefox is doing for vibrate on mobile devices? Thanks. |
|
Thanks @RByers for your comments. In my opinion we should do something like this:
Notes: Instead of adding a message that disappears in 3 sec. we can add a vibration activated icon on top-left corner in iframe so when user press it, it vibrates, by pressing again it stop vibration and so and forth. Position is chosen because usually sound activation is located in the lower-right corner. Another option could be to disallow vibration by default and force advertisers to add a button/control to allow when user activate it. This way no advertising will work if iframe doesn't integrate such click button. Those are ideas but maybe they can work as a starting point. |
|
@lubin2010 I don't, sorry. It's changed a few times too.... |
|
@VicenteDiaz sorry our original messages overlapped (didn't see yours come in before I posted mine). It sounds like your proposal is a strict subset of mine, right? I.e. in my proposal an ad could determine that vibration is disabled (@lubin2010 is this already feature-detectable?) and show its own "tap here to enable awesome haptic feedback" button. Once the user has tapped anywhere inside the iframe, vibration will be enabled for the lifetime of the frame. So rather than the browser defining the precise UI, the ad (or ad network) has control over that - as long as the user action includes a tap. Doesn't that work even better for you than what you proposed? By the way, for the record for others following along here is the blink intent-to-ship thread where we approved making this breaking change to Chrome. |
|
Yes @RByers You are right (I didn't realized about your previous message, sorry). That's the best option for everyone! It simplifies everything and it avoids malicious content to vibrate, giving the advertiser the control over the message to be used to advert the user about haptic content. Thanks! |
|
@VicenteDiaz great, glad to hear you like this. Thinking about this more I think it's exactly analogous to our position on autoplay video and audio (#23). We don't allow audio by default in a cross-origin frame, but once the user taps a play button or something we do. It's conceptually identical IMHO except that we didn't have the examples of legitimate vibration cases in hand to force us to come to such a compromise from the start. @lubin2010 what's your thoughts on implementing this relaxation? Does it seem reasonable to you? @bzbarsky can you suggest how we can find out what was done in Gecko and who to talk to for more |
|
@bzbarsky nevermind - Bin found the Firefox bug. I checked our implementation and it looks we should be returning |
|
@RByers Ah, excellent. Yes, that bug is the most recent thing I recall going by, and getting in touch with the people who worked in it is a good way to change whether anything has changed since then. |
|
By the way, @lubin2010, here I send you a screenshot of my mobile phone when trying to open our haptic content in Sizmek Company Demo Webpage > http://testme.sizmek.es/mobile.php?id=0UKNGG&pos=middle
|
|
cc @ojanvafai @RByers & @VicenteDiaz, Could allowing vibrate after any user gesture on the cross-domain iframe still cause problems since user doesn't have control over it? Say, user might just want to play a video, but after user click, the video starts to vibrate and user doesn't have a way to turn it off. I'm guessing it's slightly different from the autoplay of muted video since unwanted vibrate might be more annoying? Is it a bad idea to do something like auto-popup blocking in browser? For example, vibration is disallowed by default on a new site, and when the vibrate function is called, browser shows a message allowing user to turn it on in 3 secs which could work for both top-level frames or iframes, and such user preferences will be saved for each enabled site. I guess It's more like what Firefox is doing now. |
|
@lubin2010 I consider that when ads contain a video and it autoplays user don't have to click on iframe to view it. Take into account that this is for iframe using vibrate API, not for conventional videos that will work as usual. @RByers idea match with both malicious and Haptic content (any good future haptic content, not only videos). When such iframe activate a haptic content (call to vibrate API) the message "Tap to enjoy haptic content" should appear to allow user tapping on it. In this case, to avoid discrimination of vibration content from audio it could be better to show the message in a creator's selected position in the frame so user must press just in the message instead of the iframe. This way creator can position the control of user vibration to not disturb video or any future content while playing. A selection pop up will discriminate the use of haptic content over other content. That's why I don't like Firefox solution, because video content can not be viewed while pop-up is on, reducing user experience. Of course browser can store the selection if it is possible so if user likes this kind of content it can be played without user interaction as you mentioned. What do you think? |
It's a good point that we need to think this through - my analogy isn't perfect. Audio has the fallback of the user muting their device if they're annoyed, but there's no tab or system-wide "mute vibrations". Of course the user can close or reload the tab (or, unlike audio, even just switch to a different tab). + @mounirlamouri in case he has any wisdom to share from his years of finding a good compromise for audio. But is this really likely to be an abuse pattern? If a user gesture has occurred, then (in the vast majority of cases) the iframe could use that gesture to open a popup or navigate the top frame to get to a top-level site that does whatever it wants (including vibration). If the frame has already succeeded at getting the user to tap it, then maybe it conceptually already has permission to arbitrarily annoy the user?
A permissions prompt is certainly worth considering, especially since there's precedent (we do want to converge on something where the web can behave the same everywhere). But it's got some clear downsides. First, if you do it based on the frame origin, the user can't really reason about WHO they're granting permission to (the only origin that means anything to the user is the one in the omnibox). It looks like Firefox is using the top frame's origin for their permission? That means, eg. in the maps case, every site you visit that has an embedded haptic-map will request vibration permission (the user can't just grant it to the map origin). Also it's more intrusive - we know we've got a problem with creating permission dialog blindness (just training users to click ok) so our security team is pretty hesitant to add new permission prompts and instead try to predict the user's intent without a prompt at all when possible. One idea would be to start with the more permissive option, with a plan to make it more restrictive (eg. via a dialog) if we get reports of abuse. In general I don't think we want to restrict things we don't have solid evidence will actually be a problem. In general we tend to use permissions for things that are privacy/security sensitive and user gestures for things that are just about user annoyance. There's some interesting precedent for middle ground like fullscreen where a gesture is required but then we show UI to undo, and popups where we require a gesture but when it's not present we have a UI work-around. Hopefully we can get the Mozilla folks to weigh in on these tradeoffs too. |
|
I agree with @RByers in the sense that including a context dialog to any haptic content will create even more disturbance to users. So we should not consider such solution.
As a matter of fact this is the simplest way. Using a by default vibration ON in browser will allow users to switch vibration OFF when they receive such content often and feel it annoying. They can switch on again when they like the content or the time goes by and this kind of malicious content disappears naturally thanks to other ecosystem technologies that are evolving and I mentioned above. You can see a lot of companies doing so as a service, like GeoEdge, and some others, to verify creativities previous to launch or receive. In fact today I have had a meeting with the European representative of Ad Explora or Site Scout (a Canadian innovative DSP platform) and they have explained us that they don't receive any report about suffering from these vibration annoying advertising. So vibration won't be a problem soon and in my opinion is something from the past.
This case is a special case we have to consider. As services can be added to websites via iframe too, blind or deaf people should have it already active to enjoy not only advertising but future haptic services or applications that enrich the content for them. If we add a pop-up message only deaf people could be able to notice and blind/old people will not be able to activate. Nevertheless, if they have a person that can disable/unable for them in the browser, they have to do nothing to enjoy it. In fact I have been talking to a friend of mine that is expert in Typhlotechnia (accessibility technologies) from ONCE (Spanish Disabled Organization) whom I worked in 2014 in "Touchover", a research project to allow blind people to touch images in smartphones (feeling roughness, image edges, buttons, Braille code, etc, using the phone vibration), has made me some comments about this:
In my opinion the small damage created by sporadic malicious advertising (that obviously trends to zero in the short term), is not an excuse to limit the use of vibration API in a good way, specially when so many advantages can be obtained from it. What do you think about it @lubin2010? |
FWIW I disagree with this characterization. In general the web ecosystem is really struggling due to a large variety of categories of bad advertisements and we are NOT seeing an "obvious trend to zero" or even any real trend to improving ad quality and performance. Instead one clear trend is that ad blocking is becoming extremely popular with no sign of slowing down. So big picture, on the Chrome team we're committed to trying hard to tackle EVERY instance of web users complaining about annoying advertisements (following the lessons learned years ago by pop-up blockers). If we don't, there may not be much of a business model for the mobile web in a few years whatsoever! That said, in this case I'm still confident that we can come up with something which avoids 99% of the potential for abuse while enabling much more of the legitimate use cases than our current solution does. |
|
@RByers I don't agree with your approach either. Ad blocking grow is not due to malicious ads we are talking about in this group, but just because ads exist. Advertising may be annoying for users (as it is on TV) but free contents are paid via advertising, like it is on TV. And people wants free content without advertising, that's the reason why. People that doesn't want advertising are installing ad blockers not because they receive vibrating ads, or Malvertising but because they don't like ads at all. That's the truth. In fact those blockers are expected to rise in 2017 up to 86 millions against thousand of millions without them installed. In fact, ad blocking is caused because of user experience, privacy and speed challenges. One of our goals when creating Haptter is to provide high quality advertising experiences to minimize ad blockers installation. Nevertheless, by using such browser control approach I think we protect users from malicious vibration (the aim of this group) and allow people enjoy other formats. Obviously people who doesn't like ads will continue using ad blockers... or maybe not, who knows. Thanks for your comments and I hope we can find the best solution to it. |
I don't believe this is true. We are getting a lot of user complaints about those malicious ads both internally and externally. For example, if you search 'ad vibrate phone' on Google it shows many user complaints. Also some data (e.g, this report) show that "Ads are annoying and intrusive" is one of the top reasons that people use ad blockers, and AFAIK the common belief is that if all ads become benign and clean, people won't have the incentive to use ad blockers.
Tested with this page: Firefox use both the top frame's origin & the iframe origin (eg., the map origin) for permission, eg., once you allow say "haptter.com" to use vibrate, any pages with an embedded vibrate video from "haptter.com" will be allowed to use vibrate.
I agree that allowing vibrate after a user gesture might enable most use cases within iframe, But for the top frame case, it might be hard to predict (based on the initial data from @dominickng that most vibrate calls are on sites with no engagement scores at all). So if we need to find a solution, should we find one that work for both iframe and top-level pages in the long run? |
I've filed #43 to discuss the meta issue of whether or not interventions should even be a thing. Let's keep this issue focused on the specific problem of the right design for the vibration API. |
I was thinking of the top-level page question as distinct from the issue here (which so far has focused just on cross-origin iframes). Since Chrome is already shipping something for cross-origin iframes, perhaps it makes the most sense to keep this issue focused to that more narrow (and tractable) problem, and maybe start brainstorming about the larger question in a new issue? |
|
Thanks for your comments @lubin2010 sure there are malicious vibrating ads. That's why we are here, and also there are non malicious vibrating ads and content as you now know. So now we should find the way, and as @RByers told above, we should concentrate in the vibration API, its current and possible uses in the future. We have to think about all users (ables, disables, etc), not the users that complain, install ad blockers for any reason, and modify actively the advertising ecosystem in a malicious way. In fact users that complain don't install blocking advertising I'm afraid ;-). In our case, we have to think about an easy way to protect users from "vibrating malvertising" allowing haptic advertising and other haptic applications that users may like. I again ask you all if is there is any inconvenience/consequence/dificulty/policy break/etc by adding a new chrome setting disallowing vibrating when user decides he/she is exposed with abuse to vibration content? Correct me if I'm wrong, but this "simple" modification has no changes in the ecosystem, no changes in haptic videos, no changes in publishers websites, no change at all, and provides full user control over his/her phone. Let me know what do you think. This is a debate, right? |
It is explicitly against Chrome UI policy to make settings for such things. We are constantly pushed in UI review to avoid at all costs asking users what they prefer and instead try to do what most users prefer by default (basically Chrome UI leads are unwilling to let Chrome settings become the endless list of choices like Firefox - even though many of us engineering types would personally prefer that for ourselves). However, if we feel like we don't have an accurate understanding of what users prefer we can potentially use a temporary dialog to collect data on that. Eg. in a small random subset of cases where a cross-origin iframe has triggered vibration we could potentially present a dialog / button that said something like "this page is trying to vibrate your device: allow, deny" and anonymously send the results to Google. Then if users choose deny >50% of the time we'd know with confidence that disabled-by-default best reflects what our users want the default behavior to be. |
|
I don't understand well your comment @RByers . I have tried to search through Chromium project and I can't find what you mean. Can you clarify where, in the Chrome UI policy, adding a Vibrate/not vibrate (or any new selection control) is against Chrome UI policy? Nevertheless your idea is not bad, I devise several problems though:
We are open to make any tests because we are confident about the results due to the several tests we have done during the last two years, independently of age or sex, blind, deaf, etc. But as time goes by, maybe we will not exist so this discussion and the solution you decide may have no effect on our future situation. Sorry if I seem naif but if the past vibration policy (always on) has been changed to the new one (always off) policy, why not reactivating it and think it a little bit more to not affect us, by the moment? This way we can try to continue our business, we will have more tests and results that can share with Chromium to understand users behavior. Further, isn't it possible to add us to a Chrome Whitelist somehow? I know I look desperate but I'm really desperate, sorry. Thanks to all for your efforts. |
Sorry, this is really about "Chrome UI policy" which as far as I can see isn't documented in detail as part of the chromium open source project (though the high level principles from which it follows is here). The chromium code could in principle be different, but when we ship any new UI in Google Chrome we go through an internal UI review process. While we debate the right long-term behavior (and eventual standardization) here @lubin2010 is in the process of changing chromium to enable vibrate after the user has tapped on the frame as we discussed above. This will enable the "tap to enable awesome haptic feedback" UI of the player we discussed above. With any luck this will be available in a Chrome Canary release within a week or so for you to try out and give us feedback on.
Note that it doesn't help us decide what chromium should do by default to know how users feel about some specific content like yours unless there's some sort of fundamental identifying property of that content other than just the URL. Chromium doesn't use URL whitelists to change behavior depending on the website being visited. What I was thinking was that we could, in principle, show a dialog to a random subset of Chrome users when a cross-origin iframe triggered a vibration (but otherwise allow the vibration). Based on our existing analysis we expect the large majority of such cases today to be abusive, so we'd expect most users to click the "block vibration" option. This would give us a clear signal that most users today would prefer the capability to be off by default. But this has the limitation you mention of being biased against any cases users do like which happen to be rare today. The conclusion I draw from this is that no such global setting is acceptable (either it's off by default and leads to annoying users most of the time, or is on by default and leads to blocking legitimate use cases most of the time). So this experiment is only worth doing if there's a compelling argument to be made for why we might be wrong about most existing cases today being annoying to users. The better solution IMHO is to attempt to separate the "abusive" and "engaging rich interactive" use cases so we can reason about them separately. This is what we get from the "enabled once the user taps" option, with the addition of an explicit API that the publisher / ad network can use to completely enable or completely disable vibrations. Then when the user has interacted explicitly with the frame OR the publisher / ad network has indicated they expect a "engaging rich interactive" use case vibration is enabled.
Yes it's very unfortunate that we didn't learn of the impact to you during the 2 months the change was out in Chrome 55 test releases (dev and beta channel), or in the ~6 weeks after that while Chrome 56 was being tested for release final release. At this point we can make changes over the next several weeks and will probably succeed in getting permission to merge those back into the Chrome 57 release. |
|
Thanks for your answers and explanations @RByers and also all of the team for your efforts and understanding. I'm sure that together we'll find the best solution for this. Relating to your comment about @lubin2010 efforts:
Do you mean that Chrome Canary (by the way, nice name from Spanish Islands :-) will serve us just to make tests with our test content so we can give you feedback about how it works? This mean that those tests will serve to define if such solution can be a possible solution for Chrome V.57 release? Another question: Will you give us any tests specification previously to those test or do we have to define them according to our criteria? I just want to understand next steps on our side to be prepared and arrange possible configuration modifications with our partners (advertising companies and adservers) if needed. |
I think we're getting a bit too far into Chrome implementation / release details for this cross-browser web-standards design forum. I've posted answers to your questions over on the relevant chromium bug, mind following up there? Sorry to be moving your around 😃 |
|
Yes, I'm a bit confused right now 🙃. But, nevertheless, now I understand what those Chrome Canary 🐤 changes are for. Thanks. When is ready we will test it asap. Have a nice week you all. |
This is to fix the issue of breaking some use cases of vibrate in cross-origin iframes. Once the iframe has ever received a user gesture, it will be allowed to call vibrate. See more context: WICG/interventions#25 BUG=683938 Review-Url: https://codereview.chromium.org/2642263006 Cr-Commit-Position: refs/heads/master@{#445631}
|
The above fix is in Chrome Canary - version 58.0.2992.0 and should be in the next Chrome 57 release. Here's a simple test page - it should only vibrate after it's tapped. |
This is to fix the issue of breaking some use cases of vibrate in cross-origin iframes. Once the iframe has ever received a user gesture, it will be allowed to call vibrate. See more context: WICG/interventions#25 BUG=683938 Review-Url: https://codereview.chromium.org/2642263006 Cr-Commit-Position: refs/heads/master@{#445631} (cherry picked from commit 8f4a520) Review-Url: https://codereview.chromium.org/2654133003 . Cr-Commit-Position: refs/branch-heads/2987@{#95} Cr-Branched-From: ad51088-refs/heads/master@{#444943}
|
Thanks @RByers. We have been testing your test page and it works as you mentioned. Here is a page by Sizmek to provide a demo of Haptter technology applied to a Lexus advertisement that now... works again with Canary version: http://testme.sizmek.es/mobile.php?id=0UKNGG Based on my short experience, this kind of malicious "warning message" ads vibrate just when they appear (pop-up) to create attention so using this user gesture procedure no one will receive vibration on these kind of ads. By the way, just to have real figures, do you have figures on how long does it take to update Chrome version on, let's say >70%% of users, since release is available in Google Play? Is there any difference depending on geographical areas? It is because even though release is in march I need to know the deployment time to get back to our clients. In the mean time I will test beta versions as soon as they are available to detect any issue. |
|
Relating to @RByers comment (6 days ago) about user vibration muting control:
We have realized that if user deactivate vibration intensity for Vibration Notifications (not for feedback), Haptter videos does not vibrate, so it is a way to avoid any page to vibrate, a kind of muting vibration. By the way, I don't know why Vibration Notifications and not Vibration Feedback intensity is connected to Vibration API. In our case it is more natural that Haptic vibration (feedback) should be connected to vibration.API instead, or even not connected at all with any OS setting, but this an OS related issue not for this discussion. Hope this comment helps you. |
|
As this is shipped, I believe this issue should be closed. |
Vibrate is being abused by unsafe third-party content (eg., malicious ads), and some users have complained about it (e.g., this reddit thread). To better protect user, we would like to block vibrate if it is called in cross-origin iframes (eg., a lot of ads are rendered inside cross-origin iframes). The measurement from Chrome shows that vibrate from (same-origin+cross-origin) iframes is being used by ~0.00025% of pages (the metrics link), and so it is considered a low risk removal.
Meanwhile, if really needed, we could provide a permission API to reenable it, since the permissions/feature-policy work is moving forward.
The text was updated successfully, but these errors were encountered: