Recherche avancée

Sur d’autres sites (4981)

• WebVTT as a W3C Recommendation

  2 décembre 2013, par silvia

  Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

  How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

  I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

  Advantages of a W3C Recommendation

  TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

  Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

  WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

  As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

  Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

  The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5
  element) towards a feature set that is clearly defined to be supported by such non-updating devices.

  Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

  Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

  Choice of Working Group

  FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

  The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

  Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

  Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

  A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

  So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

  The forthcoming process

  At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

  What I came away with is the following process :

  1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
  2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
  3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
  4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
  5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
  6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
  7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

  The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

  There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

  The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

  Making the best of a complicated world

  WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

  At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.

• Lawful basis for processing personal data under GDPR with Matomo

  30 avril 2018, par InnoCraft

  Disclaimer : this blog post has been written by digital analysts, not lawyers. The purpose of this article is to explain what is a lawful basis and which one you can use with Matomo in order to be GDPR compliant. This work comes from our interpretation of the following web page from the UK privacy commission : ICO. It cannot be considered as professional legal advice. So as GDPR, this information is subject to change. GDPR may be also known as DSGVO in German, BDAR in Lithuanian, RGPD in Spanish, French, Italian, Portuguese. This blog post contains public sector information licensed under the Open Government Licence v3.0.

  The golden rule under GDPR is that you need to have a lawful basis in order to process personal data. Note that it is possible to not process personal data with Matomo. When you do not collect any personal data, then you do not need to determine a lawful basis and this article wouldn’t apply to you.

  “If no lawful basis applies to your processing, your processing will be unlawful and in breach of the first principle.“

  Source : ICO, based on article 6 of GDPR.

  As you may process personal data in Matomo, you have to :

  1. define a lawful basis.
  2. document your choice.
  3. inform your visitor about it in a privacy notice.

  Even if you think you don’t process personal data, we recommend reading this post about personal data in Matomo (personal data may be hidden in many ways).

  Note that if you are processing special category data (ethnic origin, politics, religion, trade union membership…) or criminal offence data ; extra responsibilities are applied, and we will not detail them in this blog post.

  1 – Define a lawful basis

  There are 6 different lawful bases all defined within article 6 of the GDPR official text :

  1. Consent : the data subject has given consent to the processing of his or her personal data for one or more specific purposes.
  2. Contract : processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract.
  3. Legal obligation : processing is necessary for compliance with a legal obligation to which the controller is subject.
  4. Vital interests : processing is necessary in order to protect the vital interests of the data subject or of another natural person.
  5. Public task : processing is necessary for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller.
  6. Legitimate interests : processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party ; except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

  As you can see, most of them are not applicable to Matomo. As ICO is mentioning it within their documentation :

  “In many cases you are likely to have a choice between using legitimate interests or consent.”

  “Consent” or “Legitimate interests” : which lawful basis is the best when using Matomo ?

  Well, there is no right or wrong answer here.

  In order to make this choice, ICO listed on their website different questions you should keep in mind :

  • Who does the processing benefit ?
  • Would individuals expect this processing to take place ?
  • What is your relationship with the individual ?
  • Are you in a position of power over them ?
  • What is the impact of the processing on the individual ?
  • Are they vulnerable ?
  • Are some of the individuals concerns likely to object ?
  • Are you able to stop the processing at any time on request ?

  From our perspective, “Legitimate interests” should be used in most of the cases as :

  • The processing benefits to the owner of the website and not to a third party company.
  • A user expects to have their data kept by the website itself.
  • Matomo provides many features in order to show how personal data is processed and how users can exercise their rights.
  • As the data is not used for profiling, the impact of processing personal data is very low.

  But once more, it really depends ; if you are processing personal data which may represent a risk to the final user, then getting consent is for us the right lawful basis.

  If you are not sure, at the time of writing ICO is providing a tool in order to help you make this decision :

  

  Note that once you choose a lawful basis, it is highly recommended not to switch to another unless you have a good reason.

  What are the rights that a data subject can exercise ?

  According to the lawful basis you choose for processing personal data with Matomo, your users will be able to exercise different rights :

  	Right to be informed	Right of access	Right to erasure	Right to portability	Right to object	Right to withdraw consent
  Legitimate interests	X	X	X		X
  Consent	X	X	X	X		X

   

  • Right to be informed : whatever the lawful basis you choose, you need to inform your visitor about it within your privacy notice.
  • Right of access : as described in article 15 of GDPR. Your visitor has the right to access the personal data you are processing about them. You can exercise their right directly within the page “GDPR Tools” in your Matomo.
  • Right to erasure : it means that a visitor will be able to ask you to erase all their data. You can exercise the right to erasure directly within the page “GDPR Tools” in your Matomo.
  • Right to portability : it means that you need to export the data which concern the individual in a machine-readable format and provide them with their personal data. You can exercise their right directly within the page “GDPR Tools” in your Matomo.
  • Right to object : it means that your visitor has the right to say no to the processing of their personal data. In order to exercise this right, you need to implement the opt-out feature on your website.
  • Right to withdraw consent : it means that your visitor can remove their consent at any time. We developed a feature in order to do just that. You can learn more by opening the page “Privacy > Asking for consent” in your Matomo.

  2 – Document your choice

  Once you choose “Legitimate interests” or “Consent” lawful basis, you will have some obligations to fulfill. From our interpretation, “Legitimate interests” means writing more documentation, “Consent” means a more technical approach.

  What should I do if I am processing personal data with Matomo based on “Legitimate interests ?

  ICO is providing a checklist for “Legitimate interests”, below is our interpretation :

  • Check that legitimate interests is the most appropriate lawful basis.

  Our interpretation : document and justify why you choose this lawful basis in particular. This tool from ICO can help you.

  • Understand your responsibility to protect the individual’s interests.

  Our interpretation : you need to take all the measures in order to protect your users privacy and data security. Please refer to our guide in order to secure your Matomo installation.

  • Conduct a legitimate interests assessment (LIA) and keep a record of it to ensure that you can justify your decision. This document is composed of a set of questions on those 3 key concerns : 1) purpose, 2) necessity, 3) balancing.

  1) Purpose :

  • Why do you want to process the data – what are you trying to achieve ?
  • Who benefits from the processing ? In what way ?
  • Are there any wider public benefits to the processing ?
  • How important are those benefits ?
  • What would the impact be if you couldn’t go ahead ?
  • Would your use of the data be unethical or unlawful in any way ?

  2) Necessity :

  • Does this processing actually help to further that interest ?
  • Is it a reasonable way to go about it ?
  • Is there another less intrusive way to achieve the same result ?

  3) Balancing :

  • What is the nature of your relationship with the individual ?
  • Is any of the data particularly sensitive or private ?
  • Would people expect you to use their data in this way ?
  • Are you happy to explain it to them ?
  • Are some people likely to object or find it intrusive ?
  • What is the possible impact on the individual ?
  • How big an impact might it have on them ?
  • Are you processing children’s data ?
  • Are any of the individuals vulnerable in any other way ?
  • Can you adopt any safeguards to minimise the impact ?
  • Can you offer an opt-out ?

  • Identify the relevant legitimate interests.
  • Check that the processing is necessary and there is no less intrusive way to achieve the same result.
  • Perform a balancing test, and be confident that the individual’s interests do not override those legitimate interests.
  • Use individuals’ data in ways they would reasonably expect, unless you have a very good reason.

  Our interpretation : use those data to improve user experience for example.

  • Do not use people’s data in ways they would find intrusive or which could cause them harm, unless you have a very good reason.

  Our interpretation : ask yourself if this data is representing a risk for the individuals.

  • If you process children’s data, take extra care to make sure you protect their interests.
  • Consider safeguards to reduce the impact where possible.

  Our interpretation : Check if your web hosting provider is providing appropriate safeguards.

  • Consider whether you can offer an opt out.

  Our interpretation : Matomo is providing you the opt-out feature.

  • If your LIA identifies a significant privacy impact, consider whether you also need to conduct a DPIA.

  Our interpretation : A DPIA can easily be conducted by using this software from the French privacy commission.

  • Regularly review your LIA and update it when circumstances change.
  • Include information about your legitimate interests in your privacy information.

  As you see, going for “Legitimate interests” requires a lot of written documentation. Let’s see how “Consent” differ.

  What should I do if I am processing personal data with Matomo based on “Consent” ?

  As previously mentioned, using “Consent” rather than “Legitimate interests” is more technical but less intense in terms of documentation. Like for “Legitimate interests”, ICO is providing a checklist for “Consent” which is divided into 3 key categories : 1) asking for consent, 2) recording consent, and 3) managing consent.

  1. Asking for consent :
     1. Check that consent is the most appropriate lawful basis for processing.
     2. Make the request for consent prominent and separate from your terms and conditions.
     3. Ask people to positively opt in. Don’t use pre-ticked boxes or any other type of default consent.
     4. Use clear, plain language that is easy to understand.
     5. Specify why you want the data and what you are going to do with it.
     6. Give individual (‘granular’) options to consent separately to different purposes and types of processing.
     7. Name your organisation and any third party controllers who will be relying on the consent.
     8. Tell individuals they can withdraw their consent.
     9. Ensure that individuals can refuse to consent without detriment.
     10. Avoid making consent a precondition of a service.
     11. If you offer online services directly to children, only seek consent if you have age-verification measures (and parental-consent measures for younger children) in place.
  2. Recording consent :
     1. Keep a record of when and how you got consent from the individual.
     2. Keep a record of exactly what you told them at the time.
  3. Managing consent :
     1. Regularly review consents to check that the relationship, the processing and the purposes have not changed.
     2. Have processes in place to refresh consent at appropriate intervals, including any parental consent.
     3. Consider using privacy dashboards or other preference-management tools as a matter of good practice.
     4. Make it easy for individuals to withdraw their consent at any time, and publicise how to do so.
     5. Act on withdrawals of consent as soon as you can.
     6. Don’t penalise individuals who wish to withdraw consent.

     3 – Inform your visitor about it in a privacy notice

     Privacy notices are an important part within the GDPR process. Read our blog post dedicated to privacy notices to learn more.

     We really hope you enjoyed reading this blog post. Please have a look at our Matomo GDPR guide for more information.

  The post Lawful basis for processing personal data under GDPR with Matomo appeared first on Analytics Platform - Matomo.

• Revision 30966 : eviter le moche ’doctype_ecrire’ lors de l’upgrade

  17 août 2009, par fil@… — Log

  eviter le moche ’doctype_ecrire’ lors de l’upgrade