How to create Allow rules in Office 365 for senders over IPv6 (and also for IPv4)

Office 365 now permits anonymous inbound email over IPv6. Most of the functionality works the same in IPv4 as IPv6. However, there are some differences for inbound messages where customers want to allow messages from a particular domain or sender.

Whereas in IPv4, customers could create IP Allow rules, this functionality does not exist in IPv6. The reason is that it is cumbersome to manage IPv6 ranges and you won’t get them all correct anyhow.

Fortunately, it is easier (sort of) to manage IP Allows and Blocks in IPv6. IPv6 requires the senders to authenticate with either SPF or DKIM. Office 365 stamps the results of the SPF check into the Authentication-Results header, for example:

From: user@example.com
Authentication-Results: spf=pass (sender IP is 2207:eab0:3001:a01::123)
 smtp.mailfrom=user@example.com; contoso.com; dkim=pass (signature was
 verified) header.d=example.com;

This header can be used to create Allow rules. You no longer need to keep track of IP addresses, you can just allow the domain.

1. The simple, but less secure, way to create Allow rules for IPv6 (and also works for IPv4)

To quickly allow a message over IPv6, create an Exchange Transport Rule (ETR) that does the following:

a) Looks for spf=pass or dkim=pass in the Authentication-Results header

b) Looks for the sender domain you want to allow

To do this using the Exchange Admin Center:

image

Creating the Allow rule this way requires the domain to authenticate. In IPv6, a domain must pass SPF or DKIM to be allowed into the system, and the advantage of this quick way of creating ETRs is that it also works for IPv4; only real email from the domain bypasses filtering. If the domain is not authenticated in IPv4, this rule will not work and so a spoofed message will undergo filtering most of the time.

2. The more complicated, but more secure, way to create Allow rules for IPv6 (and also works for IPv4)

 

The above ETR works most of the time, but spammers and phishers can craft messages in such a way to pass SPF or DKIM but still spoof the From: address that is displayed in the email client. For example, the spammer can set up their own SPF and DKIM records, but change the From: address to show a different sender than the one that was authenticated.

From: user@example.com

Authentication-Results: spf=pass (sender IP is 2207:eab0:3001:a01::123) smtp.mailfrom=spammer@spammer.com; contoso.com; dkim=pass (signature was verified) header.d=spammer.com;

This is not the most commonly used spam technique but it occurs often enough to cause problems for some users. To prevent this, create an Exchange Transport Rule (ETR) that does both of the following:

a) Looks for spf=pass or dkim=pass in the Authentication-Results header

b) Looks for the authenticated domain in the Authentication-Results header by searching for text patterns (not “text includes”)

image

This uses a combination of regular expressions instead of simple text matches. The two regular expressions in the Authentication-Results header to look for in the ETR are:

spf=pass (sender IP is [a-zd:.]+) smtp.mailfrom=[a-zd_]+@<example.com>

dkim=pass (signature was verified) header.d=<example.com>

image

Replace the highlighted text with the domain you want to allow (but do not include the angle brackets). After you are done, the rule should look something like this:

 

image

This is more complicated than the simple way but it prevents spammers from spoofing a domain and then getting a free pass to the inbox.


3. Why add conditions like SPF=pass or DKIM=pass?

Many customers today create Allow rules for various domains but spammers will frequently spoof those domains and then the message gets to their users’ inboxes. By requiring that a message passes SPF or DKIM, this will no longer occur. Only an authenticated message will skip filtering, meaning a spoofed message will not go unfiltered.

For IPv6, which requires SPF or DKIM, the above mechanisms will work. For IPv4, where a lot of domains still do not authenticate, this will result in some domains not skipping filtering. The means that some domains may get marked as spam even though you created a rule to skip filtering. For high value domains that are prone to spoofing this is okay – it’s better to avoid the malicious emails in your inbox. For low-value that are not prone to spoofing domains, it may be alright to simply create an Allow rule.


 

Related Articles:

ASP.NET MVC Security Bulletin MS14-059 ships to help secure .NET NuGet Libraries

Microsoft Security Bulletin MS14-059 – Important: Vulnerability in ASP.NET MVC Could Allow Security Feature Bypass (2990942)

This is the first release from Microsoft that uses Security Updates for .NET NuGet Libraries Support. This feature enables Microsoft to update app-deployed .NET NuGet libraries, for machines with the .NET Framework 4.5.1 or later version installed. This security bulletin was released on 10/14/2014 as part of the monthly “patch Tuesday”.

This security update is rated “Important” for the ASP.NET MVC 2.0, ASP.NET MVC 3.0, ASP.NET MVC 4.0, ASP.NET MVC 5.0, and ASP.NET MVC 5.1. All potentially impacted applications and machines, should install or deploy this update.

  • The vulnerability could allow security feature bypass if an attacker convinces a user to click a specially crafted link or to visit a webpage that contains specially crafted content designed to exploit the vulnerability 

