Some new types #88

michielbdejong · 2020-08-07T07:45:55Z

Here is a list of document types that Tosback2 uses but src/types.js does not yet list. We probably don't want to merge all of these, some include the service name in the document type and some are too similar or even look like typos. I'll tick the boxes of the ones this PR keeps, I'll update the Tosback2 rules at the XML source, not to use any document types that are not ticked here:

michielbdejong · 2020-08-07T08:41:50Z

Not sure how to handle this one, it's basically two privacy policies that apparently both apply:

<docname name="Privacy Policy">
    <url name="https://policies.oath.com/us/en/oath/privacy/index.html" xpath="//main[@id=&apos;site-main&apos;]" reviewed="true">
      <norecurse name="arbitrary" />
    </url>
  </docname>
  <docname name="Flickr Privacy Policy">
    <url name="https://policies.oath.com/us/en/oath/privacy/products/flickr/index.html" xpath="//main[@id=&apos;site-main&apos;]" reviewed="true">
      <norecurse name="arbitrary"/>
    </url>
  </docname>

Same for Gizmo. I'll use privacy for the product-specific one, and privacyFull for the parent company one.

michielbdejong · 2020-08-07T11:01:02Z

I realized that I can't do the full tosback import until we have language support, so I'll put this PR up for review with the additions I made so far, and then we can follow up later once we have support for >=1 docs of the same type for the same service, which is what some of these need.

michielbdejong · 2020-08-07T11:03:05Z

I don't know all the implications of adding (too) many types that are similar to each other, but in general services use very different titles for their legal documents. Some call it Terms of Use, others call it Usage Policy. Should we allow this diversity or force a more strict small set of document types?

michielbdejong · 2020-08-07T11:48:14Z

This does greatly increase the number of times

(Tests skipped for this document type as it is not declared for this services)

is printed when you run npm run validate... :/

MattiSG · 2020-08-07T16:07:42Z

Thank you very much @michielbdejong!

I'll use privacy for the product-specific one, and privacyFull for the parent company one.

We encountered this issue with Skype (parent company Microsoft). In #53, we introduced a document type tosParent. We then found that Skype had a consolidated ToS document which we imported, removing the document type along the way, in #76.
If there is no such consolidated document, then let's re-introduce tosParent from #53 🙂

I can't do the full tosback import until we have language support

Just to double-check: do you mean being able to store documents in different languages? Is the issue the fact that some documents are not in English (which contradicts our current contribution guidelines), or is it that some ToSback documents are tracked in several languages?

Should we allow this diversity or force a more strict small set of document types?

In order to enable comparative analysis, I would find it great to define types independently from the provider-given name. This way, we could compare terms of services or privacy policies across companies, no matter how they call them in their own lingo. This seems reinforced by the future addition of multiple languages: I don't think it would be manageable to translate each type into several languages!

I understand this means being able to better define each type, so that one can find the most appropriate one beyond the names. I see a couple ways this could be solved:

Add a description field to the document types, which would enable a more complete description and would help contributors identify the most appropriate type no matter the provider-given name.
Add a synonyms field to the document types, which would help with disambiguating.
Characterise each document type along three dimensions of the contractual relationship: party 1 / party 2 / object . Example 1, example 2.

This would mean, for example, that:

A “cookie policy” describes the agreement on cookies between service provider and individual end user.
A “privacy policy” describes the agreement on personal data between service provider and individual end user.
A “law enforcement guideline” describes the agreement on service between service provider and law enforcement agents.
“commercial terms” describe the agreement on service between service provider and commercial intermediaries.

I am not yet sure that this characterization is a proper theoretical representation of a contractual relationship, but it does seem to help pragmatically in defining document types. What do you think of it @michielbdejong? Do you have recommendations of people to reach out to to discuss this topic? 🙂

Twitter is really the worst for that (or the best if one considers readability!), as their rules and policies are split in dozens of documents. We added a few in #85, but there are definitely many others.

This does greatly increase the number of times […] is printed when you run npm run validate... :/

I think this workaround is showing its limits. We'll probably have to find a better one.

MattiSG

