The first two generations of the Pi only had a single HDMI output - later generations have 2 and hence required smaller HDMI ports to be able to keep the Pi footprint.
The Fuchsia team is working on a Linux compatibility-layer, named Starnix[1], which is much like WINE on Linux. This would allow Linux applications to run on Fuchsia as-if they were running on a Linux kernel. A massive amount of work, but less work than adapting every single existing application to run on Fuchsia.
Back in 2022, there were signs[2] that Google was working on testing the Android Runtime (ART) on top of Starnix, by trying to get the clock app running on top of it. Most of this work has been done in private though, the tracking-issues mentioned in the article were quickly set to private after they were found.
Interesting. I guess this isn't so impossible then. Still, it seems they would need a very strong will in the company, up to Sundar Pichai, to really commit to switch over Android to Fuchsia. Which likely requires a large and years-long developer effort until the switch can be made in a reasonably seamless manner. But the management will likely ask whether the advantages (better security?) are worth such an investment.
> testing the Android Runtime (ART) on top of Starnix
It reminds me how early Wayland compositors barely could ran on bare hardware and worked as X11 clients for testing purposes, hehe (many, like Weston or Cage, still can).
A few years ago I reverse engineered my Oral-B (Braun) toothbrush in order to change the color of the brush (handle) to one of my liking, without being constrained by the pre-set colors available in smartphone app. (Which I think now also requires you to log in)
In an enterprise setting you can just roll out your own root certificate to every machine's trust store, and have your middle box MitM all traffic with the help of that.
Auto-updates had nothing to do with it, in this case it was a pre-existing bug in Firefox's HTTP3 implementation getting triggered by new changes to load balancers in front of Firefox's data collection servers.
“Cookie dialogs” are supposed to be about trackers of all sorts (not just cookies); there to ask for permission to store non-essential trackers in general.
We need to stop calling them cookie pop ups as that’s a misnomer. You can use cookies. You can store site state, login sessions, shopping carts and much more without asking at all.
I’m not a lawyer, so take this with a grain of salt. But I have implemented gdpr for several companies.
First, you do not need consent for anything deemed essential to your site. Furthermore, you kind of get to say what is essential and what isn’t, as long as you can reasonably defend it.
For example a shopping cart is certainly essential. Previous purchases, page views, etc all essential.
“Page views per session”, most likely not essential (though you can make the argument they are), but if you’re not installing an identifier on the user to track them (for example, they’re signed in and you’re aggregating as such), then you don’t need to ask for consent.
If this sounds like there are loopholes that’s because there are loopholes. Concretely, tracking consent dialog are one of the looser parts of gdpr.
So what I usually tell clients is: You do not need a consent dialog, unless you use a first or third party analytics library.
If you add a third party analytics library (google analytics, Facebook pixel, piwik, plausible, …), [edit: or third party ads, they come with their own tracking], do not load it until you’ve asked for consent.
Ask for consent once per account or per logged out device.
> “Page views per session”, most likely not essential (though you can make the argument they are), but if you’re not installing an identifier on the user to track them (for example, they’re signed in and you’re aggregating as such), then you don’t need to ask for consent.
GDPR might allow for this but other data protection laws might not. In the UK if you want to use an authentication cookie for any other purpose you're required to request permission[0]. Weirdly the guidance also states that consent is also required for persistent login cookies.
Yes, you're quite right; I'm talking about GDPR, but other data protection laws may apply and may be stricter.
Also, these are general guidelines and may not be compliant to 100%. But the clients I deal with do not usually need to worry about absolute compliance, otherwise they'd be hiring teams of actual lawyers, not me.
6. No, you are not really looking at this issue the right way.
While it has been nicknamed the "Cookie Law", the ePrivacy Directive is about trackers that contains PII (Personally Identifiable Information) and the reason some cookie exist.
On a high-level, the spirit of the law is:
- if the cookie is essential to the site, consent is not needed
- if the cookie doesn't contain PII / isn't used for tracking, it is not impacted by the law, and thus consent is not needed
Now several examples you detailed could be done server-side, without any tracking cookie, or with a cookie if the user is logged (which implies accepting the website conditions and could be deemed essential). In those cases, no consent is needed.
If on the other hand you use a tracking cookie, like a Google Analytics tracking cookie, yes consent is needed.
The answer is no, unless you use a 3rd party like Google Analytics, then you need to look closely at legislation and their settings about whether you need to ask your end user for consent.
But generally speaking, you do not need a tracking consent banner unless you use tracking, directly or via 3rd parties.
As long as you don't connect the statistics you collect to individual user data, you should be fine. A server-side hit counter that just increments a row per page visit in the database doesn't need consent, as long as that row isn't directly connected to any user accounts.
If return counts are nothing more than "this user has visited the site before" and there is some benefit to the user (say, remembering their address or username) then I don't see why you'd need consent. This is in the legitimate interest of you and your user. This "legitimate interest" exception doesn't go as far as many of the nasty tracking companies pretend it does, though.
A history of purchases for an account is an obvious feature, but you need consent before you can use that data to generate a marketing strategy for example. So a cart history is perfectly fine, but training your recommendation algorithm in that needs consent.
You can use whatever you like to achieve the technical requirements for your site to operate from the user's perspective. Theoretically you could even use advanced device fingerprinting techniques without consent as long as the purpose isn't to gather data, but to serve an end goal.
As soon as you start aggregating data for your own benefit, you need explicit, optional consent from the user to use their data to your benefit.
Anonimised data can be used without consent, but good anonimisation is very very difficult to achieve. Data is considered PII if the data can be linked back to the individual user if you have a theoretical second database. Pseudonymisation, which is what most frameworks actually seem to do instead of anonimisation, is not enough to not need consent, because the data can easily be linked back to actual user data using a backup of your site database afterwards.
Tl;dr: as long as you use cookies and other features only to directly benefit the user, you need no consent. If the data you collect cannot possibly be connected to a user, you don't need consent. Based on my reading of the GDPR (not a lawyer but it was covered in an IT law class), that means 1: yes, 2: yes, 3: no, 4: possibly, 5: probably, 6: you've got the right idea.
You can find more details here: https://gdpr.eu/cookies/
You can also try reading the GDPR text itself, it's quite readable as far as legal documents go in my opinion.
It's not about remembering a user's cookie options. The point the parent is making is that "Reject All" should be upfront and centre along with "Accept All" so you don't need to then navigate extra layers to refuse cookies. i.e. it's just one click instead of many.
However that said the cookie preferences "cookie" can be considered a strictly necessary cookie so that it can be used to remember your cookie choices. This is the UK's Information Commissioner's guidance on such cookies:
Punish bad pop-ups, so people are wary of them ('wait is this bad') and discover (and find attractive) the possibility of not having one (can't be fined for a bad thing that doesn't exist) & network effects ('wait how do they have no pop-up')?
It's not about cookies. The legislation and the consent popups are not about cookies. They're not even about whether they're essential.
The banners are there for you to opt-in to your activity on the website and beyond to be tracked by a 3rd party, possibly across multiple other websites.
We do not need to discuss whether a cookie is essential, because it's a red herring. It's not about cookies, it's about behavioural tracking, it's about your browser activity being sent to 3rd parties, being collated and used to e.g. serve you advertisements to sell you shit.
That's what I'm saying. I recognise that's not what the law was intended to do.
The problem is that individuals and small businesses would rather interpret the law in a way that isn't going to get them in trouble, even if it is over-reaching. There has been a level of paranoia stirred up, caused by other companies interpreting the law badly.
It's like staying away from all bodies of water because someone sometime drowned while swimming in the sea. It's a vast overreaction, but it works.
In short, we have lots of armchair lawyers giving idiot-in-a-hurry interpretations, and everyone is doing it wrong because everyone is scared of doing it wrong.
It doesn't matter what the banners were intended for.
It's not that simple though. Even though I agree with you that it is not JUST about cookies, the legislation and guidelines do go into some cookie specific details such as when you can use session cookies vs. long lived cookies as an example.
It's not accepting cookies vs not accepting cookies; it's accepting non-essential (tracking + others) cookies vs rejecting those.
While this is an interesting question/argument, I'd argue that adding a cookie to represent that you have rejected all cookies might be considered an acceptable essential cookie, since it's expected you need to reject them all only once. See here for example:
You don't need to store an identifying cookie to remember someone clicked "no" on a popup. Storing a cookie or localstore that says "cookiePrompt = rejected" should be sufficient.
The rules in question apply to any storage of information to, or reading of information from, an Internet-connected device. It doesn't have to be "identifying" information.
Edit: I'm amazed this comment is being downvoted. Go read the CJEU's ruling in the Planet49 case if you disagree with me!
The Planet49 case has not much at all to do with that. They were using tracking cookies that they also shared with third-parties, i.e. "non-essential cookies, i.e. not was OP suggested, and they were using a pre-checked checkbox for consent. The CJEU (and German BGH) decided that having such an "opt-out" does not constitute active consent.
PS: You might be misinterpreting that what the court said about "personal data" (aka Question 2). The crucial bit here is this
>That interpretation is borne out by recital 24 of Directive 2002/58, according to which any information stored in the terminal equipment of users of electronic communications networks are part of the private sphere of the users requiring protection under the European Convention for the Protection of Human Rights and Fundamental Freedoms. That protection applies to any information stored in such terminal equipment, regardless of whether or not it is personal data, and is intended, in particular, as is clear from that recital, to protect users from the risk that hidden identifiers and other similar devices enter those users’ terminal equipment without their knowledge.
This just means that cookies containing personal data and cookies containing no personal data have to be handled the same. This still means essential cookies are still fine. It just means there is no difference between putting some static text, random string (which could be an identifier), or the users home address (personal data) in a cookie. Planet49 tried to claim that their tracking ids were not personal data and therefore they do not need any consent, and they failed, that's all.
I think we're talking at cross purposes. I am specifically picking up on the mention of "identifying" cookies in the OP. As you've flagged, the Planet49 case said that doesn't matter (your post: "cookies containing personal data and cookies containing no personal data have to be handled the same"). I'm not commenting on the essential cookie aspect.
You're right, I read your response quite differently than what you seem to have meant. I read it as "cookies need consent, no exceptions", which was my misreading and my bad.
At least under UK/EU law, you could likely justify such a cookie under exemptions allowing nonconsensual cookies - that's explicitly stated in the French regulator's guidance, for example.