Security Update Deployment Options:

  1. Automatic Update via Microsoft Update
    1. Installing the MS14-059 patch will secure the machine and all applications hosted on the machine.
    2. Patches will be pushed to all machines with automatic updating enabled if either of the following two criteria are met:
      1.  MVC 2.0, MVC 3.0, or MVC 4.0 is installed, or
      2. The system is running Microsoft .NET Framework 4.5.1 and an application with the affected component (System.Web.Mvc.dll for ASP.NET MVC 2.0, 3.0, 4.0, 5.0, and 5.1) has been previously loaded
  2. Manual install of the MS14-059 patch for customers with Automatic Update disabled, do not meet the above Microsoft Update criteria, or are unsure if their machine is secure
    1. Installing the MS14-059 patch will secure the machine and all applications hosted on the machine.
    2. Customers can check for updates using the Microsoft Update service, or can install the patch directly from Microsoft Download Center (KB2990942)
  3. Updated NuGet packages have been published to NuGet.org for MVC 3.0, MVC 4.0, MVC 5.0, MVC 5.1 to address this security vulnerability
    1. It is recommended that all customers who do not control their server should redeploy each application after downloading and installing the updated NuGet packages.
    2. It is also recommended that customers update apps to use the updated versions of these NuGet packages to ensure that they are testing with those versions.
    3. For more information on the released ASP.NET MVC NuGet packages, please review the Security Update Deployment section of the MS14-059 bulletin
    4. For more information about managing NuGet Packages using the NuGet dialog, see Managing NuGet Packages Using the Dialog.

There are some known issues with this update where some ASP.NET MVC 3 and ASP.NET MVC 4 project can no longer build in Microsoft Visual Studio after the update is applied.

 What does the update do to my system and how is my MVC application affected? 

  • For MVC 2.0, 3.0, 4.0, 5.0, and 5.1, the MSI update installs the fixed assembly (System.Web.Mvc.dll) in the GAC. Vulnerable versions of the assembly (System.Web.Mvc.dll) that were deployed with applications are overridden by the secure version in the GAC.
  • For MVC 3.0 and MVC 4.0, it is possible to install the vulnerable  version of System.Web.Mvc.dll in the GAC. The fixed version is installed in the GAC with a higher version number and accompanying publisher policy that redirects previous versions of the assembly to the new version. 

More details about this vulnerability and can be found in the security bulletin MS14-059. Please refer to the “Update FAQ” of the security bulletin to better understand how Microsoft security updates for .NET NuGet Libraries are supported. Please refer to the “Security Update Deployment” for more information on NuGet packages and deployment and patch details.

 

Top 10 Microsoft Developer Links for Tuesday, October 28, 2014

  1. Brian Harry: TechEd Europe 2014 News
  2. Brian Harry: Visual Studio Online is in Europe!
  3. Scott Guthrie: Azure: New Marketplace, Network Improvements, New Batch Service, Automation Service, more
  4. Vibhor Kapoor: Exciting updates to Microsoft Azure at TechEd Europe, enabling simplicity, scale and innovation
  5. Charles Sterling: Announcing a simplified browser-based authoring and configuration experience for Load Testing
  6. Charles Petzol: Free Ebook – Creating Mobile Apps with Xamarin.Forms (Preview Edition)
  7. Marius Schulz: Asynchronously Bootstrapping AngularJS Applications with Server-Side Data
  8. Joshua Weber: Application Insights SDK (0.11.0-prerelease)
  9. Nick Summers: Microsoft releases Kinect v2 SDK 2.0, allows devs to publish apps in the Windows Store
  10. Rowan Miller: EF7 – What Does “Code First Only” Really Mean

2171

Sitecore Commerce 7.5 now available!

Sitecore Commerce 7.5 is now available immediately from the Sitecore Developer Network. Building upon the strong foundation set with 7.2, Sitecore Commerce 7.5 adds: Support for Sitecore Experience Platform 7.5, including leveraging the Experience Database for all analytics data gathering and personalization Underlying support for Microsoft SQL Server 2014 and Microsoft BizTalk Server 2013 R2 A number of performance, debugging, stability, and maintainability improvements This release includes all…(read more)

Q&A with the SharePoint MVP Experts Chat On Oct 29th @1pm EST or 10am PDT

Hello everyone

We are launching our SharePoint MVP Expert Chats again!  Do you or someone you know have questions about SharePoint 2010 or 2013?  Or SharePoint Online and Office 365?  Please join us October 29th at 1pm EST or 10am PDT where you can have your questions answered live by the Microsoft MVP Experts!  We will be using the Reddit Ask Me Anything format.  This is new to us but many of Microsoft teams are using this medium now.  Please create a Reddit account beforehand so you can be ready to ask questions.  More information on the chat and room location will be available on Oct 29th in the SharePoint forum.  Hope you can join us!

https://www.reddit.com/r/sharepoint

 

MVP Experts Participating:

1. Andrew Connell

2. Cathy Dew

3. Doug Hemminger

4. Doug Ware

5. Eric Shupps

6. Gavin Barron

7. John Ross

8. Kris Wagner

9. Randy Drisgill

10. Sahil Malik

11. Sean McNeill

12. Shane Young

13. Spencer Harbar

14. Todd Bleeker

15. Trevor Seward

16. Wictor Wilen

HDInsight Storm Topology Submission Via VNet

1. Introduction

To submit a Storm topology to an HDInsight cluster, a user can RDP to the headnode of the cluster and run storm command. This is not always convenient. It is actually possible to submit a Storm topology from outside of an HDInsight cluster. The idea is to create an HDInsight Storm cluster with a configured Virtual Networks (VNet), and submit Storm topology from a machine that is connected to the VNet.

There are many types of VNet so with VNet support we can actually submit topology from Azure VM, other Azure services, on-premises infrastructure or developer boxes.

To show case the idea, I’ll show you how to use an Azure VM to submit a Storm topology via VNet.

2. Step-by-step Instructions

1) Create a Cloud-Only VNet in Azure portal. You can use the “QUICK CREATE” button.

  

 

2) Create a VM using the created VNet, this will be the VM from which we submit Storm topology. You need to use “FROM GALLERY” button and on page 4 you need to choose the VNet that we just created.

 

3) Create a Storm cluster using the created VNet. Note you need to use “custom create” and specify the VNet name in Region/Virtual Network section.

  

