1

Let's say we have two companies "WeServe" and "OurContent" and the following relationships, who is the Controller and who is the Processor or are they Joint Controllers (Art. 26 GDPR) or is there another kind of relationship or none at all?

  1. The most common case, ourcontent.com is hosted by WeServe. OurContent is the Controller and WeServe the Processor, OurContent has a Privacy Policy and needs a DPA from WeServe
  2. ourcontent.weserve.com or weserve.com/ourcontent with 100% of the content provided by OurContent. Still the same as #1, apart from WeServe being visible in the url, I suppose.
  3. OurContent uploads content to WeServe and is part of some page of WeServe and it may not be obvious content is provided by OurContent and OurContent does not access or process any user data.
  4. OurContent uploads content to WeServe and is part of some page of WeServe but processes some user data on its own.
  5. WeServe crawls the internet and copies and hosts content of OurContent that processes some user data. OurContent doesn't necessarily mind this and may even see this as beneficiary. (similar to the wayback machine of archive.org)
  6. OurContent provides a url to WeServe which will be embedded in an iframe as part of a page of WeServe.
  7. WeServe embeds pages of OurContent in an iframe in its own pages. (e.g. Google Translate).

If WeServe and OurContent are Joint Controllers, is it sufficient if both of them have their own privacy policy with a contact point for data subjects or do they need an extra arrangement that combines both privacy policies in an appropriate way?

Improve this question

1 Answer 1

Reset to default
1

It is a very difficult question, but I'll try to answer anyway.

  1. The most common case, ourcontent.com is hosted by WeServe. OurContent is the Controller and WeServe the Processor, OurContent has a Privacy Policy and needs a DPA from WeServe
  2. ourcontent.weserve.com or weserve.com/ourcontent with 100% of the content provided by OurContent. Still the same as #1, apart from WeServe being visible in the url, I suppose.
  3. OurContent uploads content to WeServe and is part of some page of WeServe and it may not be obvious content is provided by OurContent and OurContent does not access or process any user data.
  4. OurContent uploads content to WeServe and is part of some page of WeServe but processes some user data on its own.
  5. WeServe crawls the internet and copies and hosts content of OurContent that processes some user data. OurContent doesn't necessarily mind this and may even see this as beneficiary. (similar to the wayback machine of archive.org)
  6. OurContent provides a url to WeServe which will be embedded in an iframe as part of a page of WeServe.
  7. WeServe embeds pages of OurContent in an iframe in its own pages. (e.g. Google Translate).
  1. OurContent is the controller, and WeServe is a processor, as you said, because WeServe is processing personal data on your behalf.
  2. Same as number 1, provided that the situation is exactly the same (OurContent actually collects the data, and WeServe just hosts it).
  3. If OurContent really doesn't collect or process any personal data, then they are nothing, neither a controller nor a processor. If WeServe processes personal data for their own private purposes (for example tracking visitors) then they are a controller. Users will visit your content on WeServe, but they will just have to accept WeServe's privacy policy.
  4. OurContent is a controller, and WeServe is a processor of personal data on behalf or Ourcontent (so it's the same situation as number 1). However, if WeServe also processes personal data for their own private purposes (for example tracking visitors), then they would also be a controller. I'm not sure whether they would be a separate controller or a joint controller though.
  5. OurContent is a controller. WeServe is also a controller, and definitely a separate controller. I really don't think that blocking crawlers and bots is required by the GDPR, as that would mean totally changing the way the internet works. So, any crawler or bot is free to browse the internet, as long as they comply with the GDPR. And whether they comply or not is their own business, I guess.
  6. (or 7) I don't really understand the difference between point 6 and point 7, in both cases it sounds like WeServe is embedding an iframe from OurContent. Speaking of iframes in general, they should be treated like separate pages that open up automatically. The privacy issues arise when the "automatically opened page" (the iframe) also collects personal data and the visitor does not expect it. The visitor is automatically sending the IP to the page in the iframe, but they could also be sending a cookie and other data. So the main site is a controller, and the iframed side is also a controller, they are separate. However, the main site can't let its visitors send personal data to another controller without consent, so most iframes should be blocked by default.
Improve this answer
6
  • The only difference between 6 and 7 is who initiates the relationship. In 6 OurContent asks WeServe to show its own website as part of WeServe's pages, in 7 WeServe just does it without being asked to do so. OurContent might not even know about this, but does not mind it either.
    – Dennis Kaselow
    Sep 9, 2018 at 15:20
  • Interesting point about crawlers in #5. They process personal data without any data subjects giving them any type of consent. That wasn't even what I wanted to know, but interesting nonetheless. The difference between #4 and #5 is more like the difference between #6 and #7. Whether the content by OurContent is hosted because OurContent wants it to be hosted or because WeServe offers some kind of service where they add OurContent on their own without informing OurContent. - the answer to this will probably be the same as to the answer to #7.
    – Dennis Kaselow
    Sep 9, 2018 at 15:30
  • Any idea about the privacy policy part?
    – Dennis Kaselow
    Sep 9, 2018 at 15:33
  • @DennisKaselow, if WeServe put OurContent in an iframe without asking them for permission, then I guess it would behave more or less like a kind of search engine hosting your public content.They are therefore separate controllers, if they process your data in any way (maybe just crawling?). Otherwise they might not even be controllers nor processors I guess. As for the privacy policies of joint controllers, I can't help you because I'm not even sure what joint controllers are. I actually posted a question here asking for concrete examples after reading your question.
    – reed
    Sep 9, 2018 at 16:36
  • The (weird) thing is, if you put some content in an iframe, you are just hosting a link to the iframed page and you don't have any control over the content. You don't need to crawl it or anything, you might not even know what that content is at all. It's the browser that will then request the content and display it in the iframe. So technically if you really only host an iframe you are hosting a link, and you aren't processing any personal data at all.
    – reed
    Sep 9, 2018 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .