Yeah, I hope it doesn't mean that they will remove Command Palette. Unfortunately, it's still an opt-in "feature preview", so who knows what this means. For me it's a key navigation tool in GitHub, but I can understand that it's more of a power user feature.
I guess they can't ban a product for all eternity. In the decision [1] they are a bit more specific:
"This shall be done in particular by ceasing to use that version of the tool
Google Analytics as used on August 14, 2020, if not sufficient
protective measures have been taken."
Hashing the IP is not enough by IMY's decisions, none of the companies are allowed to use GA going forward.
CDON used GA's IP anonymization through truncation, it was not deemed enough. [1] The IP itself becomes is not personal data after truncation but it's unclear if the truncation happens before it leaves the country. And combined with the other personal data (e.g. cookies), it is considered personal data. [2]
Coop proxied all calls to GA and use the same generic IP address for all users. [3] They don't get a fine but have to stop using GA.
1.3.14.2 Coop's implementation of the server side container The purpose of the server side container that Coop has implemented is to improve the security related to the data sent. More specifically, the aim is to on a good and safely be able to protect the personal privacy of those registered. Server side the container acts as a proxy between the registrant's browser and the Tool where Coop has chosen to implement the server side container in a way that makes them the registered browser's public IP address is never transmitted to the Tool. Implementation can be described as follows. A registrant visits the website www.coop.se in your browser. The Google Analytics script is downloaded from the server side container instead of being downloaded directly from Google Analytics servers. This results in the registrant's IP address as well as information about user behavior, device information, customer status, online identifiers and transaction data (according to points 1–5 above under section 1.3.10) are transferred to the server side container, instead directly to Google Analytics. Once the Google Analytics script has been downloaded from the server side container, a new call is made from the server side container to Google Analytics servers. Since the call is made from the server side container, no transfer of the registrant's public IP address to Google Analytics. Coop has configured the server side container in such a way that all data as above, except it was recorded public IP address, passes through the server side container to Google Analytics. Google Analytics receives data sent from the server side container and that data (information) that has been sent is popularized in reports by the measurement set up on the website www.coop.se. The treatments that take place through the aforementioned – i.e. to receive, convert and forward the call - takes place in the working memory of the server side container. It means all processing takes place in real time and that no data is permanently stored. In other words, stored public IP addresses were not registered in the server side container and they are not exposed rather against Google Analytics servers. All communication from the browser, via server side container, to The tool is also encrypted.
This process cannot be reversed as the information is not stored and the conversion
not based on a one-to-one relationship that enables the use of a "key"
to recreate the public IP addresses.
Coop has activated Google's function for IP anonymization. It means that the IP
address sent to the Tool is truncated. This is done by Google removing one
part of the IP address before the IP address is stored on disk. For an IPv4 address, last is replaced
the octet in the address with a zero. For an IPv6 address, the last 80 bits are replaced with
zeros. The action cannot be reversed but as this action is done by Google i
Coop has also chosen to implement the tool as a server side container.
In Coop's case, the IP anonymization feature is enabled and applied to the generic
IP address sent via the server side container. In context, however, the function is
redundant considering that the server side container prevents the public of the registered
IP addresses from being sent to the Tool. Coop's assessment is that server side
the container as a measure is a sufficient protective measure, but that it does not harm that even
have the IP anonymization function activated in the Tool.
Do you happen to know which section of the ruling it is where they discuss why Coop needs to stop doing this? It's a PDF and the translation tool I'm using on my phone is a pain.
In section 2.2.2 they expand on their reasoning. The claim is basically that unique identifiers stored in cookies ("_gads", "_ga" and "_gid") (they also mention more unique identifiers in the same context in section 2.4.2.3.2) together with information about the page that was visited, the visitors browser fingerprint and the generic IP address can be used to identify individual users.
If I need to do more than one query to the database in series, my intuition is that it would be faster to make those calls in the same region as the database, rather than at the edge. It seems to be true using Vercel's playground[1] (towards Supabase).
Any guidance for Supabase based apps? Is it possible to run my functions close to the database?
for when it really matters, then you should just use a Postgres Function. That will be an order of magnitude faster than anything you do to match the region.
Supabase has auto-generated APIs (using PostgREST), so you can execute a Postgres Functions like this:
I was bummed out by that too initially.But it's kind of inevitable with root not writable on the latest macOS releases and needing the store to be under /nix.
I’ve been working on this for the last two years, and now it’s out. Dossier a toolkit for building headless CMSs, released under MIT license. It’s written in TypeScript and supports running the server in a browser, Node, Bun or Deno. The data is stored in SQLite or Postgres. It includes schema/type generation for TypeScript and GraphQL.
There’s a playground[1] to try it out in the browser and a getting started guide[2] if you want to run it on your machine.
There’s still a lot of work left to do, but I’m happy with the big strokes of the project. Please, let me know what you think!
We will eventually have a builtin Postgres client, but Postgres.js is also a great choice. I started to work on a `bun:sql` module, but ran out of time for now.
Even if you don't send personal data to Google analytics they store personal data automatically. At least Google Analytics for Firebase store the following identifiers:
Mobile ad IDs
IDFVs/Android IDs
Instance IDs
Analytics App Instance
https://firebase.google.com/support/privacy/