4) Find out the FQDN of the active head node of HDInsight Storm cluster using REST API.

This is a Powershell script to help you get the FQDN of the active head node:

function Get-ActiveFQDN(
    [String]
    [Parameter( Position=0, Mandatory=$true )]
    $ClusterDnsName,
    [String]
    [Parameter( Position=1, Mandatory=$true )]
    $Username,
    [String]
    [Parameter( Position=2, Mandatory=$true )]
    $Password)
{
    $DnsSuffix = “.azurehdinsight.net”
    $ClusterFQDN = $ClusterDnsName + $DnsSuffix
    $webclient = new-object System.Net.WebClient
    $webclient.Credentials = new-object System.Net.NetworkCredential($Username, $Password)
    $Url = “https://” + $ClusterFQDN + “/clusteravailability/status”
    $Response = $webclient.DownloadString($Url)
    $JsonObject = $Response | ConvertFrom-Json
    Write-host $JsonObject.LeaderDnsName
}

  
This script will print out something like this:

headnode1.<clusterdnsname>.b1.internal.cloudapp.net

5) RDP to the Azure VM we just created. Copy Storm bits from HDInsight head node (c:appsdiststorm-xxx or %STORM_HOME%) to Azure VM (let’s say we copy to c:storm folder); Install Java 1.7 runtime (either Oracle or OpenJDK is fine).

6) On the Azure VM, make sure the following configurations (environment variable and Storm configurations) are correctly set:

Environment variable:

    JAVA_HOME = “<your java installation path>”

storm.yaml (c:stormconfstorm.yaml):

    nimbus.host: headnode1.<clusterdnsname>.b1.internal.cloudapp.net

7) On the Azure VM, submit a Storm topology using storm.cmd command line like this:

C:stormbin>storm jar ..contribstorm-starterstorm-starter-<version>-jar-with-dependencies.jar storm.starter.WordCountTopology wordcountSampleTopology

Then on the Azure VM you can manage topology status using Storm UI web page (start IE and enter the address like this):

http://headnode1.<clusterdnsname>.b1.internal.cloudapp.net:8772/

This is how easy it is. Enjoy storming!

Dutch water company Evides benefits from the OpenText and Microsoft Alliance

 

As a productivity and platform company a key part of our strategy is working with and investing in our partners to deliver enterprise solutions that extend our core capabilities to deliver value to our customers. A great example of this in practice comes from Evides Waterbedrijf (Evides), a Dutch water company headquartered in Rotterdam, serving 2.5 million people and businesses in The Netherlands.

imageEvides has a Microsoft first strategy so they naturally looked at implementing Microsoft SharePoint for a repository, records and document management and archiving solution. But to meet core requirements SharePoint would have required additional third party modules from several vendors that would expose Evides to future risk due to the greater number of vendors and the potential for future incompatibilities.

In addition to being a Microsoft shop, Evides has been a longtime user of OpenText solutions and to make a long story short they selected OpenText’s Content Server to provide the core foundation of the solution along with SharePoint. As Gerry van Meijel, Head of Document Management Department, at Evides says: “Top among the factors for selecting OpenText was the strong, long standing, strategic partnership between OpenText and Microsoft. Their global relationship and track record gave us the confidence to proceed knowing their respective solutions will continue to work seamlessly together.”

It’s a great success story of how OpenText and Microsoft work together to provide business value and minimize customer risk. You can read about the OpenText – Microsoft Alliance here and the full story on how we jointly delivered business value to Evides Waterbedrijf here. Enjoy! – Jon C. Arnold

Интернет "просто работает" при любом способе ввода: Mouse Events, Touch Events и Pointer Events

Мы недавно объявили о поддержке API-интерфейса Touch Event в Internet Explorer для Windows Phone 8.1 с обновлением в рамках нашей стратегии добиться того, чтобы Интернет “просто работал” для наших пользователей. Это означает, что теперь Internet Explorer поддерживает все три основных API-интерфейса ввода с помощью указателя: Mouse Events, Touch Events и Pointer Events. Работать с Интернетом на мобильных устройствах стало удобнее, однако в то же время разработчики начинают задумываться, какой API лучше использовать.

Чтобы помочь разработчикам понять, в каких случаях следует использовать каждый из этих API, мы решили поделиться своими обновленными советами, а также размышлениями о перспективах развития веб-платформы с учетом того, что API-интерфейс Pointer Events скоро будет поддерживаться в Firefox, тогда как в Google недавно приняли решение отказаться от реализации этой спецификации.

Сравнение и противопоставление моделей

Мы хотим, чтобы разработчики использовали ту технологию ввода, которая им подходит. Мы предоставляем API-интерфейс Touch Events с высоким уровнем взаимодействия, позволяющий охватить наибольшее число современных браузеров, и передовой API-интерфейс Pointer Events, позволяющий использовать более простые модели программирования, предоставлять больше возможностей, обеспечить поддержку большего числа устройств, создавать более удобный интерфейс с высокой скоростью реагирования и максимально эффективно использовать аппаратное ускорение. Ниже представлен детальный разбор характеристик и возможностей каждой модели.

  Mouse Events Touch Events Pointer Events
Поддержка мыши   1  
Поддержка традиционного сенсорного ввода 2    
Поддержка мультисенсорного ввода      
Поддержка пера, Kinect и других устройств 2    
Предоставление событий появления указателя над элементом, ухода с него, входа, выхода и наведения      
Запуск асинхронного панорамирования или масштабирования для аппаратного ускорения      
Спецификация W3C   3 3
Возможность использования в разных браузерах на мобильных устройствах     4
Возможность использования в разных браузерах на настольных компьютерах     4