Thanks again @michielbdejong, this is super useful both towards integrating tosback rules but also to go further in defining types properly! 😃

MattiSG · 2020-08-07T16:08:30Z

src/types.js

    fileName: 'terms_of_service'
  },
+  website_tos: {


In favor of merging with tos, unless I misunderstand and there is a difference.

It's used by for instance Apple to define the ToS of the www.apple.com website, as opposed to their iChat ToS, Game Center ToS, iCloud ToS, and iTunes ToS. Maybe the right thing to do here is to define "the Apple website", iChat, Apple Game Center, iCloud and iTunes all as separate services. It's probably inaccurate to define "Apple" as a single service.

That way, we can have "the tos of www.apple.com" instead of "the website_tos of Apple".

Maybe the right thing to do here is to define "the Apple website", iChat, Apple Game Center, iCloud and iTunes all as separate services.

Yes, strong +1.
This is also what I suggested and we finally decided in #77: Facebook, Facebook Ads and Facebook Payments should all be separate services. This suggests there might be a use for modeling the service provider in the end, but right now let's declare each service independently 🙂

MattiSG · 2020-08-07T16:08:51Z

src/types.js

@@ -1,12 +1,72 @@
 export const TYPES = {
  tos: {


Maybe we should expand acronyms 🤔

Yep 👍 , I was thinking the same the last week.

MattiSG · 2020-08-07T16:09:37Z

src/types.js

+    name: 'Vendor Terms of Service',
+    fileName: 'vendor_terms_of_service'
+  },
+  tou: {


In favor of merging with tos, unless I misunderstand and there is a difference.

MattiSG · 2020-08-07T16:09:44Z

src/types.js

+    name: 'Acceptable Use Policy',
+    fileName: 'acceptable_use_policy'
+  },
+  termsAndConditions: {


In favor of merging with tos, unless I misunderstand and there is a difference.

MattiSG · 2020-08-07T16:11:10Z

src/types.js

+    name: 'Terms and Conditions',
+    fileName: 'terms_and_conditions'
+  },
+  termsAndPrivacyPolicy: {


We can add this, or we can ask contributors to select the subset of the document which is about ToS and about privacy, especially now that it's been made easier with #70… Could we have some examples of this @michielbdejong? 🙂

Good point, and it applies in a few other cases as well. I'll do that.

MattiSG · 2020-08-07T16:13:05Z

src/types.js

+    name: 'Cookie Policy',
+    fileName: 'cookie_policy'
+  },
+  cookieAndAdPolicy: {


In favor of merging with cookiesPolicy, unless I misunderstand and there is a difference.

MattiSG · 2020-08-07T16:13:22Z

src/types.js

  reviewGuidelines: {
    name: 'Review Guidelines',
    fileName: 'review_guidelines'
  },
+  cookiePolicy: {


In favor of merging with cookiesPolicy.

MattiSG · 2020-08-07T16:14:11Z

src/types.js

  cookiesPolicy: {
    name: 'Cookies Policy',
    fileName: 'cookies_policy'
  },
+  copyright: {


Could we have examples, in order to understand if this is about describing copyright owners, about DMCA, or about providing copyright licenses?

MattiSG · 2020-08-07T16:14:21Z

src/types.js

+    name: 'Consumer Terms of Sale',
+    fileName: 'consumer_terms_of_sale'
+  },
+  securityAndPrivacy: {


In favor of merging with privacy, unless I misunderstand and there is a difference.
Could we have an example?

src/types.js

MattiSG · 2020-08-07T16:20:21Z

I'll update the Tosback2 rules at the XML source, not to use any document types that are not ticked here

I see that many of these types contain company names, and are thus trivial to realign (e.g. SAMSUNG PRIVACY POLICY FOR THE U.S. should be privacy).
Some others are syntactic variants, also trivial to realign (e.g. APIs Terms of Use and API Terms of Use).

However some seem more complex, as they are specific to a service type, such as Host Guarantee Terms and Conditions. When these document types are not ticked, what is your intention with them? 🙂

MattiSG · 2020-08-07T16:43:22Z

they are specific to a service type […] what is your intention with them?

Just saw that this was precisely your question in #89 😅

Co-authored-by: Matti Schneider <matti.schneider@diplomatie.gouv.fr>

MattiSG · 2020-08-10T15:15:53Z

Will be impacted by #90, inputs welcome there!

michielbdejong · 2020-08-14T08:46:58Z

Superseded by #90.

MattiSG · 2020-08-14T11:45:08Z

Has been only partly superseded by #90: some types are still missing.

@Ndpnt and myself spent some time yesterday building a mapping table for all the document types you referenced in this PR 🙂

Since you mentioned wanting to edit the original XML files (we could also build a dynamic mapping table), this mapping table maps each ToSBack type to a CGUs type.

Types in bold are new ones that should be created. In italic are documents that we believe should be dropped as the links are outdated.

michielbdejong marked this pull request as draft August 7, 2020 07:46

Some new types

8676f97

michielbdejong force-pushed the new-types branch from 24f5c20 to 8676f97 Compare August 7, 2020 10:59

michielbdejong marked this pull request as ready for review August 7, 2020 10:59

michielbdejong requested review from MattiSG and Ndpnt August 7, 2020 11:03

michielbdejong added a commit to tosdr/tosback2 that referenced this pull request Aug 7, 2020

Comply with OpenTermsArchive/engine#88

9c258d7

MattiSG requested changes Aug 7, 2020

View reviewed changes

michielbdejong and others added 2 commits August 7, 2020 19:54

Update src/types.js

b121fd8

Co-authored-by: Matti Schneider <matti.schneider@diplomatie.gouv.fr>

Update src/types.js

f9161a0

Co-authored-by: Matti Schneider <matti.schneider@diplomatie.gouv.fr>

MattiSG mentioned this pull request Aug 10, 2020

Service-specific document types #89

Closed

michielbdejong closed this Aug 14, 2020

michielbdejong deleted the new-types branch August 14, 2020 08:47

michielbdejong mentioned this pull request Aug 17, 2020

Use ambanum/CGUs for crawling tosdr/edit.tosdr.org#928

Closed

MattiSG mentioned this pull request Sep 29, 2020

Document discussions around document types #155

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some new types #88

Some new types #88

michielbdejong commented Aug 7, 2020 •

edited

Loading

michielbdejong commented Aug 7, 2020 •

edited

Loading

michielbdejong commented Aug 7, 2020

michielbdejong commented Aug 7, 2020

michielbdejong commented Aug 7, 2020 •

edited

Loading

MattiSG commented Aug 7, 2020

MattiSG left a comment

MattiSG Aug 7, 2020

michielbdejong Aug 7, 2020

michielbdejong Aug 7, 2020

MattiSG Aug 9, 2020

MattiSG Aug 7, 2020

Ndpnt Aug 10, 2020

MattiSG Aug 7, 2020

MattiSG Aug 7, 2020

MattiSG Aug 7, 2020

michielbdejong Aug 7, 2020

MattiSG Aug 7, 2020

MattiSG Aug 7, 2020

MattiSG Aug 7, 2020

MattiSG Aug 7, 2020

MattiSG commented Aug 7, 2020

MattiSG commented Aug 7, 2020

MattiSG commented Aug 10, 2020

michielbdejong commented Aug 14, 2020

MattiSG commented Aug 14, 2020

Some new types #88

Some new types #88

Conversation

michielbdejong commented Aug 7, 2020 • edited Loading

michielbdejong commented Aug 7, 2020 • edited Loading

michielbdejong commented Aug 7, 2020

michielbdejong commented Aug 7, 2020

michielbdejong commented Aug 7, 2020 • edited Loading

MattiSG commented Aug 7, 2020

MattiSG left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MattiSG commented Aug 7, 2020

MattiSG commented Aug 7, 2020

MattiSG commented Aug 10, 2020

michielbdejong commented Aug 14, 2020

MattiSG commented Aug 14, 2020

michielbdejong commented Aug 7, 2020 •

edited

Loading

michielbdejong commented Aug 7, 2020 •

edited

Loading

michielbdejong commented Aug 7, 2020 •

edited

Loading