Gotta be honest, this isn't very inspiring : "Wait, division by zero is zero, really?
Yes. But focusing on this is a bit like focusing on the color of the seats in a spacecraft."
Curious if anyone can weigh in on why Flix requires a developer to explicitly mark a function as pure. I'd imagine in almost all cases this can be derived through static analysis.
Well, it's a fact, not a narrative. I think the actual debate is whether or not boosting economies of countries in the EU that for one reason or another were or are behind on the curve is a net win. I think it is. Just as it is perfectly justified for other countries to feel a bit hard done by if that same country after an estimates 280 billion euro injection is still rejecting the shared currency of that body.
Being able to buy groceries with euros is not a strong, or even related, argument to the point you're making. Even ignoring the real economic cost of having two currencies, there is no serious economist that would argue Poland joining the EUR zone is negative for Poland (as opposed to for stronger EU economies). Every single historic metric points in the other direction. Poland's economy is maturing and strengthening and median household income is slowly reaching parity with neighbouring countries so this particular argument may only hold for maybe another decade but until then it's a bit misguided. Also, not for nothing but the Polish economy is mostly doing as well as it does because of the metric ton of EU subsidies injected into it the past decades. Poland is one of the largest net receivers of EU money since 2004 so arguing it or its single currency was somehow a net negative to Poland is, and by extension an odd argument to make for someone benefiting from the above as a Polish citizen.
So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it's a toy project or something that's basically in the state of "We wish it was just code but we don't dare touch it".
I know people are going on about privacy and that's fair but easily sorted with the appropriate data privacy policies and actually adhering to your commitments in them.
If you are approaching this from a potential business perspective that will not be the major issue. As you can tell from the comments most people do want their screen recordings on a remote service, now matter the policies involved.
That leaves you with some options :
1) Encrypt the outgoing WebRTC stream before it leaves the client device/browser (e.g. through WebRTC Insertable Streams or similar), encoded with a client local key that only your customer knows/manages. This ensures any screen recordings stored on your end cannot be accessed in any way. They can then download the recordings as needed and decrypt on demand. Note that this still has the implication of you storing and transmitting massive amounts of data which is likely to become cost prohibitive as a service.
2) As above but do the decrypting for your customer on your end so they get to download playable media. This obviously introduces the security risk of your platform becoming temporarily able to 'see' the content.
3) Save your recording directly through MediaRecorder WebM or similar (has various browser compatibility challenges as standards materialize) and uses less obvious encodings (we're still living with the bullshit of H.264 requiring licensing).
Honest question; what does OSI actually do? I am involved with a number of OS projects and not once has OSI come up in any context, be it compliance, governance, education and so on.
If the random user ID is truly anonymous (so, cannot be linked back to an identifiable person even with other data you have), it is not personal data under GDPR and no obligation to inform or consent is needed. If the data processor stores any information that makes PII attribution possible then, and only then, does it fall under GDPR, CCPA, etc. That random ID being persisted on the device allowing for subsequent attribution is still not PII sensitive unless/until the aforementioned identifiability barrier is breached. This is exactly why prominent analytics platforms (Plausible, Matoma, Mixpanel if configured correctly, etc) all offer data hygiene barriers.
I suspect what's happening here is that the word "user" is making things ambiguous here. It was meant in the context of attributable session, not as the data subject as per GDPR language for example.
Well, sure, if you're exceptionally picky about non-normative use cases you can probably find a use for it that is not harmful to the average person. But you're doing a lot of heavy lifting already to justify a positive use case (contacting a person you apparently have no other way of reaching, which isn't in the top 3 of primary use cases for X). Anyway, I was speaking in the aggregate. X (so, post Elon) has been bad for society as a whole and if that's not an objective statement then it is at least close enough to make no difference. I suspect any arguments to use it anyway probably boil down "but...I like it". And since we live in a free world that's a good enough argument to have. It is not, however, harmless.
That's reversing the argument. I'm not saying quitting X is bad for X, I'm saying quitting X is good for you. Nobody's completely immune to whatever that sociological experiment is turning into and staying on X is likely to influence your ethics, morals and standards in an objectively negative way.
Maybe we're disconnecting. Cookies are just a standardised way to communicate a small key/value set between client/browser and server through HTTP headers. It's not inherently (in)secure, sensitive, etc. There are zero things you can do with cookies that you cannot do without and there are no inherent differences in security, they're just very convenient if you're in HTTP world.
And yes what you said is exactly right; you're allowed to fingerprint a unique user and track data with that fingerprint as the sole unique identifier without any PII legislation (GDPR, CCPA, etc.) compliance issues. You just cannot store any information that allows linking PII data to that fingerprint in either direction. In other words, attribution to a random UUID that just happens to represent an anonymous user is not an issue.
Circling back to the original comment; there is no (good) argument against cookies if you're basically doing exactly what cookies are doing. Umami using it as a USP is, at best, a little odd.