1 По крайней мере в некоторых браузерах на платформе Android события касания могут активироваться для ввода с помощью мыши. Однако при использовании событий касания невозможно отличить такой ввод с помощью мыши от фактического ввода с помощью касаний.

2 Все браузеры активируют некоторые события мыши для традиционного сенсорного ввода, чтобы обеспечить совместимость с веб-страницами, предназначенными для ввода с помощью мыши. Однако в настоящее время при использовании событий касания невозможно отличить сенсорный ввод от фактического ввода с помощью мыши. Аналогично ввод с использованием жестов Kinect в Internet Explorer для Xbox также будет активировать некоторые события мыши для обеспечения базовой совместимости.

3 Спецификация Pointer Events сейчас имеет статус Candidate Recommendation и скоро перейдет в разряд Recommendation. Спецификация Touch Events имеет статус Recommendation. В 2012 г. участники рабочей группы Web Events решили прекратить работу над Touch Events версии 2 и закрыть группу в пользу стандартизации Pointer Events.

4 Полная поддержка событий указателя доступна в Internet Explorer и скоро будет реализована в Firefox. Частичная поддержка (touch-action API) доступна в Chrome, Firefox и Opera и рассматривается для Safari WebKit. Модель событий указателя может использоваться в разных браузерах через объекты polyfill, такие как Google Polymer Pointer Events и Hand.JS.

Прочтите эту статью на сайте HTML5 Rocks. В ней более подробно рассматриваются некоторые из этих отличий и проблем.

Быстродействие

Быстродействие играет для ввода, особенно сенсорного, очень важную роль. В действительности вы просто проводите пальцами по стеклянной поверхности, но мы хотим, чтобы это воспринималось как перемещение по веб-странице. Вот почему мы потратили 3 года на переработку архитектуры сенсорного ввода в Internet Explorer, чтобы сделать этот процесс четырехпотоковым и использовать ускорение на базе графического процессора (начато в Internet Explorer 10 и улучшено в Internet Explorer 11). Мы спроектировали события указателя, чтобы использовать типы архитектур, которые начали появляться в других современных браузерах.

Панорамирование и масштабирование обычно являются самыми важными сенсорными взаимодействиями, составляя более 60 % всех сенсорных жестов в Internet Explorer и Chrome для Windows. Почти в каждом приложении или веб-приложении и почти на каждом сайте используются панорамирование и масштабирование. Эти жесты наглядно демонстрируют скорость ввода. Если панорамирование медленно начинается (со скачком и задержкой) или отрывисто выполняется (с потерей кадров), вы замечаете это и вспоминаете о том, что это просто стекло.

При использовании Touch Events перед началом панорамирования или масштабирования требуется синхронное выполнение JavaScript, что может вызывать серьезные проблемы быстродействия — порядка сотен миллисекунд или больше. Поэтому переход на использование Pointer Events может существенно улучшить управление с помощью касаний:

Демонстрация возможного влияния Touch Events на скорость панорамирования и масштабирования (на примере Android LG Nexus 5 и Windows Phone HTC 8x).
Спецификация Pointer Events позволяет использовать асинхронные сенсорные операции с аппаратным ускорением, что часто приводит к повышению быстродействия.

На примере этой простой тестовой страницы (настроенной с задержкой 1000 мс), разработанной Риком Байерсом (Rick Byers) из группы Chrome, при использовании событий касания в Internet Explorer мы видим, что первый кадр панорамирования не отрисовывается, пока сенсорный контакт не переместится в течение 1020 мс на 4,8 см, что четко заметно пользователю. Простая замена обработчиков Touch Event обработчиками Pointer Event снижает эту задержку до 31 мс и 0,3 см — улучшение больше, чем в 32 раза.

Хотя задержка в этой тестовой странице внесена искусственно, она была создана для того, чтобы продемонстрировать фундаментальную проблему быстродействия, часто встречающуюся в Интернете. На практике нам попадались страницы с задержкой лучше и хуже 1000 мс. Эта переменная неограниченная зависимость от основного потока браузера приводит к непредсказуемому поведению и мешает достижению оптимального времени отклика в 1 мс. Исследователи из подразделения перспективных научных исследований Microsoft Research продемонстрировали поразительное влияние такого сокращения времени ожидания на пользователей. Мы все еще на пути к времени отклика в 1 мс при панорамировании и масштабировании и считаем спецификацию Pointer Events критически важным шагом к достижению этой цели.

Pointer Events также имеют дополнительные функции, отсутствующие в Touch Events, например события появления указателя над элементом, ухода с него, входа и выхода, о которых просили разработчики, а также дополнительные функции, требующие некоторых дополнительных затрат времени. Но мы инвестировали средства в сокращение этих затрат. На дополнительную проверку нажатий, необходимую для этих компонентов, обычно уходит всего ~0,15 мс, и у нас есть идеи относительно того, как можно улучшить этот показатель, если подтвердится, что это позволит разработчикам достичь быстродействия 60 кадров в секунду.

Совместимость

В записи блога, в которой объявлялось о поддержке Touch Events, мы упомянули о проблемах, связанных с использованием Интернета на настольных компьютерах и мешающих нам обеспечить совместимость и перенести этот API на такие устройства. Например, если API-интерфейсы Touch Events включены на настольном компьютере, в следующих распространенных моделях программирования нарушается поддержка мыши:

В этой неправильной модели не подключена критически важная обработка событий мыши в любом браузере, поддерживающем Touch Events (независимо от того, имеется ли у устройства сенсорный экран). Это вызывает множество проблем, таких как неправильная работа меню, раскрывающихся списков, значков общего доступа и других элементов, при использовании мыши на таких сайтах, как Web MD, Macys, Onet, Pages Juanes, Globo, Samsung, Taobao, Huffington Post и других.

