www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No Privacy Policy in D tools (dmd, dub, phobos, etc)

reply However (?) <huhapi75.qutotu32 murena.io> writes:
Hello everyone! I was looking at the [Dlang 
website](https://dlang.org/) and found absolutely no **Privacy 
Notice**, **Privacy Policy**, or document that explains the 
handling of user personal information.
Looking at the source code of 
[dub](https://github.com/dlang/dub), 
[dmd](https://github.com/dlang/dmd), 
[phobos](https://github.com/dlang/phobos), 
[dlang.org](https://github.com/dlang/dlang.org), and 
[dub-registry](https://github.com/dlang/dub-registry) 
(code.dlang.org) I did not find (and I am very glad) telemetry or 
analytics of any kind. But I also consider it necessary to have a 
document that explains how dlang.org handles the user's personal 
data.
It even seems like a good opportunity to tell the world that they 
take care of their users' personal information.
Jan 22
next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Monday, 22 January 2024 at 13:45:09 UTC, However (?) wrote:

 [...]


I don't think any user data is collected (although I might be 
wrong), hence no need for a privacy notice.
Jan 24
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 24 January 2024 at 09:20:26 UTC, RazvanN wrote:

 On Monday, 22 January 2024 at 13:45:09 UTC, However (?) wrote:

 [...]


 I don't think any user data is collected (although I might be 
 wrong), hence no need for a privacy notice.


Dub does indeed collect user data. Besides, having a privacy 
policy goes beyond that. See 
https://foundation.rust-lang.org/policies/privacy-policy/
Jan 24
parent reply Arafel <er.krali gmail.com> writes:
On 24/1/24 13:49, aberba wrote:

 Dub does indeed collect user data. Besides, having a privacy policy goes 
 beyond that. See 
 https://foundation.rust-lang.org/policies/privacy-policy/ 
 <https://foundation.rust-lang.org/policies/privacy-policy/>
 


I would like to point out that, at least in the EU, IP addresses are 
considered personal data under the GDPR [1]. This doesn't automatically 
mean that you need to ask for consent from your users*, but you might 
need to add a privacy policy on the website to inform them.

It also affects the dlang.org website, and even more so the forum web 
interface, where there is a registration that clearly involves personal 
data (as related to the GDPR).

I'm not sure how this applies to sites hosted outside the EU, but as 
long as you target EU users it wouldn't hurt to just add one. There are 
a lot of templates around that you can use.

Incidentally, this has interesting consequences when, for instance 
google fonts (or any other external resource) are hot-linked directly 
and not self-hosted. Then, according to at least a German Court [2], you 
are *transferring* collected personal information (the IP address) to a 
third party (google).

IANAL, so I have no idea of how this applies to the DLF, who I assume 
sits in the US, but I thought it might be of interest.

*:  You likely don't if you only do what is needed to keep the server 
running and healthy.

[1]: 
https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en#examples-of-personal-data
[2]: https://www.cookieyes.com/documentation/google-fonts-and-gdpr/
Jan 24
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 24 January 2024 at 13:07:26 UTC, Arafel wrote:

 IANAL, so I have no idea of how this applies to the DLF, who I 
 assume sits in the US, but I thought it might be of interest.


IANAL either, but I did the GDPR compliance engineering for my 
teams product at MSFT. The basic principle is that, unless the 
service is physically hosted in the EU, GDPR has no legal force. 
If a European connects to a US hosted service, they can have no 
legal expectation that GDPR regulations will be followed and if 
they do it is as a courtesy and no action may be brought under 
the GDPR.

IIRC, the EU originally tried to write the law as "any service 
that any European connects to must comply", but I think someone 
somewhere along the way pointed at that most of these services 
were held in the US and the most effective way to "comply" was to 
simply block EU IPs until the engineering work was completed (if 
the company had any compelling reason to stay accessible in the 
EU market). And enforcement would be impossible without US 
support and they got a hard "no" on that.

When I was doing this for MSFT, we just held off deploying our 
product into the EU datacenters and product offerings until the 
engineering and documentation was complete. Took a year of my 
life that work did.

For my current project, our non-US plans consist of "block their 
IPs." GDPR is a massive capital sink for an small business.
Jan 24
next sibling parent reply Danny Arends <Danny.Arends gmail.com> writes:
On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:

 On Wednesday, 24 January 2024 at 13:07:26 UTC, Arafel wrote:

 IANAL, so I have no idea of how this applies to the DLF, who I 
 assume sits in the US, but I thought it might be of interest.


 IANAL either, but I did the GDPR compliance engineering for my 
 teams product at MSFT. The basic principle is that, unless the 
 service is physically hosted in the EU, GDPR has no legal 
 force. If a European connects to a US hosted service, they can 
 have no legal expectation that GDPR regulations will be 
 followed and if they do it is as a courtesy and no action may 
 be brought under the GDPR.

 IIRC, the EU originally tried to write the law as "any service 
 that any European connects to must comply", but I think someone 
 somewhere along the way pointed at that most of these services 
 were held in the US and the most effective way to "comply" was 
 to simply block EU IPs until the engineering work was completed 
 (if the company had any compelling reason to stay accessible in 
 the EU market). And enforcement would be impossible without US 
 support and they got a hard "no" on that.

 When I was doing this for MSFT, we just held off deploying our 
 product into the EU datacenters and product offerings until the 
 engineering and documentation was complete. Took a year of my 
 life that work did.

 For my current project, our non-US plans consist of "block 
 their IPs." GDPR is a massive capital sink for an small 
 business.


Erm, IANAL either, but the GDPR does apply to US companies that 
want to operate inside he EU, since the regulation is 
extra-territorial in scope[1]. Basically any company/organisation 
outside of the EU storing/processing information about EU 
nationals (or non-EU national living in the EU) should be aware 
that they do run the risk of being fined for non-compliance with 
the GDPR.

[1] https://gdpr.eu/compliance-checklist-us-companies/
Jan 25
next sibling parent Danny Arends <Danny.Arends gmail.com> writes:
On Thursday, 25 January 2024 at 15:21:25 UTC, Danny Arends wrote:

 On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:

 [...]


 Erm, IANAL either, but the GDPR does apply to US companies that 
 want to operate inside he EU, since the regulation is 
 extra-territorial in scope[1]. Basically any 
 company/organisation outside of the EU storing/processing 
 information about EU nationals (or non-EU national living in 
 the EU) should be aware that they do run the risk of being 
 fined for non-compliance with the GDPR.

 [1] https://gdpr.eu/compliance-checklist-us-companies/


Just to add, The D foundation is exempt as long as it has less 
than 250 employees [2]

[2] https://gdpr.eu/companies-outside-of-europe/
Jan 25
prev sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 25 January 2024 at 15:21:25 UTC, Danny Arends wrote:

 On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:

 IANAL either, but I did the GDPR compliance engineering for my 
 teams product at MSFT. The basic principle is that, unless the 
 service is physically hosted in the EU, GDPR has no legal 
 force. If a European connects to a US hosted service, they can 
 have no legal expectation that GDPR regulations will be 
 followed and if they do it is as a courtesy and no action may 
 be brought under the GDPR.


 Erm, IANAL either, but the GDPR does apply to US companies that 
 want to operate inside he EU, since the regulation is 
 extra-territorial in scope[1]. Basically any 
 company/organisation outside of the EU storing/processing 
 information about EU nationals (or non-EU national living in 
 the EU) should be aware that they do run the risk of being 
 fined for non-compliance with the GDPR.


If you read the first paragraph again, that's what I said.

The confusion stems from people in the EU incorrectly believing 
that "operating in" is the same as "accessible in". The fact that 
a website/service is accessible in the EU does not mean that the 
service is "operating in" the EU.

At a more fine-grained level, if Product A complies with GDPR but 
Product B does not, then so long as the non-compliant Product B 
is not made available in the EU, then there is no GDPR violation. 
GDPR only applies to services that are *offered* to EU citizens. 
The EU cannot mandate that products not offered in the EU comply 
with EU regulations simply because that business has operations 
in the EU.

By way of similar example, Windows N is the version of Windows 
offered in the EU to comply with the outcomes of some media 
lawsuits in the EU. In the US, we don't have the crippled "N" 
versions, you can only get them from MSDN for testing purposes. 
The EU can only mandate compliance on software that was sold to 
Europeans, they could not force their regulations on versions 
sold in the US. The same principle applies to GDPR.

At MSFT it was easy, MSFT has strict internal deployment controls 
to make sure we didn't deploy non-compliant products into the EU. 
When the GDPR compliance paperwork was complete, we flipped a 
switch and the product went live in the EU.

In the case of DLF, because there are no operations in the EU, as 
the websites are hosted outside the EU, GDPR has no force. Simple 
accessibility is insufficient. There are certainly plenty of 
other reasons to have a Privacy Policy, and to make sure it is 
followed, but GDPR isn't one of them.

And as somebody else pointed out, it looks like the DLF is too 
small (under 250 people) for the GDPR to apply in any case.
Jan 27
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:

 
 For my current project, our non-US plans consist of "block 
 their IPs." GDPR is a massive capital sink for an small 
 business.


Why block eu ips for the eu?

"GDPR Notice, we are not in the eu and if you wish to enforce 
this please invade newyork, make your way through the midwest, 
then conquer California; eu citizens may be interest in reading 
the [a]declaration of independence[/a] and the [a]first 
ammendment[/a] for futher details"
Jan 25
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 25 January 2024 at 16:00:21 UTC, monkyyy wrote:

 On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:

 
 For my current project, our non-US plans consist of "block 
 their IPs." GDPR is a massive capital sink for an small 
 business.


 Why block eu ips for the eu?


To avoid threads like this? It clearly and unambiguously solves 
the entire question.

Also, localization is a massive headache (re: expensive) that 
we'd rather just not deal with. To be fair, we won't be exporting 
outside the US in general, because we aren't going to localize to 
French (Canada) either and that's a legal requirement there.

The US is far and away the biggest market for our software, so we 
find it easier to focus on that.

I am all for following the local laws. But there is no 
requirement that we do business with locales whose laws we find 
too onerous to comply with.
Jan 27
parent reply FairEnough <FairEnough gmail.com> writes:
On Sunday, 28 January 2024 at 03:42:41 UTC, Adam Wilson wrote:

 ...
 I am all for following the local laws. But there is no 
 requirement that we do business with locales whose laws we find 
 too onerous to comply with.


That is certainly fairenough.

However, the focus (and your focus as a developer) should be on 
protecting the personal data of citizens, and not on geography.

That GDPR compliance can be too onerous for some, is certainly an 
issue, but not an excuse to not take all reasonable measures to 
protect the personal data of citizens, including U.S citizens.

Privacy by design and default, should be the guiding principle, 
regardless of local laws and geography. If it's not, it WILL come 
back to bite you, that's is for certain.
Jan 27
parent Adam Wilson <flyboynw gmail.com> writes:
On Sunday, 28 January 2024 at 04:04:42 UTC, FairEnough wrote:

 However, the focus (and your focus as a developer) should be on 
 protecting the personal data of citizens, and not on geography.

 That GDPR compliance can be too onerous for some, is certainly 
 an issue, but not an excuse to not take all reasonable measures 
 to protect the personal data of citizens, including U.S 
 citizens.

 Privacy by design and default, should be the guiding principle, 
 regardless of local laws and geography. If it's not, it WILL 
 come back to bite you, that's is for certain.


I don't disagree with any of that, and we do take it very 
seriously, probably more so than most. And I've actually done 
this kind of work for MSFT and others. But most regulation 
compliance regimes do very little in practice to actually ensure 
that data is secure, and GDPR is no exception.

These types of laws are all about liability and redress when 
something does go wrong. By complying with GDPR the company gets 
a "pass" on liability so long as it complied with said 
regulations. A simple example would be: Company implements a 
compliant password hashing regime, Customer selects weak password 
that is on a rainbow table, Customers data is stolen. The company 
can say "We complied with the regulations, the customer as at 
fault for selecting a weak password." You could argue that the 
companies password hashing regime was also sufficiently weak to 
allow a hashed password that appears in a rainbow table, but the 
company gets a pass because it "complied".

Essentially, this is incredibly expensive cover for businesses so 
that they can outsource their liability to the user or 
government. I can either spend the money on meeting some 
regulations, or spend the money on implementing actually systems. 
In a capital constrained environment, it is better to solve the 
regulation problem as cheaply as possible (IP blocks are free), 
and focus on building a secure system.

In any case, a sufficiently well developed security system is 
going to far exceed the standards of any government regulation, 
so if one day down the road you decide to open up to other 
countries, you aren't paying to redevelop the whole security 
system for "compliance." You pay the fat legal/audit fees and 
move on.
Jan 27
prev sibling parent reply However (?) <huhapi75.qutotu32 murena.io> writes:
On Wednesday, 24 January 2024 at 09:20:26 UTC, RazvanN wrote:

 On Monday, 22 January 2024 at 13:45:09 UTC, However (?) wrote:

 [...]


 I don't think any user data is collected (although I might be 
 wrong), hence no need for a privacy notice.


It may collect little or no personal information, but it is 
always important to indicate this in a formal document. I suppose 
the user deserves to have knowledge about how their data is 
processed.

Also, [dub registry](https://code.dlang.org/) have a 
[login/register 
page](https://code.dlang.org/login?redirect=/my_packages).
Jan 24
parent monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 24 January 2024 at 16:50:49 UTC, However (?) wrote:

 
 It may collect little or no personal information, but it is 
 always important to indicate this in a formal document.


Formal documents do not matter
Jan 24
prev sibling next sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Monday, 22 January 2024 at 13:45:09 UTC, However (?) wrote:


 or analytics of any kind. But I also consider it necessary to 
 have a document that explains how dlang.org handles the user's 
 personal data.
 It even seems like a good opportunity to tell the world that 
 they take care of their users' personal information.


The world (of specialists for whom the site is intended) actually 
knows how personal data is processed on a websites
Jan 24
prev sibling next sibling parent kdevel <kdevel vogtner.de> writes:
On Monday, 22 January 2024 at 13:45:09 UTC, However (?) wrote:

 Hello everyone! I was looking at the [Dlang 
 website](https://dlang.org/) and found absolutely no **Privacy 
 Notice**, **Privacy Policy**, or document that explains the 
 handling of user personal information.


On the help page https://forum.dlang.org/help you'll find some 
information (spreading of e-mail addresses, Gravatar use). Why 
one should abstain from using Gravatar has already been discussed 
elsewhere [1].

[1] 
https://meta.stackexchange.com/questions/44717/is-gravatar-a-privacy-risk
Jan 24
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
The site search is a google applet. Google surely tracks it.

The books page on the D wiki has affiliate links to books about D, with the DLF 
as the beneficiary. Amazon surely tracks it.

Bugzilla is maintained independently by Brad Roberts.

The D forums have a login, and so must keep track of passwords and chosen
names. 
You can access it via any NNTP app, which does not have a login, if you prefer. 
I recommend using a unique password for the D forums. The messages posted are 
all public (which is kinda the point!).

 From time to time, a user will ask that all their postings be removed from the 
forums. We've complied, but since it's an NNTP server with the addition of a 
mailing list, we cannot do anything about copies that have been already
transmitted.

The web site itself keeps track of aggregate usage statistics, such as which 
pages are most clicked on.

Beyond that, I don't know of any information gathering. We simply don't care 
about that aspect. I doubt any of it has any commercial value. Nobody has 
offered to buy the data, and we've never sold any of it.

We deliberately make no attempt to associate user names with real names.

And that's all I can think of.
Jan 24
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Wednesday, 24 January 2024 at 22:53:02 UTC, Walter Bright 
wrote:

 The site search is a google applet. Google surely tracks it.

 The books page on the D wiki has affiliate links to books about 
 D, with the DLF as the beneficiary. Amazon surely tracks it.

 Bugzilla is maintained independently by Brad Roberts.

 The D forums have a login, and so must keep track of passwords 
 and chosen names. You can access it via any NNTP app, which 
 does not have a login, if you prefer. I recommend using a 
 unique password for the D forums. The messages posted are all 
 public (which is kinda the point!).

 From time to time, a user will ask that all their postings be 
 removed from the forums. We've complied, but since it's an NNTP 
 server with the addition of a mailing list, we cannot do 
 anything about copies that have been already transmitted.

 The web site itself keeps track of aggregate usage statistics, 
 such as which pages are most clicked on.


This is essentially what the content of the Privacy Policy on 
dlang.org would tell, but I'm no expert. The spirit of GDPR is to 
let people know what happens with their personal data, considered 
as a resource to protect.
Jan 28
parent aberba <karabutaworld gmail.com> writes:
On Sunday, 28 January 2024 at 13:16:34 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 24 January 2024 at 22:53:02 UTC, Walter Bright 
 wrote:

 The site search is a google applet. Google surely tracks it.

 The books page on the D wiki has affiliate links to books 
 about D, with the DLF as the beneficiary. Amazon surely tracks 
 it.

 Bugzilla is maintained independently by Brad Roberts.

 The D forums have a login, and so must keep track of passwords 
 and chosen names. You can access it via any NNTP app, which 
 does not have a login, if you prefer. I recommend using a 
 unique password for the D forums. The messages posted are all 
 public (which is kinda the point!).

 From time to time, a user will ask that all their postings be 
 removed from the forums. We've complied, but since it's an 
 NNTP server with the addition of a mailing list, we cannot do 
 anything about copies that have been already transmitted.

 The web site itself keeps track of aggregate usage statistics, 
 such as which pages are most clicked on.


 This is essentially what the content of the Privacy Policy on 
 dlang.org would tell, but I'm no expert. The spirit of GDPR is 
 to let people know what happens with their personal data, 
 considered as a resource to protect.


A privacy policy is necessary nonetheless. I hope the DLF at 
least talks to a legal expert. Also information is certainly 
being collected through dub registry and forum. It doesn't matter 
how you handle that data, you still need a privacy policy to tell 
users that like you said.
Jan 28