diff --git a/.gitignore b/.gitignore index e8d29c0..58e2d13 100644 --- a/.gitignore +++ b/.gitignore @@ -115,3 +115,4 @@ venv.bak/ test.py *.json +homepage/cache diff --git a/docker-compose.yml b/docker-compose.yml index 8668a44..b2d9edc 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -1,9 +1,13 @@ version: '3' services: - homepage: + proxy: + image: nginx:1.17-alpine + volumes: + - output:/usr/share/nginx/html ports: - - 8000:8000 + - 8000:80 + homepage: build: context: '.' dockerfile: ./Dockerfile.python @@ -11,9 +15,11 @@ services: volumes: - .:/website - homepagedeps:/root/.local - command: make devserver + - output:/website/homepage/output + command: make regenerate environment: DEBUG: 1 volumes: homepagedeps: + output: diff --git a/homepage/content/articles/0040-test-offen-today.md b/homepage/content/articles/0040-test-offen-today.md index aa64d09..a0bce51 100644 --- a/homepage/content/articles/0040-test-offen-today.md +++ b/homepage/content/articles/0040-test-offen-today.md @@ -23,15 +23,15 @@ Although we have dug very deep, things may still contain issues. Therefore, we r ## Offen v0.1.0-alpha.3 -#### Single binary file for Linux, Windows or MacOS +##### Single binary file for Linux, Windows or MacOS [Download](https://get.offen.dev/){: data-button="full"} -#### Your own Offen instance +##### Your own Offen instance [Deploy to Heroku](https://heroku.com/deploy?template=https://github.com/offen/heroku/tree/master){: target="_blank" data-button-mb5="full"} Download or deploy Offen today and give it a spin. *[Check our Docs](https://docs.offen.dev/){: target="_blank"} for detailed instructions.* -We appreciate any feedback. No matter if you have difficulties with the installation, find our UI hard to understand or catch anything unexpected. Please get in touch via [Twitter,](https://twitter.com/hioffen){: target="_blank"} [LinkedIn](https://www.linkedin.com/company/hioffen/){: target="_blank"} or [email.](mailto:hioffen@posteo.de){: target="_blank"} +We appreciate any feedback. No matter if you have difficulties with the installation, find our UI hard to understand or catch anything unexpected. Please get in touch via [Twitter,](https://twitter.com/hioffen){: target="_blank"} [LinkedIn](https://www.linkedin.com/company/hioffen/){: target="_blank"} or [email.](mailto:hioffen@posteo.de){: target="_blank"} We look forward to hearing from you. Happy testing! diff --git a/homepage/content/articles/0050-milestone-3.md b/homepage/content/articles/0050-milestone-3.md index 98285a7..bcca23c 100644 --- a/homepage/content/articles/0050-milestone-3.md +++ b/homepage/content/articles/0050-milestone-3.md @@ -65,7 +65,7 @@ Offen generates client side keys for encrypting data for each user. At the end o ### 1-Click Deploy -Self hosted software is a great fit for privacy focused software like Offen. Yet, it can seem daunting to non-technical users and make them stick to established SaaS solutions longer than needed. This is why we put a lot of effort into finding easy "1-click" options to deploy an Offen instance. In Milestone 3 we have created a 1-click solution for deploying Offen to Heroku: [https://github.com/offen/heroku](https://github.com/offen/heroku). Using free resources only, people interested in running Offen can now deploy a production ready instance to Heroku in less than 1 minute. We hope this encourages website operator to consider self-hosted software and Offen as a real option. Required changes for this were implemented in [PR 287](https://github.com/offen/offen/pull/287). +Self hosted software is a great fit for privacy focused software like Offen. Yet, it can seem daunting to non-technical users and make them stick to established SaaS solutions longer than needed. This is why we put a lot of effort into finding easy "1-click" options to deploy an Offen instance. In Milestone 3 we have created a 1-click solution for deploying Offen to Heroku: [https://github.com/offen/heroku](https://github.com/offen/heroku). Using free resources only, people interested in running Offen can now deploy a production ready instance to Heroku in less than 1 minute. We hope this encourages website operator to consider self hosted software and Offen as a real option. Required changes for this were implemented in [PR 287](https://github.com/offen/offen/pull/287). diff --git a/homepage/content/articles/0060-milestone-4.md b/homepage/content/articles/0060-milestone-4.md index 6295259..d7cf02c 100644 --- a/homepage/content/articles/0060-milestone-4.md +++ b/homepage/content/articles/0060-milestone-4.md @@ -44,14 +44,14 @@ This has been implemented in PRs [362](https://github.com/offen/offen/pull/362), ### Improved demo -For self-hosted software like Offen, giving potential users an idea of what the software looks like without having to do a proper install. Many softwares do this by sharing the credentials for a demo account on their website, but in the case of Offen we do not want to do this as it would expose the usage data of our real world users - which is what we are trying to protect with Offen. +For self hosted software like Offen, giving potential users an idea of what the software looks like without having to do a proper install. Many softwares do this by sharing the credentials for a demo account on their website, but in the case of Offen we do not want to do this as it would expose the usage data of our real world users - which is what we are trying to protect with Offen. This is why we built a downloadable demo of Offen that you can run on your local machine. This demo exists for a while now, but with Milestone 4 we made major improvements to this feature: - A demo is now populated with randomly generated usage data at start, so that users will get an idea of how an install that is already in use will look like, instead of having to generate usage data themselves beforehand. - We added a dedicated landing page for demo users that explains them how to use the demo from both a user's and an operator's perspective. - + You can try using the demo yourself by running the following snippet: @@ -65,7 +65,7 @@ Relevant PRs are: [367](https://github.com/offen/offen/pull/367), [346](https:// An ongoing part of our work on Offen is implementing features and fixes that come from our own experience with running our own Offen instance. This is why Milestone 4 contains a few UX improvements and fixes regarding the operator facing Auditorium. Among others, we improved the referrer stats, improved the mobile UX for tabular data and fixed issues with the user flow for resetting your password. -Relevant PRs are [361](https://github.com/offen/offen/pull/361), [363](https://github.com/offen/offen/pull/363), [364](https://github.com/offen/offen/pull/361https://github.com/offen/offen/pull/364), +Relevant PRs are [361](https://github.com/offen/offen/pull/361), [363](https://github.com/offen/offen/pull/363), [364](https://github.com/offen/offen/pull/361https://github.com/offen/offen/pull/364), --- @@ -122,7 +122,7 @@ describe('Consent', function () { Now that we have a basic idea of how such a test looks like, let's add interaction and check for their immediate effects on the UI: ```jsx -it('displays a link to the Auditorium after opt in only', function () { +it('displays a link to the Auditorium after opt-in only', function () { cy.visit('/') cy.contains('Open Auditorium').should('not.exist') cy.contains('Yes please').click() @@ -151,10 +151,10 @@ it('allows users to opt out and delete all of their data', function () { cy.contains('Open Auditorium').click() cy.url().should('include', '/auditorium/') - cy.contains('Opt out').should('exist') - cy.contains('Opt out').click() + cy.contains('Opt-out').should('exist') + cy.contains('Opt-out').click() - cy.contains('Opt out').should('not.exist') + cy.contains('Opt-out').should('not.exist') cy.contains('Unique websites').prev('p').should('eq', '0') }) ``` diff --git a/homepage/content/articles/0070-budget.md b/homepage/content/articles/0070-budget.md index 8fe7405..5cee97c 100644 --- a/homepage/content/articles/0070-budget.md +++ b/homepage/content/articles/0070-budget.md @@ -5,11 +5,12 @@ slug: hosting-offen-on-budget sitemap_priority: 0.7 image_url: /theme/images/offen-blog-0070-budget.jpg author: Frederik Ring +must_read: True bottom_cta: blog # Hosting Offen on a budget -Using self-hosted software like Offen when you're on a budget can seem daunting as you usually don't know too much about the performance requirements of the software you are planning to use beforehand. Once you do know, you might have locked in yourself already. +Using self hosted software like Offen when you're on a budget can seem daunting as you usually don't know too much about the performance requirements of the software you are planning to use beforehand. Once you do know, you might have locked in yourself already. In this article we collect a few real world options and scenarios for hosting Offen on a budget and compare how they relate in terms of ease of deployment, performance and pricing. diff --git a/homepage/content/articles/0080-beta.md b/homepage/content/articles/0080-beta.md index 6e4c408..abbd582 100644 --- a/homepage/content/articles/0080-beta.md +++ b/homepage/content/articles/0080-beta.md @@ -23,7 +23,7 @@ We as Offen are convinced that all these 'privacy friendly' approaches are an im Users continue to be unaware what kind of data is collected and how it is being used. They still cannot access or delete it. This leaves them in the dark about their situation and does not help to reduce the latent distrust against web operators. A problem that GDPR also addresses explicitly under the headline 'Rights of the data subject'. This is why we develop a fair and open web analytics tool that finally treats *operators and users as equal parties.* -Usage data is only collected after opt in. If users choose to opt in, they have full access to their data and can also delete it. The collected data is presented to the user with explanations that describe why a particular metric is relevant and what the privacy implications are. +Usage data is only collected after opt-in. If users choose to opt in, they have full access to their data and can also delete it. The collected data is presented to the user with explanations that describe why a particular metric is relevant and what the privacy implications are. At the same time essential metrics give operators the chance to gain valuable insights. They can improve their services without violating the privacy of their users. By the way, Offen is in beta phase now. [Please take a look and give it a try.](/try-demo/) diff --git a/homepage/content/articles/0100-matomo.md b/homepage/content/articles/0100-matomo.md index 5917d8e..fd1527f 100644 --- a/homepage/content/articles/0100-matomo.md +++ b/homepage/content/articles/0100-matomo.md @@ -13,11 +13,11 @@ bottom_cta: fair Matomo was started around 2007 as a successor to phpMyVisites and *open-source alternative to Google Analytics.* The project founded by Matthieu Aubry used to be called Piwik until it was rebranded to its current name in 2018. According to Wikipedia it is installed on about 1.5 million websites, making it one of the best known open source web analytics applications on the market. -Operators interested in open and privacy friendly web analytics particularly appreciate Matomo's ability to be self-hosted. The respective app variant called "Matomo On-Premise" has no license costs, but paid plugins are necessary for extensive use. +Operators interested in open and privacy friendly web analytics particularly appreciate Matomo's ability to be self hosted. The respective app variant called "Matomo On-Premise" has no license costs, but paid plugins are necessary for extensive use. ### Room for improvement -Despite the general popularity, there are some problems with Matomo's decisions regarding privacy. By default, the software only offers an opt out feature for website users. This way, *consent is practically a preset.* In addition, access to usage data is not automated and therefore can be very complex and laborious for users. A common problem which the GDPR mandates explicitly under the heading ["Rights of the data subject"](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation#III_Rights_of_the_data_subject){: target="_blank"}. +Despite the general popularity, there are some problems with Matomo's decisions regarding privacy. By default, the software only offers an opt-out feature for website users. This way, *consent is practically a preset.* In addition, access to usage data is not automated and therefore can be very complex and laborious for users. A common problem which the GDPR mandates explicitly under the heading ["Rights of the data subject"](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation#III_Rights_of_the_data_subject){: target="_blank"}. On the technical side, the following issues are particularly apparent. Installing Matomo can be a bit of a pain as there are many dependencies that must be pre-installed on the system. This also applies to the requirement to use a dedicated MySQL database, which makes installation even more complex. Last but not least, the tracking script that Matomo uses is extensive and therefore delays the loading of the pages considerably. @@ -27,7 +27,7 @@ On the technical side, the following issues are particularly apparent. Installin To address the above mentioned issues we develop a fair and lightweigt web analytics tool that treats operators and users as equal parties. It is called Offen and is [available as a beta version.](https://www.offen.dev/get-started/) -*Offen's default is to NOT collect any data.* Usage data is collected after opt in only. If users choose to opt in, they have full access to their data. They can delete it any time or opt out completly. +*Offen's default is to NOT collect any data.* Usage data is collected after opt-in only. If users choose to opt in, they have full access to their data. They can delete it any time or opt out completly. The collected data is presented to users with explanations that describe why a particular metric is relevant and what the privacy implications are. This helps to strengthen trust in operators. diff --git a/homepage/content/articles/0110-milestone-6.md b/homepage/content/articles/0110-milestone-6.md index f2524c3..52a622f 100644 --- a/homepage/content/articles/0110-milestone-6.md +++ b/homepage/content/articles/0110-milestone-6.md @@ -11,7 +11,7 @@ bottom_cta: blog It feels a little surreal to write this, but: this post marks the end of Milestone 6, which is the last one defined in our initial product plan defining the scope of our support by the [NGI Zero PET initiative](https://nlnet.nl/thema/NGIZeroPET.html){: target="_blank"}. -In these last weeks we focused on packaging and testing, which - who would have thought - uncovered some issues we didn't know about yet. But it also felt very rewarding to see the work of the last ~9 months paying off, now that we and others can deploy and use Offen easily. Having designed Offen as a self-hosted solution from the start, we managed to establish a unique characteristic when comparing Offen with other solutions out there: if you're looking to self host your analytics software, it won't get much easier. If you are unsure about that claim, check out the rest of this post to see what that actually means. +In these last weeks we focused on packaging and testing, which - who would have thought - uncovered some issues we didn't know about yet. But it also felt very rewarding to see the work of the last ~9 months paying off, now that we and others can deploy and use Offen easily. Having designed Offen as a self hosted solution from the start, we managed to establish a unique characteristic when comparing Offen with other solutions out there: if you're looking to self host your analytics software, it won't get much easier. If you are unsure about that claim, check out the rest of this post to see what that actually means. During Milestone 6 we have released the following versions: diff --git a/homepage/content/articles/0120-opt-in-quality.md b/homepage/content/articles/0120-opt-in-quality.md index 1d356d0..65896fa 100644 --- a/homepage/content/articles/0120-opt-in-quality.md +++ b/homepage/content/articles/0120-opt-in-quality.md @@ -1,13 +1,14 @@ -title: Opt in for quality insights +title: Opt-in for quality insights description: Collecting data only with user consent has a less obvious implication: the quality of insights from web analytics increases. date: 2020-10-28 slug: opt-in-quality sitemap_priority: 0.7 image_url: /theme/images/offen-blog-0120-opt-in-quality.jpg author: Hendrik Niefeld +must_read: True bottom_cta: matomo -# Opt in for quality insights +# Opt-in for quality insights ### Fair web analytics @@ -17,13 +18,13 @@ Collecting data only with *user consent has a significant impact on the quality ### Analyzing our own turf -Our own homepage [offen.dev](https://www.offen.dev/), on which of course an Offen instance is installed, can be described as rather small. It currently has an average of 280 unique users after opt in and 660 verified page views per month. +Our own homepage [offen.dev](https://www.offen.dev/), on which of course an Offen instance is installed, can be described as rather small. It currently has an average of 280 unique users after opt-in and 660 verified page views per month. -We estimate our opt in rate, meaning the percentage of website users who agree to the data collection, to be about 40%. This figure is a subjective estimate and derived solely from the personal feedback of a relatively small group of test users. +We estimate our opt-in rate, meaning the percentage of website users who agree to the data collection, to be about 40%. This figure is a subjective estimate and derived solely from the personal feedback of a relatively small group of test users. We cannot and do not want to measure the actual rate for obvious data protection reasons. What we are sure about is that it depends very much on the content offered. In our particular case, where product and presentation are so closely interwoven, it should be rather high compared to other content. -However, we do not think it really matters to know what your opt in rate exactly is. But more about this later. +However, we do not think it really matters to know what your opt-in rate exactly is. But more about this later. ### Collecting data differently @@ -55,15 +56,15 @@ Common web analytics tools try to solve this problem by blocking single traffic ### Real human users -We don't think so. An "opt in only" policy for data collection, which is necessary anyway for privacy reasons, solves the problem along the way. Even if you wanted to, the opt in banner can only be bypassed with a lot of engineering effort. This assures real human users with a very high probability. The best starting point for the optimization of your website. +We don't think so. An "opt-in only" policy for data collection, which is necessary anyway for privacy reasons, solves the problem along the way. Even if you wanted to, the opt-in banner can only be bypassed with a lot of engineering effort. This assures real human users with a very high probability. The best starting point for the optimization of your website. -Talking about these real users brings us back to the question of whether it is important to know your exact opt in rate. For an answer, consider for which users you want to optimize your website and what kind of users you want to attract. +Talking about these real users brings us back to the question of whether it is important to know your exact opt-in rate. For an answer, consider for which users you want to optimize your website and what kind of users you want to attract. *Those who consent are most likely interested in your content.* They support you with their usage data and may therefore be willing to support you in any other way. The exact share of these users is less interesting. ### Deeper insights for optimization -Nevertheless, common web analytics tools that collect data without user consent provide at least better results than the analysis of your server logs. Yet their quality is bound to be lower compared to the results obtained with the smaller amount of data generated by opt in only data collection. This is caused by the fact that some further issues are simply not manageable without some form of consent banner. +Nevertheless, common web analytics tools that collect data without user consent provide at least better results than the analysis of your server logs. Yet their quality is bound to be lower compared to the results obtained with the smaller amount of data generated by opt-in only data collection. This is caused by the fact that some further issues are simply not manageable without some form of consent banner. Many users are recorded even though they have visited your website with very little or no interest. Some bounce off immediately and may just have been there by mistake. Still, all these data points are included in your analytics and will give you a distorted impression. The resulting false assumptions distract you from the important users and make it difficult for you to keep the necessary focus. diff --git a/homepage/content/articles/0140-privacy-cookies.md b/homepage/content/articles/0140-privacy-cookies.md new file mode 100644 index 0000000..48d4d0c --- /dev/null +++ b/homepage/content/articles/0140-privacy-cookies.md @@ -0,0 +1,127 @@ +title: Privacy focus? Consider the cookie +description: Using cookies does not necessarily equal tracking your users. Learn how you can use cookies to respect the privacy of your users. +date: 2020-12-28 +slug: privacy-cookies +sitemap_priority: 0.7 +image_url: /theme/images/offen-blog-0140-privacy-cookies.jpg +author: Frederik Ring +must_read: True +bottom_cta: quality + +## Privacy focus? Consider the cookie + +Whoever [drafted the idea for HTTP cookies](https://tools.ietf.org/html/rfc2109){: target="_blank"} back in 1997 likely did not anticipate having created a technology that is as disputed, discussed and also disliked as it is today. A non-technical user of the internet might be under the impression that cookies are an utterly useless privacy disaster that bring you nothing but consent banners filled with dark patterns, and enable advertisers to track you on literally every website ever. + +And while there are definitely problems with the modern day usage of cookies, with very good reasons to regulate their usage, they can also be used to enhance privacy on the web. Using cookies does not necessarily equal tracking your users or invading their privacy. In this article we would like to show you how you can use cookies to respect and enhance the privacy of your users. + +> *Using cookies does not necessarily equal tracking your users or invading their privacy.* + +--- + +### Collecting data should require consent, no matter your implementation details + +Inside the European union the so called "[Cookie Directive](https://en.wikipedia.org/wiki/Privacy_and_Electronic_Communications_Directive_2002){: target="_blank"}" mandates acquiring consent from users for setting non-essential cookies. Similar laws exist for example in California. The internet being a global phenomenon, you are very likely to be subject to these regulations in one way or the other the moment you serve any non-trivial website. Many developers like to complain vocally about so called "cookie banners", and the number of sleazy patterns that try to trick users into consenting makes these complaints relatable. A solution that does not require user consent must surely be the better option for privacy, right? + +It's not that easy though. If you think user privacy from the ground up, how do the technical details of your implementation matter? We'd argue they do not matter much. If you want to collect non-essential data from your visitors (analytics data in the case of Offen) in a privacy friendly way, you should be asking for user consent. No matter how your technical solution for doing so looks like, and no matter what regulations currently say. If you're not doing this and instead come up with something that allows you to avoid "the cookie banner" for collecting non-essential data, you are not building a privacy friendly solution, you are building a regulations friendly solution. + +Think about it in this way maybe: if you feel like you really do not want ask users for consent, then maybe this is a good hint to reevaluate if you really need to collect that data you would need user consent for. Privacy values choices, and simply not making use of non-essential features should be an option for users always. Not convinced? Think about why ad blockers are so popular. + +In case your conclusion is that you do need to collect the data, don't be afraid about that consent banner too much. There is absolutely nothing that requires you to use the overly complex solutions you can find on the internet way too often. Consent banners can be unobtrusive, concise and clear starting the moment when you accept a "No" just as much as you accept a "Yes". + +> *Consent banners can be unobtrusive, concise and clear starting the moment when you accept a "No" just as much as you accept a "Yes".* + +--- + +### Essential, non-essential, and what's the difference? + +Regulations around data protection and collection often distinguish essential and non-essential features, and this makes a lot of sense. If a user can log in to your service and you have to store a session identifier in a cookie to enable this, it is perfectly fine to do so without consent. Having to provide credentials over and over again for every request made against your server would render your service unusable, hence it is an essential feature. + +Non-essential features are usually revolving around performance and analytics. Collecting analytics data for a website definitely is not required for the user to use your service. This means it is non-essential usage and you should be asking for consent before doing so. Regulations around this topic only cover cookies, but taking privacy seriously, you would apply this principle to all techniques. On a side note, [quantity does not necessarily mean quality in web analytics](https://www.offen.dev/blog/opt-in-quality/). + +Most importantly, both essential and non-essential segments require making sure their technical implementation is secure and respects user privacy as much as possible. + +--- + +### Technical considerations for using cookies in a privacy friendly manner + +Offen is a fair web analytics software. This is a promise we can only deliver with an opt-in only solution. Not having to work around a "cookie banner" (for us, that's a feature) we are free to solve any task at hand in the most privacy friendly way we can come up with. And in many cases, this means using cookies. The following collects a few guidelines we've been following when building Offen. + +#### Choosing privacy friendly identifiers and values + +Cookies are essentially a key-value store. It might seem tempting to store detailed and highly specific information in the values here, but let's have a look at what that would mean from a privacy perspective. + +For example let's say you wanted to write a feature test, checking for whether you can set cookies in the first place, you might come up with a mechanism that writes a random value to a certain key and tries to read it again. If the value can be read and is not altered the check succeeds. However, this means the feature test does also make the user identifiable by that random token, which is a privacy implication that is not tolerable for such a basic task. Instead, you can use a static value and also a static key for all users that ever run the feature test, thus making them indistinguishable. The guideline therefore is to always use static values that are the same for each and every user, unless you really need to identify users. + +If you find yourself in the situation where you do need to create an identifier that is unique to a user, cookies will give you the privacy advantage of being able to create a truly random and anonymous value (e.g. a UUID) that is not tied to any user or device specific information (as compared with for example tracking sessions by hashing a combination of IP address and User Agent string on the server, [which leaks a lot of private information, even when stored in its hashed form only](https://edps.europa.eu/data-protection/our-work/publications/papers/introduction-hash-function-personal-data_en){: target="_blank"}). Ensure you use a well-tested library for creating such identifiers. Also, consider the option of periodically rotating such tokens so that others that inadvertently get hold of such a token can only make use of it for a limited period of time. + +> *Cookies will give you the privacy advantage of being able to create a truly random and anonymous value that is not tied to any user or device specific information.* + +#### Allow users to delete their cookies + +One of the best privacy features of cookies is: users can delete them at any time, disassociating themselves with the data tied to the previous identifiers instantly. This will never work if you use server side solutions relying in UA strings and/or IP addresses. Many users might know how to do this, but if you take privacy seriously and you are using cookies for your service, why not implement such a feature within? + +#### Do not use Third Party cookies + +A cookie is always bound to the domain it has been issued from. In a scenario where a page loads resources from different domains, this means that some of these resources may set or use cookies bound to a different domain than the host document is served from. + +These cookies are called third-party cookies and are pretty bad for privacy, considering they can be used to follow users around the web when such third party resources are being loaded on a multitude of websites. + +Luckily, usage of third party cookies is already being heavily restricted by browser vendors, and there are concrete plans to disallow their usage entirely until 2022. + +However, when designing an application you might find yourself in situations where using third party cookies might become a requirement. In case such a requirement pops up, it's probably best to take a step back and reconsider the overall architecture of your application's HTTP schema. Using a third party cookie shows your application would be leaking information (both essential and non-essential) across domain boundaries. Consider consolidating all logic that requires to share such data under a single domain so that data can be neatly protected by other mechanisms such as `SameSite`. + +#### Same site cookies + +To preserve privacy for the values stored in the cookies you set yourself, you will want to restrict their usage to to a first-party or same-site context. In order to allow for fine grained control of this behavior, [the `SameSite` attribute](https://web.dev/samesite-cookies-explained/){: target="_blank"} got introduced in [RFC6265bis](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1){: target="_blank"}. + +This allows you to now set a value of either `Strict`, `Lax` or `None` for the `SameSite` attribute, limiting the scenarios in which your browser will send cookie information with requests to your domain. + +Considering this article is about building secure and privacy focused applications, using `None` should not be an option here. The major difference between `Lax` and `Strict` is that `Lax` allows for cookies to be sent along with so called "top level" requests, i.e. if your site is using cookies to store a session identifier for login and a 3rd party site links to your site, using `Lax` will allow users to click that link and be logged in instantly, whereas using `Strict` would not send those cookies on the first request, but only on those initiated by the document loaded from your domain itself. + +Depending on your use case, both options are valid choices and make sure you respect your users' privacy. + +> *One of the best privacy features of cookies is: users can delete them at any time, disassociating themselves with the data tied to the previous identifiers instantly.* + +#### Secure by default + +Cookies are designed to be sent in the headers of HTTP requests. This means that when not using an encrypted connection over TLS, the values sent in plaintext and are subject to possible eavesdropping by third parties in between your user and your server. + +Even while using HTTPS is becoming the default nowadays, HTTP still does exist and it's totally possible in certain setups to accidentally make HTTP requests, even when HTTPS would be available. + +To protect cookie values to be sent over insecure, plain-text connections, set the `Secure` attribute on your cookies. This way, the browser will make sure to send cookies only when a request is using the `https` protocol. + +#### HTTP cookies and JavaScript cookies + +Cookies can be set and read in two different manners, either by using client side JavaScript, using the `document.cookie` interface or by using the `Cookie` and `Set-Cookie` HTTP Headers. + +By default, cookies set by one method can be read by the other and vice-versa. This does create privacy implications though: as modern websites can load a large amount of third party code in the client, this exposes information stored in cookies to everyone who can run code on your website, e.g. third party widgets or similar. + +To avoid a situation like this, the `HttpOnly` attribute can be used. When set on a cookie, it means reading from and writing to it is not possible using client side JavaScript, it can only be accessed by the server, which gives you much tighter control over the data contained. + +`HttpOnly` should be the default setting when issuing cookies. Only disable when there is no other way to achieve what you need to achieve. When you have to do so, consider the information stored in that cookie public, so do never store any user identifiers, session data or similar information in a cookie that is not `HttpOnly`. + +#### Scope access using domains and paths + +Access rules for a cookie can be defined by using the `Domain` and `Path` parameters. The `Domain` defines the domain a cookie is sent to and `Path` limits its submission to certain sub-paths of that domain. So for example a cookie with a domain of `www.offen.dev` and a path of `/blog` would be sent along with requests of a URL beginning with `https://www.offen.dev/blog` only. + +There are some interesting details about the `Domain` parameter: it is optional and when not specified at all, the cookie will be bound to the very domain that is setting the cookie. No sibling or subdomains will be allowed to access its value. When you specify a domain, this domain and all of its subdomains will be allowed to access that cookie. + +Sometimes, you will also see domain values starting with a dot like `.offen.dev`, which used to indicate that the cookie should be sent to all subdomains, yet modern browsers will treat the domain [with or without the leading dot in the same way](https://tools.ietf.org/html/rfc6265#section-4.1.2.3){: target="_blank"}. It is not needed anymore. + +These two mechanisms should be leveraged from the start when you are using cookies. Start by not specifying a domain and the most restrictive `Path` value you can use and only relax these rules if it is strictly necessary for your application to function. Be extra stringent about this when handling cookies that contain identifiers. + +#### Expire cookies you do not need + +Cookies come in two flavors: Session cookies and persistent cookies. Session cookies will be purged by your browser once your [browsing session](https://html.spec.whatwg.org/dev/history.html#browsing-session){: target="_blank"} ends, persistent cookies define a point of time where they expire themselves. Technically, it's not possible to issue a cookie that is never expiring, although you can create one that expires in a 100 years, resulting in the same effect for the end user. + +Once again using the principle of [Datensparsamkeit](https://martinfowler.com/bliki/Datensparsamkeit.html){: target="_blank"} as a guideline, it's a good habit to start with all cookies being session cookies. Only make those persistent where the benefits justify the consequences of storing possibly sensitive data like user identifiers on a user's device for a prolonged period of time. Consider the trade-offs for your users when defining the expiry and err on the side of security and privacy. If you really need a very long lived cookie, look into if you could periodically refresh its value so that it does not create a potentially unwanted tracking identifier for others. + +> *Start with all cookies being session cookies. Only make those persistent where the benefits justify the consequences of storing possibly sensitive data.* + +--- + +### Wrapping up + +If you find yourself building a product where privacy is important - just like we do when building Offen - feel encouraged to consider cookies as an option for your tasks. Very often, it's a robust and simple choice that is beneficial for your user's privacy when done right, and the implicit requirement for acquiring user consent is a major privacy feature. + +Do you have comments or feedback about this article or about Offen in general? Tweet at us [@hioffen](https://twitter.com/hioffen){: target="_blank"} or email us at [hioffen@posteo.de](mailto:hioffen@posteo.de). diff --git a/homepage/content/pages/about.md b/homepage/content/pages/about.md index 35be0c4..9f8e7fb 100644 --- a/homepage/content/pages/about.md +++ b/homepage/content/pages/about.md @@ -1,25 +1,74 @@ title: About | Offen -description: Who we are, who supports us and how you can can get in touch. +description: Who we are, what we do, who supports us and how you can can get in touch. slug: about -bottom_cta: matomo +bottom_cta: fair ## About +### What is this thing called "my data" and why does seemingly everyone want to get hold of it? + +It has a ring, gives a slight spine-chilling sensation and generates a whole lot of clicks: consumer magazines like German "Computer Bild" caution about ["Google espionage"](https://www.computerbild.de/artikel/cb-Ratgeber-Kurse-Wissen-Was-weiss-Google-ueber-Sie-2799009.html){: target="_blank"} just like the internet has countless tutorials on turning off numerous ["data leeches"](https://praxistipps.chip.de/datenkrake-windows-10-so-schalten-sie-auffaellige-funktionen-ab_99652){: target="_blank"}. Interestingly, diving into these realms will have you accidentally catching the next toolbar, malware infection or [even worse](https://blog.malwarebytes.com/cybercrime/2012/10/pick-a-download-any-download/){: target="_blank"}. + +Yet, many internet users still do not know what really is happening to their data. Public relation activities trying to calm the public - as recently undertaken by Facebook [for example](https://www.zeit.de/digital/datenschutz/2019-01/social-media-facebook-mark-zuckerberg-ads-privacy-business-model-transparency){: target="_blank"} - end up being rather disturbing instead of creating transparency or adding any value to the public debate. Denelle Dixon, COO of Mozilla, just publicly [warned the European Commission](https://blog.mozilla.org/blog/2019/01/31/mozilla-raises-concerns-over-facebooks-lack-of-transparency/){: target="_blank"} about the dangerous effects an opaque apparatus such as Facebook can have on society. Updated Terms and Conditions only parenthetically mention that newly created Google accounts will now hand over real names to third parties for [advertising purposes](https://www.propublica.org/article/google-has-quietly-dropped-ban-on-personally-identifiable-web-tracking){: target="_blank"}. + +
@@ -23,12 +23,9 @@