Чтобы сделать сенсорный ввод более удобным для пользователей и упростить жизнь разработчикам, мы планируем:

  • Добавить поддержку Touch Event в Internet Explorer в Windows Phone (сделано).
  • Сотрудничать с разработчиками сайтов для исправления неполадок, упомянутых выше, надеясь, что в один прекрасный день мы сможем надежно использовать эти API-интерфейсы (работа продолжается: следите за сообщениями электронной почты или твитами от нашей группы по популяризации и за информацией на сайте webcompat.com).
  • Реализовать поддержку Touch Events во всех наших платформах, чтобы сделать матрицу поддержки более понятной для разработчиков (работа продолжается).
  • Принимать участие в реализации Pointer Events в других платформах (работа продолжается в Firefox и Chrome).
  • Активно общаться с разработчиками сайтов и сред, чтобы узнавать их мнение и ожидания относительно веб-платформы.
  • Делиться нашими внутренними проектными документами, схемами архитектур, методиками тестирования и нашим кодом с другими поставщиками браузеров (работа продолжается).

Многим разработчикам будет проще использовать Pointer Events для других браузеров с помощью объектов polyfill, таких как Google Polymer Pointer Events или Hand.JS. Но если вы решите использовать Touch Events, следите за тем, чтобы обеспечить надлежащую поддержку мыши. И никогда не предполагайте, что наличие API-интерфейсов Touch Event означает, что у устройства есть сенсорный экран.

Движение вперед

События ввода остаются одной из важнейших проблем взаимодействия в браузерах и устройствах. Как и большинство проблем взаимодействия, она неминуемо затрагивает как разработчиков, так и пользователей, проявляясь в необходимости использовать сложные модели программирования и возникновении проблем совместимости. Мы стремимся исправить эту ситуацию, работая над обеспечением взаимодействия в нашем браузере и стандартизацией в W3C.

Мы стремимся создать платформу, подходящую как для веб-разработчиков, так и для пользователей. Сообщите нам ваши отзывы. Что подходит вам? А что — нет? Чего вы ждете в дальнейшем? Поделитесь вашим мнением через @iedevchat и системы отслеживания ошибок Chrome и Firefox.

— Джейкоб Росси (Jacob Rossi)
Руководитель программы

Интернет "просто работает" при любом способе ввода: Mouse Events, Touch Events и Pointer Events

Мы недавно объявили о поддержке API-интерфейса Touch Event в Internet Explorer для Windows Phone 8.1 с обновлением в рамках нашей стратегии добиться того, чтобы Интернет “просто работал” для наших пользователей. Это означает, что теперь Internet Explorer поддерживает все три основных API-интерфейса ввода с помощью указателя: Mouse Events, Touch Events и Pointer Events. Работать с Интернетом на мобильных устройствах стало удобнее, однако в то же время разработчики начинают задумываться, какой API лучше использовать.

Чтобы помочь разработчикам понять, в каких случаях следует использовать каждый из этих API, мы решили поделиться своими обновленными советами, а также размышлениями о перспективах развития веб-платформы с учетом того, что API-интерфейс Pointer Events скоро будет поддерживаться в Firefox, тогда как в Google недавно приняли решение отказаться от реализации этой спецификации.

Сравнение и противопоставление моделей

Мы хотим, чтобы разработчики использовали ту технологию ввода, которая им подходит. Мы предоставляем API-интерфейс Touch Events с высоким уровнем взаимодействия, позволяющий охватить наибольшее число современных браузеров, и передовой API-интерфейс Pointer Events, позволяющий использовать более простые модели программирования, предоставлять больше возможностей, обеспечить поддержку большего числа устройств, создавать более удобный интерфейс с высокой скоростью реагирования и максимально эффективно использовать аппаратное ускорение. Ниже представлен детальный разбор характеристик и возможностей каждой модели.

  Mouse Events Touch Events Pointer Events
Поддержка мыши   1  
Поддержка традиционного сенсорного ввода 2    
Поддержка мультисенсорного ввода      
Поддержка пера, Kinect и других устройств 2    
Предоставление событий появления указателя над элементом, ухода с него, входа, выхода и наведения      
Запуск асинхронного панорамирования или масштабирования для аппаратного ускорения      
Спецификация W3C   3 3
Возможность использования в разных браузерах на мобильных устройствах     4
Возможность использования в разных браузерах на настольных компьютерах     4

1 По крайней мере в некоторых браузерах на платформе Android события касания могут активироваться для ввода с помощью мыши. Однако при использовании событий касания невозможно отличить такой ввод с помощью мыши от фактического ввода с помощью касаний.

2 Все браузеры активируют некоторые события мыши для традиционного сенсорного ввода, чтобы обеспечить совместимость с веб-страницами, предназначенными для ввода с помощью мыши. Однако в настоящее время при использовании событий касания невозможно отличить сенсорный ввод от фактического ввода с помощью мыши. Аналогично ввод с использованием жестов Kinect в Internet Explorer для Xbox также будет активировать некоторые события мыши для обеспечения базовой совместимости.

3 Спецификация Pointer Events сейчас имеет статус Candidate Recommendation и скоро перейдет в разряд Recommendation. Спецификация Touch Events имеет статус Recommendation. В 2012 г. участники рабочей группы Web Events решили прекратить работу над Touch Events версии 2 и закрыть группу в пользу стандартизации Pointer Events.

4 Полная поддержка событий указателя доступна в Internet Explorer и скоро будет реализована в Firefox. Частичная поддержка (touch-action API) доступна в Chrome, Firefox и Opera и рассматривается для Safari WebKit. Модель событий указателя может использоваться в разных браузерах через объекты polyfill, такие как Google Polymer Pointer Events и Hand.JS.

