So you don’t want developers to be anonymous/pseudonymous?
That means we can’t have censorship resistance. That means if all the Eyes countries go through with requiring KYC on OS level, maybe now, maybe in the future, then there is nothing we can do about it and have no way to resist.
Anonymous/pseudonymous developers is the only way we can have freedom.
You’re also a bit too focused on trust. Don’t forget that it’s mainly about distrusting the infrastructure. You’re not supposed to trust developers. You’re supposed to verify. That’s the point of open source.
And yes, there is of course risk in resisting tyranny. That’s why we need to work together to create a infrastructure that makes it easier. For example, it really shouldn’t be so difficult to have a discussions that doesn’t require JS. And emails are the primary tracking method which the surveillance state uses. When not even qubes os, possibly the most secure OS in the world, uses insecure email as requirement to participate in development and community, that’s not a good sign.
It makes sense that a linux distro like Mint or Ubuntu uses email and JS, but for projects like Qubes OS, Tor, Whonix, that makes no sense.
It’s because of this kind of backwards infrastructure that it becomes more difficult for pseudonymous developers to not get caught.
The sad thing is that what I’m saying has been said by people in security/privacy communities for many many years. But the developers never listen. I just hope that this age verification event wakes everyone up. And if it doesn’t, it could be a signal of state actors pressuring the devs to not resist.
Hi, I’m still here. @michael already shared the team’s position on this above. I don’t have anything else official to share right now. I suggest we all try to keep a cool head while we continue to monitor the situation.
Good to know, thought you might have left the project. I remember you as a prudent thinker, so I thought you might have something to add to this rather important discussion, officially or unofficially.
That said, while the californian law has yet go into effect and thus there is still roughly a year to monitor the situation, the Brazilian one is already the law of the land. And therefore it would be good to know where the Qubes team stands on this as well. The Brazilian law is full blown age verification, not mere age attestation like its californian counterpart, we are talking biometrics, IDs etc. It’s a complete surveillance package
So you don’t want developers to be anonymous/pseudonymous?
I wonder how you made this conclusion from what you quoted.
No, I am not saying what I want or not. I am explaining the negative effects of potential attempts to hide real identity and the naivety of the thinking that if one is a target, one can simply set a nickname and be untouchable in an owned infrastructure.
That means we can’t have censorship resistance.
Hiding developer identity is not really censorship resistance. In the current topic, it is just an over-expectation that it will protect the developer who decides no to comply with AB-1043 from hypothetical legal sanctions, because the adversaries are techno-idiots lacking the capacity to find such brave rider to Camelot.
That means if all the Eyes countries go through with requiring KYC on OS level, maybe now, maybe in the future, then there is nothing we can do about it and have no way to resist.
Just because the only way you are considering is highly unreliable, does not mean there is no way at all.
Anonymous/pseudonymous developers is the only way we can have freedom.
This implies that all the freedom we have is the result of anonymity only. Obviously false.
You’re also a bit too focused on trust. Don’t forget that it’s mainly about distrusting the infrastructure. You’re not supposed to trust developers. You’re supposed to verify. That’s the point of open source.
This is not true but also off-topic, so let’s keep it for another thread.
And yes, there is of course risk in resisting tyranny. That’s why we need to work together to create a infrastructure that makes it easier. For example, it really shouldn’t be so difficult to have a discussions that doesn’t require JS.
I have already had that discussion. You can see the outcome.
The topic is “how much do we gotta worry about this age verification BS”
Right. It is not “should Qubes OS move to a fully anonymous development model”.
Based on that, I think it is better to keep the two separate. If you decide to proceed in another thread, feel free to tag me and I will reply to all relevant questions or valid counter-arguments you may have.
There is , as you should be aware, a difference between the
California, NY and Brazilian approaches. The latter mandates that
service providers put in place age verification - if you feel that this is
not for you do not use the service. There is nothing for Qubes to have
an opinion on here.
The Californian law puts an onus on operating system providers to put in
place a mechanism for storage of DOB/and or age bracket. The information
is self reported.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Yes, as several of my messages alluded to, there is a difference between the californian approach and the Brazilian one. The former requires age attestation (user reported) at the OS level, while the latter requires age verification (biometrics, IDs etc) at both the OS and the App Store level. what do you mean by “There is nothing for Qubes to have
an opinion on here.”? Qubes shouldn’t have a stance on laws which mandate OS VERIFY users’ ages??? It’s extremely relevant.
Thank you, I have already read the Act, and relevant ANPD publications.
AFAIK it is specifically stated in the Act that it applies to products
or services aimed at children or likely to be used by them. I cannot
believe that Qubes falls in to that category. ANPD has stated that
they will apply the Act proportionally to each case. It is for this
reason that I think it unlikely that Qubes should be concerned. (The Act
does not apply to every OS despite your concern.)
In any case, as I have repeatedly said, the best approach for Qubes now
is to consider the advice and approach taken by Xen, Debian and Fedora,
before announcing their position. I am glad that they are doing so, and
not rushing to ill informed and hasty decisions.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
In any case, as I have repeatedly said, the best approach for Qubes now
is to consider the advice and approach taken by Xen, Debian and Fedora,
before announcing their position. I am glad that they are doing so, and
not rushing to ill informed and hasty decisions.
As it is well known, Fedora is sponsored by Red Hat (a partner of the authors of this law) who already merged age verification into systemd and refused to revert it, as per earlier posts in this thread. That is a clear position, a political one.
It is well known - in fact I made this point at a much earlier stage of
this discussion.
I do not know what you mean by “a partner of the authors of this law” -
can you point me to evidence for this? Who were the other partners? What
public position have they taken? (I have little time free so please
accept apology if this is easily searchable.)
I loathe systemd in its entirety. But the addition of an optional
field for age storage does not constitute age verification. The
developers who pushed this through provide a place for storage of age.
You can put whatever you like in that field, just as you can store
“McLovin” as your Real Name.
Age verification is a complex issue, and any position should be based on
a clear understanding of Legal requirements, and proper advice on how
to respond to them. If you tell me that you are against age
verification, are you against it in every case? The Brazilian law,
(like many), is explicitly framed against the backdrop of child
protection. I would not want to enter in to that discussion here, but
it’s important to understand that background and provide solutions that
address it. The service providers undoubtedly have a vested interest in
pushing age verification from them to the OS, and I have no doubt they
have been lobbying hard for that change.
For what it’s worth, if Qubes introduced a mandatory document backed
dob/name/race/sex/photograph/FIN (add your identifying characteristic
here) entry requirement, I’d be out of the door.
How Qubes responds to legislative requirements around the world while
retaining the emphasis on security and privacy is a difficult question,
and the team should not be pressured in to taking ill informed decisions
or making premature statements.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I do not know what you mean by a partner of the authors of this law -
can you point me to evidence for this?
Who were the other partners?
Not sure I understand the question.
What public position have they taken?
I am not aware of any official/formal one. I am just referring to the fact of that merge and the refusal of the revert which reveals the position implicitly. Putting that alongside the partners, it is not difficult to see the direction is definitely not towards ageless Linux.
I loathe systemd in its entirety. But the addition of an optional
field for age storage does not constitute age verification.
Hence my rectification. It is really interesting to see how systemd-supporting distros will react.
The developers who pushed this through provide a place for storage of age.
You can put whatever you like in that field, just as you can store
McLovin as your Real Name.
For now. Yet, it’s a step towards boiling the frog. It’s how things work today.
Age verification is a complex issue, and any position should be based on
a clear understanding of Legal requirements, and proper advice on how
to respond to them.
I doubt any legal advisor would advise not to comply with law. That still doesn’t make the law right per se. Also, as I said earlier, this is rather a legalized justification of planned activity/possibilities. It has nothing to do with protecting children, who are not allowed to use certain apps but it’s fine to let them choose/change their gender without parents even knowing (also legal). Along these lines, I don’t even see a possibility to base a position on clarity and logic. It all comes down to what we have seen, what we are seeing and what is known about the plans of those who push in direction that suits the 1%.
If you tell me that you are against age
verification, are you against it in every case?
I am absolutely for protection of children. I am against the pretense that this is done for such purpose. Politicians who visit particular island and don’t even shy away from that cannot possibly convince me it is not a pretense. Neither can those who kill thousands of children because they “fight terrorism” and call this “great success”.
This is the shortest way to answer your question without going further into the big questions behind it (which are the important ones).
For what it’s worth, if Qubes introduced a mandatory document backed
dob/name/race/sex/photograph/FIN (add your identifying characteristic
here) entry requirement, I’d be out of the door.
That sounds great. I am afraid it is far more complex though and simply stepping out may not help anyone, except one’s consciousness.
How Qubes responds to legislative requirements around the world while
retaining the emphasis on security and privacy is a difficult question,
and the team should not be pressured in to taking ill informed decisions
or making premature statements.
What information is missing or necessary? What ill informed decisions made those who joined the ageless Linux initiative?
In that case, have you also read how they define “likely to be used by children and teenagers”?
This is crucial in more than one way, first it includes teenagers, secondly, it’s how they define “likely”. I happen to also speak Portuguese so I read the legislation directly without relying on translation tools. I will explain briefly how they define “likely” in the very first article is purposefully written to include all OS.
1-Sufficient probability of a product or service (they explicitly include OS in the product or service category) being used by children and teenagers.
This is ambiguous enough to mean whatever they want and in fact, my friends and I have been using linux since we were in our teens. There are many such cases.But it gets worse.
2-Considerable ease of access and use by children and teenagers to products and services (again, this includes OS).
Getting access to Qubes is extremely easy, anyone can come to qubes-os.org and download it for free lol, it’s not as if Qubes OS is Astra linux, which requires hundreds of dollars/euros to be bought and used.
The third criteria applies less to OS and more to other “products and services”
The second article then defines what they mean by products and services.
Number 7 of the said article explicitly includes OS.
Read bellow:
" VII – sistema operacional: software de sistema que controla as funções básicas de um hardware ou software e permite que aplicações de internet, programas de computador, aplicativos ou outros softwares sejam executados por meio dele;"
Relying on the good sense of politicians and government officials is wishful thinking.
There is mounting evidence already that they will monitor compliance of OS at large and not just IOS,windows etc.
The ANPD explicitly references that they will monitor the compliance of linux distributions like Canonical’s Ubuntu for example. It’s perfectly reasonable to expect they will do the same to Redhat and others.
To me, it’s pretty clear that they are covering all OS in their shitty bill. That said, I do not think this bill applies to Qubes on jurisdictional grounds. Brazilian laws apply in Brazil and to companies which operate commercially in the country, like apple, google, microsoft and perhaps even canonical and red hat. Qubes is neither commercial in nature nor registered in Brazil. It’s merely passively available globally. This is much more clear in the US’ case (california’s bill for instance), where there is a treasure trove of jurisprudence on the issue of jurisdiction. Again, I am not a lawyer and this is not legal advice
Will Qubes OS comply with every surveillance legislation package disguised as child protection that comes from all over the world? Because more of this ‘age verification’(identity verification) will come, from europe, from NA, from SA etc.
Many projects have already either taken a stance or hinted at the direction they are likely to go. System76 has stated that they will comply even though they disagree with the law and are lobbying for open source exceptions (they have to since they are a for profit company). While, on the other hand, Graphene OS project has publicly stated that they won’t comply with such laws. Same with Artix. It’s not unreasonable for us users to be worried and to want Qubes to indicate where they stand on these issues.
I do remember a post from half a decade ago, about the EU, in an early version of chat control, considering implementing client side scanning at the OS level (essentially a backdoor). This version of chat control turned out to be discarded but I remember Marek taking a courageous and principled stance on the issue.
He said: “Anyway, we’ll fight back any request to backdoor Qubes with any means available to us. In case of all the options exhausted, we’d rather stop maintaining the project, than to ship backdoored product.”
While the current situation is a bit different, the underlying principle is the same: Governments wanting to force surveillance upon open source OS. It’s the scope and nature of surveillance that changes.
I, for one, (and I assume many other posters on this thread) would greatly appreciate seeing a similarly principled stance to the one Marek took 5 years ago.
In my opinion, the discussion mixes two aspects that are security-wise rather different:
If we are talking about some age registration feature like the data field suggested or implemented in systemd, this has no real influence on the security of a system, as you may enter an arbitrary value in this field. You may lie about your age or even put complete nonsense into this field. So it is not possible to extract any information of value from there.
Age verification, on the other hand, is something completely different. Here, the system has to get some external information describing the age of the user, and compare this with the proclaimed age. If we are talking about a high security level, access to such external information sources is absolutely unacceptable or even forbidden, like when you are processing information classified as NATO CTS or CTS/A. A really secure system must never be connected to any external information source, because, otherwise, information may leak out or malware slip in.
So, if Qubes wishes to retain its labelling as being “reasonably secure”, it simply cannot include a mandatory age verification. I would hate to use it as a “reasonably insecure” system!
On the other hand, I see any possible age verification as a matter of the operating systems running in the AppVMs, because they are running the user applications that may access the internet. So it might be sufficient not to block such features if they are installed in a template. It may even be feasible to provide template versions with and others without age verification, perhaps even give a warning when installing the latter. This might even help with the problem that @adrelanos pointed out, that Qubes could be made responsible for templates that are created by its maintainers.
If we are talking about some age registration feature like the data field suggested or implemented in systemd, this has no real influence on the security of a system, as you may enter an arbitrary value in this field. You may lie about your age or even put complete nonsense into this field. So it is not possible to extract any information of value from there.
Why do professional programmers who know very well all that do this meaningless thing? It does not provide compliance and has zero legal value. In fact, it may be considered illegal in regards to the GDPR because alongside username (which is an identifier, i.e. ‘personal data’) and requires the ‘controller’ to inform the ‘data subject’ how exactly that data will be processed, ask for explicit consent, provide option for not processing that data, etc.
Considering the law does not talk about birth date only but “birth date, age, or both”, why a birth date field, i.e. the more identifiable data? What is the intent here?
I’m stepping out of this discussion. I have limited time and little
more to add.
If Age verification at OS level requires mandatory document backed
identifying details of any kind, it is worrying BS.
If Age verification at OS level requires user input details alone it is
no more worrying than asking for a username backed by Full Name, Address,
etc on install.
What your political overlords will do with this information, if
mandated, is the real worrying thing. Qubes has a part to play in
mitigating such worries.
I’ll repeat for the last time that I think waiting for informed advice and
opinion is the best policy. Theatre like “ageless linux” wont help
users in enforcing states.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Part of groundwork useful for age prompts using other tools: Yes.
GDPR violation: No, most likely not, as it is only a data field, not a data request.
Sufficient for compliance with age API laws (if applicable): No, most likely not.
Additional system modifications required in other places to actually prompt for the age, let alone verify it, if some distribution wanted to implement this: Yes.
Not legal advice. Primarily source code analysis.
I have not seen any Linux distributions yet implementing the actual mandatory age prompt graphical user interface. Anyone?
[…] I do not see how systemd itself would violate GDPR here, because systemd only implemented a way to store the information if someone chose to store such information.
Yes, an empty field is not data. What I meant was that the one who controls how the data will be processed may need GDPR compliance. While the birth date per se is not an unique identifier, combined with other data (e.g. recognizable username, email address, etc) it becomes that. See Article 4.1.
