> We have a long list of subprocessors, but any one individual going through our system is only going to interact with two or three at most.
So, in aggregate, all 17 data leeches are getting info. They are not getting info on all you users, but different subsets hit different subsets of the "subprocessors" you use.
And there's literally no way of knowing whether or not my data hits "two" or "three" or all 17 "at the most".
> but especially your _face_ is going to be _everywhere_ on the internet. Who are we kidding here? Why would _that_ be the problem?
If you don't see this as a problem, you are a part of the problem
I agree that DPA:s, as they are written today, aren't good. I was just pointing out that the reality probably isn't as bad as the article made it sound.
> If you don't see this as a problem, you are a part of the problem
I think you're misunderstanding me. I'm just saying that there are way bigger fish to fry in terms of privacy on the internet than passport data. In the end, your face is on every store's CCTV camera, your every friends phone, and every school yearbook since you were a kid. Unless you ask all of them to also delete it once they are done with it.
But it makes a big difference if some CCTV camera captures my face and comes up with "unknown person" or if it finds my associated passport and other information.
By the way, ever since facebook was a thing I always asked my friends not to tag me in any photos and took similar measures at every opportunity to keep my data somewhat private.
> I agree that DPA:s, as they are written today, aren't good.
That is, multiple regulations already explicitly restrict the amount of data you can collect and pass on to third parties.
And yet you're here saying "it's not that bad, we don't send eggregious amounts of data to all 17 data brokers at once, inly to 2 or 3 at a time, no big deal"
> In the end, your face is on every store's CCTV camera, your every friends phone
If you don't see how this is a problem already, and is now exacerbated by huge databases cross-referencing your entire life, you are a part of the problem
> OneTrust is literally a consent management platform focused on regulatory compliance, and 24 Hour Fitness is using it to violate consent regulations.
I mean, OneTrust's entire raison d'etre is to violate consent regulations with flimsy deniability.
> I've looked at lit quite a bit but never fully understood the "why".
Because people don't want to write hundreds of lines of useless boilerplate by hand.
Web Components API is verbose enough that you want to handle it with at least some abstraction. And at one point it was explicitly marketed as aimed at library/framework developers.
> Do you have any concrete examples there? What "mechanics" are you referring to
Try the 2022 Web Components Group Report. Including things like "most these issues come from Shadow DOM".
> Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
Trillion dollar corporations also build sites in Angular, or React, or Blazor, or...
So you're deflecting from the original point raised.
Anyway, yes. Web Component "community" was fully and willfully ignoring most issues that people (especially framework authors) were talking about for years.
At one point they managed to produce a single report (very suspiciously close to what people like Rich Harris had been talking about since at least three years prior for which he got nothing but vile and bile from main people in the "community"), and then it went nowhere.
> I still don't know what "mechanics and assumptions" are baked according to the OP.
Again: you do, people who wrote the report do, but you all keep pretending that all is sunshine and unicorns in the web component land.
While the report very explicitly calls out a very major behaviour baked in, for example. And calls out a bunch of other issues with behaviours and mechanics. While web components need 20+ specs to barely fix just some of the assumptions and baked in mechanics (that literally nothing else needs, and most of which exist only due to web components themselves).
Anyway, I know you will keep pretending and deflecting, so I stop my participation in this thread.
> Not being tied to the JavaScript industry upgrade cycle (which is short!),
> We currently use Lit for the framework on top
These two are contradictory statements.
1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer
2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.
> We're currently on material components and migrating some to Shoelace.
Again, this is exactly the "fast js churn" you're talking about.
Is it that Lit gives you a different way of authoring web components than the raw APIs? Yes, that's entirely the point. It's a library that gives you better ergonomics.
Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
> Is it that Lit gives you a different way of authoring web components than the raw APIs?
than the raw APIs, than Polymer, than Stencil, than...
> Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
Again, at this point I literally couldn't care less for your obstinate willful avoidance of authoring, and of your pretending that only the output matters. (And other lies like "lit is native/just html" etc.)
> than the raw APIs, than Polymer, than Stencil, than...
Yes, and? Those are all different opinions and options on how to author web components.
> No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
It's extremely hard to tell what your point is. Lit's newer than React? Yes. Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components. We have customers do this all the time.
I don't avoid authoring, authoring is the main point of these libraries. And what you build is just web components. That's like... the whole idea.
Can you even communicate what this complaint actually is?
> Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components.
Keyword: make.
Again: you keep pretending that authoring web components is an insignoficant part of what people do.
At this point I am fully disinterested in your pretence.
> I don't avoid authoring, authoring is the main point of these libraries.
Yes yes. When authoring web components Polymer is fully compatible with lit.
(Funny when even lit's own channgelogs talk about backward incompatible breaking changes between versions, but sure, sure, Polymer you can just drop into the authoring flow, and everything will work lol).
But as I said, I am completely disinterested in web component salesmen at this point.
> If you really can't find a use case for web components then you're living in a bubble.
There's a very tiny use-case for web components. And even there it's riddled with a huge amount of potential (and actual) footguns that "in the bubble" devs have been talking about for a decade at this point, and some which were finally acknowledged: https://w3c.github.io/webcomponents-cg/2022.html (no updates since)
> There's a very tiny use-case for web components.
That's weird, we've been using them at my company for a number of years and there's plenty of other examples of them being adopted elsewhere too. This continues to read as, "it's not React, so it's bad."
There are companies that still use jQuery, or Angular, or Ember, or vanilla JS, or Blazor, or...
Just because tech exists and is usable doesn't mean it doesn't have a list of issues and footguns a mile long, some of which are explicitly recognized by the Web Components Working Group. And which still need 20+ various specs to paper over.
> Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks.
Yes. There is. The main developers and proselityzers were completely insanely biased against web frameworks (especially React).
It wasn't even a conspiracy. All you had to do was to follow Alex Russel (the person who introduced the idea of web components in the first place) and see his interactions with framework authors and his views towards web frameworks.
The new people in the space driving the specs are hardly any better. E.g. their reactions to Ryan Carniato's rather mild criticism of Web Components is just filled with vile, bile, and hate.
They literally refuse to even admit they have a problem, or want to look at any other solutions than the ones they cook up.
> but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable.
Strange, browsers push dozens of specs for web components without ever taking any time to see if the yet another half-baked "solution" is actually workable.
Some links to examples of the sort of behaviour you're describing would be really helpful here (I say this as someone who is sympathetic - I work with on a web component/Lit codebase in my 9-5 and I'm not a fan, compared to the React workflow I had in a past life).
Unfortunately, as most of them left Twitter they also temoved all their accounts, so you can only see responses from framework authors like Rich Harris.
> agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing
What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.
So, in aggregate, all 17 data leeches are getting info. They are not getting info on all you users, but different subsets hit different subsets of the "subprocessors" you use.
And there's literally no way of knowing whether or not my data hits "two" or "three" or all 17 "at the most".
> but especially your _face_ is going to be _everywhere_ on the internet. Who are we kidding here? Why would _that_ be the problem?
If you don't see this as a problem, you are a part of the problem
reply