Прочтите эту статью на сайте HTML5 Rocks. В ней более подробно рассматриваются некоторые из этих отличий и проблем.

Быстродействие

Быстродействие играет для ввода, особенно сенсорного, очень важную роль. В действительности вы просто проводите пальцами по стеклянной поверхности, но мы хотим, чтобы это воспринималось как перемещение по веб-странице. Вот почему мы потратили 3 года на переработку архитектуры сенсорного ввода в Internet Explorer, чтобы сделать этот процесс четырехпотоковым и использовать ускорение на базе графического процессора (начато в Internet Explorer 10 и улучшено в Internet Explorer 11). Мы спроектировали события указателя, чтобы использовать типы архитектур, которые начали появляться в других современных браузерах.

Панорамирование и масштабирование обычно являются самыми важными сенсорными взаимодействиями, составляя более 60 % всех сенсорных жестов в Internet Explorer и Chrome для Windows. Почти в каждом приложении или веб-приложении и почти на каждом сайте используются панорамирование и масштабирование. Эти жесты наглядно демонстрируют скорость ввода. Если панорамирование медленно начинается (со скачком и задержкой) или отрывисто выполняется (с потерей кадров), вы замечаете это и вспоминаете о том, что это просто стекло.

При использовании Touch Events перед началом панорамирования или масштабирования требуется синхронное выполнение JavaScript, что может вызывать серьезные проблемы быстродействия — порядка сотен миллисекунд или больше. Поэтому переход на использование Pointer Events может существенно улучшить управление с помощью касаний:

Демонстрация возможного влияния Touch Events на скорость панорамирования и масштабирования (на примере Android LG Nexus 5 и Windows Phone HTC 8x).
Спецификация Pointer Events позволяет использовать асинхронные сенсорные операции с аппаратным ускорением, что часто приводит к повышению быстродействия.

На примере этой простой тестовой страницы (настроенной с задержкой 1000 мс), разработанной Риком Байерсом (Rick Byers) из группы Chrome, при использовании событий касания в Internet Explorer мы видим, что первый кадр панорамирования не отрисовывается, пока сенсорный контакт не переместится в течение 1020 мс на 4,8 см, что четко заметно пользователю. Простая замена обработчиков Touch Event обработчиками Pointer Event снижает эту задержку до 31 мс и 0,3 см — улучшение больше, чем в 32 раза.

Хотя задержка в этой тестовой странице внесена искусственно, она была создана для того, чтобы продемонстрировать фундаментальную проблему быстродействия, часто встречающуюся в Интернете. На практике нам попадались страницы с задержкой лучше и хуже 1000 мс. Эта переменная неограниченная зависимость от основного потока браузера приводит к непредсказуемому поведению и мешает достижению оптимального времени отклика в 1 мс. Исследователи из подразделения перспективных научных исследований Microsoft Research продемонстрировали поразительное влияние такого сокращения времени ожидания на пользователей. Мы все еще на пути к времени отклика в 1 мс при панорамировании и масштабировании и считаем спецификацию Pointer Events критически важным шагом к достижению этой цели.

Pointer Events также имеют дополнительные функции, отсутствующие в Touch Events, например события появления указателя над элементом, ухода с него, входа и выхода, о которых просили разработчики, а также дополнительные функции, требующие некоторых дополнительных затрат времени. Но мы инвестировали средства в сокращение этих затрат. На дополнительную проверку нажатий, необходимую для этих компонентов, обычно уходит всего ~0,15 мс, и у нас есть идеи относительно того, как можно улучшить этот показатель, если подтвердится, что это позволит разработчикам достичь быстродействия 60 кадров в секунду.

Совместимость

В записи блога, в которой объявлялось о поддержке Touch Events, мы упомянули о проблемах, связанных с использованием Интернета на настольных компьютерах и мешающих нам обеспечить совместимость и перенести этот API на такие устройства. Например, если API-интерфейсы Touch Events включены на настольном компьютере, в следующих распространенных моделях программирования нарушается поддержка мыши:

В этой неправильной модели не подключена критически важная обработка событий мыши в любом браузере, поддерживающем Touch Events (независимо от того, имеется ли у устройства сенсорный экран). Это вызывает множество проблем, таких как неправильная работа меню, раскрывающихся списков, значков общего доступа и других элементов, при использовании мыши на таких сайтах, как Web MD, Macys, Onet, Pages Juanes, Globo, Samsung, Taobao, Huffington Post и других.

Чтобы сделать сенсорный ввод более удобным для пользователей и упростить жизнь разработчикам, мы планируем:

  • Добавить поддержку Touch Event в Internet Explorer в Windows Phone (сделано).
  • Сотрудничать с разработчиками сайтов для исправления неполадок, упомянутых выше, надеясь, что в один прекрасный день мы сможем надежно использовать эти API-интерфейсы (работа продолжается: следите за сообщениями электронной почты или твитами от нашей группы по популяризации и за информацией на сайте webcompat.com).
  • Реализовать поддержку Touch Events во всех наших платформах, чтобы сделать матрицу поддержки более понятной для разработчиков (работа продолжается).
  • Принимать участие в реализации Pointer Events в других платформах (работа продолжается в Firefox и Chrome).
  • Активно общаться с разработчиками сайтов и сред, чтобы узнавать их мнение и ожидания относительно веб-платформы.
  • Делиться нашими внутренними проектными документами, схемами архитектур, методиками тестирования и нашим кодом с другими поставщиками браузеров (работа продолжается).

