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.
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
I've created an Opt in / out. If opting in, I enable google analytics and store the decision in a cookie for 30 days. However if i don't store the decision in a cookie at all, then on every page the popup will continue to popup if a user doesn't consent.
Is it ok to store a true / false data in a cookie? Or does that not comply with GDPR?
It is actually not a "catch 22".
In order to store something on user's computer, you must ask permission. The true/false cookie which represents the users consent, can be stored - but also must be done with their consent.
If you consider the true/false cookie "necessary", you can simply ask their permission to store "necessary cookies". In order for the site to work (e.g. don't popup a new window on every page), they must consent to that minimal level.
For example, take a look at what CookieBot does:
"Necessary cookies" are disabled. It cannot be unchecked.
Both General Data Protection (GDPR) and ePrivacy Regulations (EPR) have to be adhered to, neither one succeeds each other.
Note each European country in-acts GDPR and EPR legislation into law slightly differently from each other some more strict than others. So you should always consult the law for your own European country also.
For the setting use of cookies and other similar technologies, you (data controller)
normally needs user consent as required by Regulation 5(3) of the EPR to use these types of technologies.
However, you don't need consent where the cookie or other technology is
"strictly necessary" to provide you with the service the user is seeking – for example, cookies
which may be needed to provide you with a functioning website which the user wants to
access.
Hence you do not have to ask permission to store "Strictly Necessary" cookies on the users device. Storing a cookie on the users devices to remember the users opt in or out consent of cookies as far as I know is allowed without asking for their permission.
As far as I am aware you are allowed to store that type of cookies for a maximum of 6 months before you have to ask for their opt in consent again. So you could potentially increase from the 1 month you have set.
The exact EU guidelines regarding the "strictly necessary" exception read as follows:
"This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."
If you are uncertain whether your cookies are strictly necessary, it's best to consult your local regulators. They can provide additional insight and specific guidelines for your country. In general, it is best to err on the side of caution. Unless you absolutely know your cookies are strictly necessary, assume they are not.
On the flip side...
Any cookie that does not fall under the "strictly necessary" definition needs consent before you can store it on a visitor's device.
Nearly all Google and Facebook API services require you to set tracking cookies and marketing cookies on the users devices i.e. you can not use Google/Facebook Login, Google reCapatcha,Google Adsense, Google Analyitics without getting prior consent from the user to set tracking cookies and marketing cookies on the users devices.
It is the trade off of using the free APIs that Google and Facebook offer, they offer the SDKs and APIs for free but require personal information from the user in return.
Google's terms require you to obtain consent from the user before using their APIs and thus setting tracking cookies and marketing cookies on the users device.
We have a website where I store the user's country selection choice. I do not track it from their IP address or anything else.
Plus I use Google Analytics which also uses cookies to store some data. Should I state that GA uses cookies as it a service which I use for analytics?
Now I am confused whether to show a message saying that we use cookies to enhance the user's experience on out website.
Yes you should show the consent even if a third party library uses them (eventually you use that data).
But you don't have to explicitly mention what is stored in cookies.
There are open source multi language alternatives you can easily use to embed the concent into your UI.
A Note
I have a very good understanding of sessions and the theory of secure web-based authentication, etc., so please don't start with the basics, or give ambiguous answers. I am not looking for Best Practices, because I am aware of them. I am looking for the real risks behind them, that make the Best Practices what they are.
I have read, and agree with the principals that nothing more than a Session identifier should be stored in a Cookie at any given time.
The Story
However... I've inherited a rusty old app that stores the Username, Password, and an additional ID, in a Cookie, which is checked throughout the site as verification/authorization.
This site is always (can only be) accessed via HTTPS, and depending on your stance, is a "low-risk" website.
The application, in its current state, cannot be re-written in such a way as to handle Sessions - to properly implement such a thing would require, essentially, re-writing the entire application.
The Question
When suggesting to the-powers-that-be that storing their user's IDs/Passwords in plaintext, in a Cookie, is an extremely bad idea, what real risks are involved, considering the connection is always initiated and manipulated via HTTPS?
For example: is the only obvious way to compromise this information via Physical Access to the machine containing the Cookie? What other real risks exist?
HTTPS just protects against a man-in-the-middle attack by encrypting the data that goes across the wire. The information would still be in plain text on the client. So anything on the client's computer can go through that cookie information and extract the pertinent information.
Some other risks include cross-site scripting attacks which can enable cookie theft and who knows what kind of browser vulnerabilities which can enable cookie theft.
A given browser's "cookie jar" might not be stored securely, i.e., an attacker might be able to read it without physical access to the machine, over a LAN, or from a distributed filesystem (e.g., if the machine's storing user homes on a storage server, to allow for roaming), or via an application running on the machine.
Some browsers keep cookies in a file that can be displayed on the computer. IE6 comes to mind.
It seems to me that cookies are not all that restricted to a single site. Lots of advertising uses cookies across multiple sites. If I go to NextTag and look for a Nikon D700 camera then
I see NextTag advertisements on slashdot.org. This is an example of a cross-site cookie. Most users use the same password all over the web so if you store the password to one site and make it even a little easy to get to then malicious folks will sooner or later get to it.
To summarize this would be a very very very bad idea. On sites that I work on we don't save users passwords at all. We convert them to a hash key and save the hash key. That way we can validate the user but if we loose the content then there is no exposure of passwords. And this is on the server side, not the browser side!
Most cookies are limited time credentials. For example, session identifiers that expire after a couple hours or are forgotten when the browser windows. Even if the attacker gains access to the session cookie, they are guaranteed neither continued access to the account nor the ability to prevent the original account holder from logging in. Preventing long term account compromise is one of the reasons users are asked for their old password before being allowed to enter a new one.
A cookie containing a username and password, if disclosed, is much longer lived. Also, many users share their passwords between websites. As others have pointed out, the cookie could easily be disclosed via Cross-Site Scripting.
Finally, is the cookie marked with the "Secure" flag? If its not, an active network attack can easily force the browser to disclose it, even if HTTPS is used to serve the entire site.
People here already mentioned the "man in the middle" attack. The thing is that even with https it is still possible. There are different ways to do this - some of them relay on physical access to the network some of them do not.
The bottom line here is that even with https it is still possible for somebody to insert itself between your app and the browser. Everything will be passed through and will look from the browser exactly the same EXCEPT the server certificate. The intruder will have to send his own instead of the real one.
The browser will detect that there are problems with the certificate - usually it will either be issued to a different dns name or, more likely it will not be verified.
And here is the problem: how this violation is presented to the end user and how end user will react. In older versions of IE all indication of the problem was a small broken lock icon on the right side of the status bar - something which many people would not even notice.
How much risk this introduces depends on what is the environment and who (how trainable) the users are
Two two main vulnerabilities are cross site scripting attacks and someone accessing the user's machine.
Have you thought about just storing a password hash in the cookie instead of the raw password? It would require some coding changes but not nearly as many as swapping out your entire authentication system.
This is something of a rant, as well as a question.
There are some sites, like Facebook, where you would only want to be logged into one account at a time.
But everything from blogging sites to email always force you to logout before you can login to another account.
And I understand the security implications, and how it would make cookie-based sessions a little more complex, but why don't we see more of this?
Why would multiple users from a single client at once be a bad idea?
I think this is something that should be implemented by browsers by allowing multiple sessions, each using their own cookie/authentication/etc.
That would probably be the best solution, as it would seem to work for all sites, and require no updating for them, and, although I don't know much about it, it doesn't seem it would be terribly difficult to implement either.
The simple problem is most sessions are implemented via cookies, and there's pretty much no way to do it without cookies.
And the way cookies work, is they're bound to the domain/path, and all cookies tied to that domain are sent.
So if you permit logging in twice via 2 different cookies, the problem would be every successive page would send BOTH cookies, and the server seeing both has no idea which "user" you are acting as.
The only way around this is passing a "thread" identity around all links, ( that is, rewriting every site link on the fly to foo.bar?thread=2 or thread=1 to indicate which session to use for things ), and that is a complete nightmare, not to mention security implications.
The only real way to do it is via browser-sand boxing, the user tells the browser that a given tab and all offshoots use one cookie set, and the other tab and all offshoots use another.
In essence, its not a problem that can be solved by websites in a practical manner.
There's practically no good way to store this information without delegating the controls to how it works to browsers to implement, and for users to manually indicate when they want to fork into a new session.
Single Browser Solutions that should work today:
CookieSwap 0.5.1 Appears to permit "state toggles" of various cookie sets, It doesn't do whats needed to be able to just browse them magically, but its a partial solution. I can't test it myself because it hasn't been ported to FF3.1 yet.
"Why would multiple users from a single client at once be a bad idea?"
It is not a bad idea at all, but the use of HTTP forces us down this route.
Most client/server protocols are stateful - the client need authenticate only once during handshaking and then the session is represented by the socket connection. If you lose the connection, you lose the session and have to re authenticate. It is then trivial to write applications that allow multiple sessions (as the same or different users) in the one process.
HTTP is stateless. The client needs to re-authenticate in some manner with every single request. Authentication information is usually stored in cookies so that the user does not have to be involved once the initial authentication has been done. Cookies, however, are global - not just global with in the process, but generally across instances/invocations of the application. Hence, you are stuck with a single session.
You would have thought that web-app designers would have looked at this massive limitation as a sign that HTTP just isn't the right protocol for client/server application development.
One implication of multiple logins is how to manage privileges. Say I have two accounts, one has a privilege to delete user accounts and my other account lacks this privilege.
If I can be logged into both of my accounts simultaneously, which takes precedence, do I have the union of privileges from both accounts, or only the intersection of privileges held by both accounts?
If I have the union of privileges, would I have the ability to combine privileges from these multiple accounts in ways that give me too much power? What does this imply for Sarbanes-Oxley compliance?
An equivalent issue is seen in SQL, with respect to "roles" which are groups of privileges. In standard SQL, a given account is permitted to adopt multiple roles, but only one at a time. This prevents you from exercising too much privilege.
Cookie state is anchored to the host header...
Use a different hostname or use its IP address directly to connect to the site. Depending on the site you may be able to setup a bunch of local host aliases to the site allowing you to be logged on more than once as each alias would have its own cookie state.
If the site redirects to itself to force a specific host header the aliasing won't work and you'll need to use multiple browsers.
Since you first wrote the question, IE 8 has been officially released and it has a built-in feature that does what you want. From the "File" menu, click on "New Session." This will open a new window that will not share session cookies with the original window, allowing you to be logged into the same site under different logins simultaneously.
http://blogs.msdn.com/ie/archive/2009/05/06/session-cookies-sessionstorage-and-ie8.aspx
You can do multiple sessions in Firefox by creating new profiles - run: firefox.exe -P which is where you can set up multiple profiles that will have different cookies - you can run multiple sessions of firefox at the same time by using firefox.exe -P "profileName" -no-remote . the no remote will only allow 1 window per session but will also allow multiple sessions at the same time.