I'm posting a question here but may be even advice is already good.
To be complied with the GDPR, we are now requested by legal department to clarify the data processing for the cookies we use. For each cookie, we need to clarify:
What data it process
Does that data processing involve a server (like sent to the server) or just proceeded locally
Combine with other information to decide if the cookie is processing personal data or not.
Among the cookies we are having on our website, there are 3rd party cookies set by auth0 custom domain, they are:
Now it's really hard for us to fulfill the request because from what we know and from the document we found on auth0 website, the information we're looking for is not available.
Please help to give advice on how should we find the information we're requested.
You'll find some information here: https://auth0.com/docs/manage-users/cookies/authentication-api-cookies. Also I'd advice you to contact Auth0 directly as they are your "processor" and obliged (under the GDPR article 28) to provide you with the information you need. Unless you can read javascript, you need to ask Auth0 for the purpose(s) of each cookie.
The answer for your 2nd question depends on your implementation. If those are 3rd party cookies (set by Auth0), then they always involve a 3rd party server. This means that personal data (IP addresses) are always processed when those cookies are used.
You will get the answer for your 3rd question once you get information on the purposes of each cookie (why they are being set).
Also your legal team would probably want to know the location of those servers (where end users fetch those cookies). As IP-addresses and other traffic data are being processed, it might involve transfers to 3rd countries (and this is where the GDPR gets really complicated).
Related
I am very confused as to how Safari ITP 2.3 works in certain respects, and why sites can’t easily circumvent it. I don’t understand under what circumstances limits are applied, what the exact limits are, to what they are applied, and for how long.
To clarify my question I broke it down into several cases. I will be referring to Apple’s official blog post about ITP 2.3 [1] which you can quote from, but feel free to link to any other authoritative or factually correct sources in your answer.
For third-party sites loaded in iframes:
Why can’t they just use localStorage to store the values of cookies, and send this data back and forth not as actual browser cookie headers 🍪, but as data in the body of the request or a header like Set-AuxCookie? Similarly, they can parse the response to updaye localStorage. What limits does ITP actually place on localStorage in third party iframes?
If the localStorage is frequently purged (see question 1), why can’t they simply use postMessage to tell a script on the enclosing website to store some information (perhaps encrypted) and then spit it back whenever it loads an iframe?
For sites that use link decoration
I still don’t understand what the limits on localStorage are in third party sites in iframes, which did NOT get classified as link decorator sites. But let’s say they are link decorator sites. According to [1] Apple only start limiting stuff further if there is a querystring or fragment. But can’t a website rather trivially store this information in the URL path before the querystring, ie /in/here without ?in=here … certainly large companies like Google can trivially choose to do that?
In the case a site has been labeled as a tracking site, does that mean all its non-cookie data is limited to 7 days? What about cookies set by the server, aren’t they exempted? So then simply make a request to your server to set the cookie instead of using Javascript. After all, the operator of the site is very likely to also have access to its HTTP server and app code.
For all sites
Why can’t a service like Google Analytics or Facebook’s widgets simply convince a site to additional add a CNAME to their DNS and get Google’s and Facebook’s servers under a subdomain like gmail.mysite.com or analytics.mysite.com ? And then boom, they can read and set cookies again, in some cases even on the top-level domain for website owners who don’t know better. Doesn’t this completely defeat the goals of Apple’s ITP, since Google and Facebook have now become a “second party” in some sense?
Here on StackOverflow, when we log out on iOS Safari the StackOverflow network is able to log out of multiple sites at once … how is that even accomplished if no one can track users across websites? I have heard it said that “second party cookies” still can be stored but what exactly makes a second party cookie different from a third party?
My question is broken down into 6 cases but the overall theme is, in each case: how does Apple’s latest ITP work in that case, and how does it actually block all cases of potentially malicious tracking (to the point where a well-funded company can’t just do the workarounds above) while at the same time allowing legitimate use cases?
[1] https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
I am not sure if the below answers are correct, please comment if they are not:
It seems applications can use localStorage with no problem, up to 7 days. But it won’t be persisted across multiple enclosing domains. I would even recommend using sessionStorage, since the goal is just to have nothing more than a seamless session. You can then roll your own cookie mechanism using a different set of headers, the only thing you can’t implement is http-only cookies.
They can, but ITP won’t let the JavaScript on the enclosing page store cookies (at least, not if your third party domain was flagged as a tracker by Safari).
Yeah, the description of “link decoration” technically doesn’t mention this workaround, but probably Apple has or will update its classifier to handle this workaround.
Yes, if a first-party webpage will send a request to the server and it sets a cookie in the response headers, then these aren’t blocked by ITP, even if it has an iframe to a tracking site. They say that’s not their goal.
Yes, in fact your first-party site can just let your site redirect to google.com and back quickly (like with oAuth) and thereby inform Google of whatever you wanted, without cookies. Google’s JavaScript can do this as well, if you allow it. Then the JavaScript can just load your google-hosted subdomain in an iframe and set a cookie that persists for years, tracking the user. However, ITP 2.3 seems to have also added mitigation to this, so you might use A records instead? https://cookiesaver.io/archives/analytics-guides/cname-cloaking-mitigation-eliminates-safari-itp-workarounds/
Probably the StackExchange network uses a version of #5
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
In the process of making a website GDPR compliant i need to identify and categorize cookies used on that website. Now i came across the issue to differentiate between first and third party cookies.
I was not able to find the information how to do that. So my question is: how can i find out if a cookie is a third-party-cookie with help of the developer tools of chrome and relative to the current website open.
Thanks a lot!
OK user3507003.
I am going to try to answer your question, even though I am not an expert on cookies. I am very interested in the topic however, so as I say, I am going to try to answer your question.
I am going to include background information on the subject as I try to answer your question, as the intent, purpose, and history of website cookies is short and sometimes confusingly often changing. You might like to skip to the TL;DR section near the end, for some reason I felt like pressing computer keyboard buttons for more than an hour and fifteen minutes this morning. I also just like thinking about the idea of "party cookies".
Being sure to define what is meant by "cookie": A 'cookie' is a small piece of data that is sent by a website server as part of the HTTP/S protocol as part of a response for a browser request for a webpage, then is stored locally by the browser, then is sent along with subsequent browser requests for website pages. What can make that confusing is when you ask your browser to ask a webserver for a web page, the request for the webpage can sometimes involve more than one HTTP request and to different servers for different parts of the webpage. Depending on cookie data property values different cookies could sometimes be sent with those different HTTP requests for webpage parts.
That explanation does not explain the difference between first party and third party cookies. It covers both indiscriminately. My US market-leading internet search engine (Google) results ((which should be largely unbiased by account histories except somewhat anonymized cookie data)) for "are there other types of cookies than party cookies" confirms that some websites talk about 'session', 'persistent', and 'third-party' cookies. That distinction is likely not directly relevant to your question, but it might be useful to know.
To be clear, what I think you are asking, and what I am trying to answer, is how you can tell the difference between third party cookies and first party cookies in the context of the developer tool storage inspector, as you have shown in a screenshot of that.
In your screenshot, on the left is an expandable view of the types of data storage that your browser (Chrome) supports, including "Local Storage" and "Cookies", among other types of storage. You have expanded the 'Cookies' section and selected the first item in the 'Cookies' list, and the inspector is showing a list of more than eighteen different cookies, starting with an 'ads_prefs' cookie.
The list on the right, starting with the 'ads_prefs' cookie is a list of cookies that were set by the selected website server in the list on the left. This is where my experience with cookies is less than sure, but I think you are confused that there are now two website domains involved with each cookie in the data you are seeing as in your screenshot.
The list of website domains on the left shows website domain servers that have set cookies as part of the most recent webpage request of your browser. All of the website domain servers that are not the domain of your original webpage request are third party servers with respect to your requested webpage. Those requests to third party servers are often pixel image trackers, advertising brokers, that sort of thing.
The cookies set by any website servers that are not the website domain server for your initial request (the first domain in the Cookie section view list on the left) are, I believe, considered "third party cookies".
The list of cookies on the right has a "Domain" column. What this should mean is that the Chrome browser is conformant to an HTTP/S cookie specification that allows webpage responses to set cookies for your browser that are intended for other webserver domains, and not the server that set the cookie. That "Domain" cookie property name does complicate the vocabulary around first party and third party servers and cookies, but once you understand the context as centered around a browser's webpage request, consistent disambiguation would be excessive.
TL;DR
The cookies set by the first-listed first party server as intended for other webpage domain servers are considered 'first party cookies' (with central respect to your first browser request for a webpage), even though they can involve another website domain as an intended recipient. All of the other cookies set by other servers (that were not the domain webserver for your initial browser webpage request) are 'third party cookies'.
Disclaimer: I could be wrong about some or all of that.
I have a website where I don't ask to user any data, I don't create cookies and I have only AWStats available in the cPanel (preinstalled by the hosting mantainer).
Do I still need to show any legal information (i.e. GDPR, privacy policy, cookie policy) or can I omit all things?
Thanks
You don't need to make any mention of GDPR - that's just one of the applicable laws.
If you don't set any persistent third-party cookies and do not use any third party scripts that set third party cookies (like Google Analytics or Facebook buttons), you don't need a cookie pop-up.
Strictly speaking, your web logs may contain personal data in the form of IP addresses and user agent strings. That data can be reasonably kept for a short period, say 10-30 days, for the purposes of combating abuse, but after that you should either truncate logs or strip out data that can be associated with any individual - and this should be mentioned in your privacy policy too. AWStats typically generates aggregate info from raw logs, and that's fine, so long as it does not end up containing data that allows you to identify individuals (for example, don't store GeoIP data at resolution finer than a city).
You should still have a privacy policy - a policy is just that, it's not something visitors need to agree to, it just tells them how you handle their data. If you don't collect data, don't set cookies, don't share with any third parties, then that's what it needs to say. You don't need a separate cookie policy, especially if you're not using them beyond what's "strictly necessary".
Make sure you have set all applicable HTTP security headers, and (if you're not already) you should be using HTTPS, even for a static site.
Run your site through Webbkoll and Cookiebot to check how the outside world sees it.
BUMP: This is not a dead request. I'm still hoping to get a solid answer from someone at Facebook or anyone else. Thanks.
Revised Inquiry: I don't know if I'm not asking the right question, or if I'm asking a valid question that no one can answer.
New Questions:
Can we use FQL or another means to get all of the requests seen at reqs.php? I'm essentially looking for something like this:
SELECT request_id, app_id FROM apprequest WHERE recipient_uid = me()
Notifications return that data but app requests are often batched into a single record with a link identifying some but not all requests. I want individual records for all app requests currently open. The data to do this must be available, as this is the data used to build notifications! It just seems that this is not being made available to us. :(
Thanks!
Original Inquiry Follows:
I have an app that aggregates various sources of Facebook information for a user. One of the sets of data I'm working on is the collection of apprequests which have been sent to this user by friends. For example, I open GreatApp and click to send a request to you. You may or may not use GreatApp but let's assume you haven't blocked requests from it. You now open my AggregatorApp that shows my request to you, and the included link back to GreatApp. The data you see is the same as at reqs.php but formatted differently, with much more data, and of course simply much better. ;)
I thought that is what we got in apprequests. From this question I'm understanding that apprequests is a collection of requests sent out by the current application.
When using path/me/apprequests, we don't need to specify an app ID. But I believe here we do need to provide an app token rather than a user token. Is that correct? If that's correct then this confirms that the requests are those that this app sent out, not requests generated by other apps.
When using FQL, we need to identify the uid of the app as well as the id of the request in order to query the apprequests table. I get that, but even with a valid request id and app id (and valid permissions) FQL doesn't return request data. (I haven't checked with an app id, maybe that's the key.)
I am hoping people will provide some concrete examples for any of the above, specifically getting inbound requests from other apps, and confirmation about what token or other detail is expected for /apprequests and the apprequests table to return data.
Thanks!
Other threads asking the same question without a good (or any) response:
thread1 thread2
You need to make a graph api request to get the apprequests connection for a user. See the current documentation here: http://developers.facebook.com/docs/reference/api/user/.
In the Connections table, the documentation correctly notes that you need an application access token to retrive the requests to that user. There's a bug in the documentation under (http://developers.facebook.com/docs/reference/api/user/#apprequests) that claims you need a user access token. This is incorrect, and (as you've seen) will return an empty list of requests.
Requests sent by an application are only visible to the application. The user can't see or delete these requests (though they are able to hide the request). The reason for this is that the applications can put data into the requests (255 characters) that's never exposed to the user or other applications.
I don't think there's a way you'll be able to aggregate a user's requests from apps that you don't have an access token for.
What I have found out (before my question was deleted) was that you can't access requests with a user token, and app tokens can only access requests that app has sent (and I found that out myself in the documentation and playing with the graph explorer). Since I know there are iPhone apps and browser plugins for processing requests, I assume they are accessing the page itself and parsing the data (like scraping a site). The downfall to that approach is that on the request page only around 100 requests from each app are shown at one time.
(Unless some people have found a way that they aren't sharing...)
You are right, you need the app_access_token and not the user_access_token.
I think the FB documentation has an error.
The definitive answer was provided by a Facebook developer here in response to my bug report. The resolution is that this is By Design. This relates to the note by #noah-callaway that there's probably some app-specific data in requests that should not be available to other apps.
This is a shame, in my opinion, because as Facebook is all about sharing data among friends, I think it adds a dimension to the ecosystem when apps can share (limited and reasonable) information among one another.
Thanks for the responses!
I'm trying to disable writing data in a specific cookie on a website,
At the same time, i want the data to be sent,
So it means, i send cookie data and don't want to receive any,
Is it possible ?
Cookie is just a mechanism to store information at per client basis or in client layer above the session layer. In general people hate cookies cause they can do creepy stuff and some website is using resources on their PC.
When you say I want to store a cookie that I never want to read, its really shady. No browser should allow this sort of cookie. You might want to re-look at your architecture.
But may be I donno what exactly you mean.