Многим разработчикам будет проще использовать Pointer Events для других браузеров с помощью объектов polyfill, таких как Google Polymer Pointer Events или Hand.JS. Но если вы решите использовать Touch Events, следите за тем, чтобы обеспечить надлежащую поддержку мыши. И никогда не предполагайте, что наличие API-интерфейсов Touch Event означает, что у устройства есть сенсорный экран.

Движение вперед

События ввода остаются одной из важнейших проблем взаимодействия в браузерах и устройствах. Как и большинство проблем взаимодействия, она неминуемо затрагивает как разработчиков, так и пользователей, проявляясь в необходимости использовать сложные модели программирования и возникновении проблем совместимости. Мы стремимся исправить эту ситуацию, работая над обеспечением взаимодействия в нашем браузере и стандартизацией в W3C.

Мы стремимся создать платформу, подходящую как для веб-разработчиков, так и для пользователей. Сообщите нам ваши отзывы. Что подходит вам? А что — нет? Чего вы ждете в дальнейшем? Поделитесь вашим мнением через @iedevchat и системы отслеживания ошибок Chrome и Firefox.

— Джейкоб Росси (Jacob Rossi)
Руководитель программы

Интернет "просто работает" при любом способе ввода: Mouse Events, Touch Events и Pointer Events

Мы недавно объявили о поддержке API-интерфейса Touch Event в Internet Explorer для Windows Phone 8.1 с обновлением в рамках нашей стратегии добиться того, чтобы Интернет “просто работал” для наших пользователей. Это означает, что теперь Internet Explorer поддерживает все три основных API-интерфейса ввода с помощью указателя: Mouse Events, Touch Events и Pointer Events. Работать с Интернетом на мобильных устройствах стало удобнее, однако в то же время разработчики начинают задумываться, какой API лучше использовать.

Чтобы помочь разработчикам понять, в каких случаях следует использовать каждый из этих API, мы решили поделиться своими обновленными советами, а также размышлениями о перспективах развития веб-платформы с учетом того, что API-интерфейс Pointer Events скоро будет поддерживаться в Firefox, тогда как в Google недавно приняли решение отказаться от реализации этой спецификации.

Сравнение и противопоставление моделей

Мы хотим, чтобы разработчики использовали ту технологию ввода, которая им подходит. Мы предоставляем API-интерфейс Touch Events с высоким уровнем взаимодействия, позволяющий охватить наибольшее число современных браузеров, и передовой API-интерфейс Pointer Events, позволяющий использовать более простые модели программирования, предоставлять больше возможностей, обеспечить поддержку большего числа устройств, создавать более удобный интерфейс с высокой скоростью реагирования и максимально эффективно использовать аппаратное ускорение. Ниже представлен детальный разбор характеристик и возможностей каждой модели.

  Mouse Events Touch Events Pointer Events
Поддержка мыши   1  
Поддержка традиционного сенсорного ввода 2    
Поддержка мультисенсорного ввода      
Поддержка пера, Kinect и других устройств 2    
Предоставление событий появления указателя над элементом, ухода с него, входа, выхода и наведения      
Запуск асинхронного панорамирования или масштабирования для аппаратного ускорения      
Спецификация W3C   3 3
Возможность использования в разных браузерах на мобильных устройствах     4
Возможность использования в разных браузерах на настольных компьютерах     4

1 По крайней мере в некоторых браузерах на платформе Android события касания могут активироваться для ввода с помощью мыши. Однако при использовании событий касания невозможно отличить такой ввод с помощью мыши от фактического ввода с помощью касаний.

2 Все браузеры активируют некоторые события мыши для традиционного сенсорного ввода, чтобы обеспечить совместимость с веб-страницами, предназначенными для ввода с помощью мыши. Однако в настоящее время при использовании событий касания невозможно отличить сенсорный ввод от фактического ввода с помощью мыши. Аналогично ввод с использованием жестов Kinect в Internet Explorer для Xbox также будет активировать некоторые события мыши для обеспечения базовой совместимости.

3 Спецификация Pointer Events сейчас имеет статус Candidate Recommendation и скоро перейдет в разряд Recommendation. Спецификация Touch Events имеет статус Recommendation. В 2012 г. участники рабочей группы Web Events решили прекратить работу над Touch Events версии 2 и закрыть группу в пользу стандартизации Pointer Events.

4 Полная поддержка событий указателя доступна в Internet Explorer и скоро будет реализована в Firefox. Частичная поддержка (touch-action API) доступна в Chrome, Firefox и Opera и рассматривается для Safari WebKit. Модель событий указателя может использоваться в разных браузерах через объекты polyfill, такие как Google Polymer Pointer Events и Hand.JS.

Прочтите эту статью на сайте HTML5 Rocks. В ней более подробно рассматриваются некоторые из этих отличий и проблем.

Быстродействие

Быстродействие играет для ввода, особенно сенсорного, очень важную роль. В действительности вы просто проводите пальцами по стеклянной поверхности, но мы хотим, чтобы это воспринималось как перемещение по веб-странице. Вот почему мы потратили 3 года на переработку архитектуры сенсорного ввода в Internet Explorer, чтобы сделать этот процесс четырехпотоковым и использовать ускорение на базе графического процессора (начато в Internet Explorer 10 и улучшено в Internet Explorer 11). Мы спроектировали события указателя, чтобы использовать типы архитектур, которые начали появляться в других современных браузерах.

Панорамирование и масштабирование обычно являются самыми важными сенсорными взаимодействиями, составляя более 60 % всех сенсорных жестов в Internet Explorer и Chrome для Windows. Почти в каждом приложении или веб-приложении и почти на каждом сайте используются панорамирование и масштабирование. Эти жесты наглядно демонстрируют скорость ввода. Если панорамирование медленно начинается (со скачком и задержкой) или отрывисто выполняется (с потерей кадров), вы замечаете это и вспоминаете о том, что это просто стекло.

При использовании Touch Events перед началом панорамирования или масштабирования требуется синхронное выполнение JavaScript, что может вызывать серьезные проблемы быстродействия — порядка сотен миллисекунд или больше. Поэтому переход на использование Pointer Events может существенно улучшить управление с помощью касаний:

Демонстрация возможного влияния Touch Events на скорость панорамирования и масштабирования (на примере Android LG Nexus 5 и Windows Phone HTC 8x).
Спецификация Pointer Events позволяет использовать асинхронные сенсорные операции с аппаратным ускорением, что часто приводит к повышению быстродействия.

На примере этой простой тестовой страницы (настроенной с задержкой 1000 мс), разработанной Риком Байерсом (Rick Byers) из группы Chrome, при использовании событий касания в Internet Explorer мы видим, что первый кадр панорамирования не отрисовывается, пока сенсорный контакт не переместится в течение 1020 мс на 4,8 см, что четко заметно пользователю. Простая замена обработчиков Touch Event обработчиками Pointer Event снижает эту задержку до 31 мс и 0,3 см — улучшение больше, чем в 32 раза.

Хотя задержка в этой тестовой странице внесена искусственно, она была создана для того, чтобы продемонстрировать фундаментальную проблему быстродействия, часто встречающуюся в Интернете. На практике нам попадались страницы с задержкой лучше и хуже 1000 мс. Эта переменная неограниченная зависимость от основного потока браузера приводит к непредсказуемому поведению и мешает достижению оптимального времени отклика в 1 мс. Исследователи из подразделения перспективных научных исследований Microsoft Research продемонстрировали поразительное влияние такого сокращения времени ожидания на пользователей. Мы все еще на пути к времени отклика в 1 мс при панорамировании и масштабировании и считаем спецификацию Pointer Events критически важным шагом к достижению этой цели.

Pointer Events также имеют дополнительные функции, отсутствующие в Touch Events, например события появления указателя над элементом, ухода с него, входа и выхода, о которых просили разработчики, а также дополнительные функции, требующие некоторых дополнительных затрат времени. Но мы инвестировали средства в сокращение этих затрат. На дополнительную проверку нажатий, необходимую для этих компонентов, обычно уходит всего ~0,15 мс, и у нас есть идеи относительно того, как можно улучшить этот показатель, если подтвердится, что это позволит разработчикам достичь быстродействия 60 кадров в секунду.

Совместимость

В записи блога, в которой объявлялось о поддержке Touch Events, мы упомянули о проблемах, связанных с использованием Интернета на настольных компьютерах и мешающих нам обеспечить совместимость и перенести этот API на такие устройства. Например, если API-интерфейсы Touch Events включены на настольном компьютере, в следующих распространенных моделях программирования нарушается поддержка мыши:

В этой неправильной модели не подключена критически важная обработка событий мыши в любом браузере, поддерживающем Touch Events (независимо от того, имеется ли у устройства сенсорный экран). Это вызывает множество проблем, таких как неправильная работа меню, раскрывающихся списков, значков общего доступа и других элементов, при использовании мыши на таких сайтах, как Web MD, Macys, Onet, Pages Juanes, Globo, Samsung, Taobao, Huffington Post и других.

Чтобы сделать сенсорный ввод более удобным для пользователей и упростить жизнь разработчикам, мы планируем:

  • Добавить поддержку Touch Event в Internet Explorer в Windows Phone (сделано).
  • Сотрудничать с разработчиками сайтов для исправления неполадок, упомянутых выше, надеясь, что в один прекрасный день мы сможем надежно использовать эти API-интерфейсы (работа продолжается: следите за сообщениями электронной почты или твитами от нашей группы по популяризации и за информацией на сайте webcompat.com).
  • Реализовать поддержку Touch Events во всех наших платформах, чтобы сделать матрицу поддержки более понятной для разработчиков (работа продолжается).
  • Принимать участие в реализации Pointer Events в других платформах (работа продолжается в Firefox и Chrome).
  • Активно общаться с разработчиками сайтов и сред, чтобы узнавать их мнение и ожидания относительно веб-платформы.
  • Делиться нашими внутренними проектными документами, схемами архитектур, методиками тестирования и нашим кодом с другими поставщиками браузеров (работа продолжается).

Многим разработчикам будет проще использовать Pointer Events для других браузеров с помощью объектов polyfill, таких как Google Polymer Pointer Events или Hand.JS. Но если вы решите использовать Touch Events, следите за тем, чтобы обеспечить надлежащую поддержку мыши. И никогда не предполагайте, что наличие API-интерфейсов Touch Event означает, что у устройства есть сенсорный экран.

Движение вперед

События ввода остаются одной из важнейших проблем взаимодействия в браузерах и устройствах. Как и большинство проблем взаимодействия, она неминуемо затрагивает как разработчиков, так и пользователей, проявляясь в необходимости использовать сложные модели программирования и возникновении проблем совместимости. Мы стремимся исправить эту ситуацию, работая над обеспечением взаимодействия в нашем браузере и стандартизацией в W3C.

Мы стремимся создать платформу, подходящую как для веб-разработчиков, так и для пользователей. Сообщите нам ваши отзывы. Что подходит вам? А что — нет? Чего вы ждете в дальнейшем? Поделитесь вашим мнением через @iedevchat и системы отслеживания ошибок Chrome и Firefox.

— Джейкоб Росси (Jacob Rossi)
Руководитель программы