CloudFlare privacy concessions?

[honestduane]

It was indicated by CloudFlare's representative on this forum that apparently they want two specific JS functions:

• canvas fillText()
  We fully support this; but it seems that CloudFlare is expecting very specific implementation behaviour for setting up iframe elements "on-the-fly" making them think it's not supported because of the timing. So this isn't really something we can do anything about and must be changed by CF.
• domRect.toJSON()
  This is a convenience function we don't have, but which I have added to our pipeline

In addition, they want several additional CSP functions implemented for blob: handling (especially on workers).

All of this is being tracked on our repo.

I'm sad to say that my theory sounds right. This looks like a demand/request that you sell out user privacy by supporting the API required to do Canvas Fingerprinting to me: https://en.wikipedia.org/wiki/Canvas_fingerprinting

Based on only the available data, it looks like they are blocking PaleMoon because PM don't currently support spying on its users via this common form of browser fingerprinting, and they have asked you to add this functionality explicitly to enable that tracking using canvas fingerprinting in PaleMoon, is my current impression.

Does this mean that pale moon is no longer focused on user privacy?

Or were you simply unaware of how cloudflares request could have been in bad faith?

Knowing this now, are you still going to enable these features in palemoon?

Is pal moon still a privacy focused browser that respects the privacy of its users?

I'm worried that by having these discussions with cloudflare and agreeing to implement these Apis that you're effectively just locking the Internet behind a feature set that has to be implemented before they can be truly free to browse the web, which means that the freedom to browse the web and the freedom of speech that writing code represents would be violated, because at that point the minimum requirement would be that you speak the code to support these features.. even if you don't want to, which in my mind is a type of forced compelled speech, as well as discrimination against people unable or unwilling to speak/write the code to do it. This worries me.

I completely agree. I'm aware of the other browsers affected but CloudFlare does really seem to want to double down on the method of shutting out specific clients instead of using their recently-touted "AI" to actually do traffic and behavioural analysis and filtering "bad traffic" that way. I mean, it does feel like marketing is saying one thing, and the tech people are saying another.

Based entirely on only the data available it is my current belief that they are actively trying to decide which browsers are considered legitimate or not, and I'm personally worried that they have some kind of back end deal with chromium and Google to preference chrome/google as most profitable for them based on the fact that they've publicly stated things that are now directly contradicting prior statements they've made. I would love to know more. Perhaps I'm misunderstanding the issue? The problem is when I look through the chromium source code and its dependencies, you'll find that there's a lot of tracking, And it's clear that the priority is to make Google the first party who collects all that data so it can be monetized. I see the request that you enable canvas fingerprinting above by cloudflare as simply a way for Google to monetize the user data of palemoon browser users, and I'm curious how you see the path going forward witj implementing these features as compatible with the palemoon ideal of user privacy.

I'm personally worried about the bias to support chromium above other browsers - even chromium forks - that's being displayed here. I'm also worried about user privacy and user choice as I'm increasingly seeing browser vendors effectively try to force the user into the second party position, where they are in the more submissive and less dominant role in negotiations on rights.

I would personally prefer that users be first party but adding support for canvas fingerprinting doesn't seem to support that goal so I'm interested in How you will respond because from my perspective as an open source individual and given somebody that I'm pretty easy to look up it will be interesting to see how pale mood survives if it can't keep to its stated goals of user privacy because cloud flare is forcing the issue by effectively acting as a gatekeeper and refusing to allow open source projects free freedom of speech because effectively lacking of access is the same as freedom of speech

[andyprough]

Does this mean that pale moon is no longer focused on user privacy?

This is your first post and you are just going to start throwing bombs at the project and its developers?

Seems highly inappropriate.

Are you planning to link your post to some clickbait social media posts as well? I don't think Pale Moon should be your willing punching bag.

Flagged.

[Moonchild]

This is your first post and you are just going to start throwing bombs at the project and its developers?

Seems highly inappropriate.

Well, yes and no, because they are logical concerns if seen in that context. I've split it off because it didn't really need to be in the CF status thread as it's a tangent.

Based on only the available data, it looks like they are blocking PaleMoon because PM don't currently support spying on its users via this common form of browser fingerprinting

Well, the thing is, you are assuming that this is both some proprietary set of features, which it isn't, and that Pale Moon would just bypass any anti-fingerprinting measures to cater to CF. Neither of those two things are correct. In fact, canvas fingerprinting is and has been easily thwarted by Pale Moon's built-in canvas poisoning which takes the more effective route of anti-fingerprinting than outright blocking canvas features. The approach I devised doesn't even need to discern between canvas use and if it's part of some fingerprinting or not, because the resulting poisoning of the data in question is imperceptible by humans in any normal usage of canvas data extraction (e.g. extracting sprites from canvases for html games and what not).

Does this mean that pale moon is no longer focused on user privacy?
Or were you simply unaware of how cloudflares request could have been in bad faith?

Pale Moon is and remains privacy and security aware in its development. Nothing has changed.
I am aware of the potential for some fingerprinting through these methods, and I've already made a critical note to CF about it as it seems to use some fingerprinting background tasks in its "challenges", and if CF would ask us to compromise our user's data privacy then the answer would simply be "no".

I'm worried that by having these discussions with cloudflare and agreeing to implement these Apis that you're effectively just locking the Internet behind a feature set that has to be implemented before they can be truly free to browse the web, which means that the freedom to browse the web and the freedom of speech that writing code represents would be violated, because at that point the minimum requirement would be that you speak the code to support these features.. even if you don't want to, which in my mind is a type of forced compelled speech, as well as discrimination against people unable or unwilling to speak/write the code to do it. This worries me.

I think you need to take a moment to step back and look at the big picture. The web is built on a very large, complex set of features and APIs, many of which can potentially be abused, but not implementing them would in turn have a browser fail in its essential task to be web-compatible for websites that do use these features and APIs in legitimate ways. The requested JS features (of which literally only one is not present, the other as already said is fully supported) do not a walled garden create, and I've already indicated clearly to Michael of CF that that is not something we want to do - and the response was that CF agrees that should not be something they should ask. So there is a need for your understanding to be a bit more flexible and understand that what we do and what CF does is both a complex balancing act in a dynamic environment.

[honestduane]

This is your first post and you are just going to start throwing bombs at the project and its developers?

Seems highly inappropriate.

Well, yes and no, because they are logical concerns if seen in that context. I've split it off because it didn't really need to be in the CF status thread as it's a tangent.

To be clear this was not my first post, and it was extracted off of another thread, so there was a lot of context unfortunately lost in that move. You seem pretty angry so apologies if I offended you because that was not my intention. I'm pretty easy to find online, and I have a long history of working in software and security, and I am very privacy and security focused, so I see the Cloudflare stuff that PM is getting entangled in as a canary for the rest of the industry. I shouldn't be required to have a specific unpatched security issue to be allowed to get past their checks. I was worried this was the case and then they asked you guys for the API required to do it, so that's my current assumption.

Based on only the available data, it looks like they are blocking PaleMoon because PM don't currently support spying on its users via this common form of browser fingerprinting

Well, the thing is, you are assuming that this is both some proprietary set of features, which it isn't, and that Pale Moon would just bypass any anti-fingerprinting measures to cater to CF. Neither of those two things are correct. In fact, canvas fingerprinting is and has been easily thwarted by Pale Moon's built-in canvas poisoning which takes the more effective route of anti-fingerprinting than outright blocking canvas features. The approach I devised doesn't even need to discern between canvas use and if it's part of some fingerprinting or not, because the resulting poisoning of the data in question is imperceptible by humans in any normal usage of canvas data extraction (e.g. extracting sprites from canvases for html games and what not).

With respect I think you misunderstand. I'm well aware that these experimental standards exist. I'm fully aware that these API calls are not proprietary and are intentionally standardized to be cross browser, however I'm also fully aware that as designed, they include multiple security issues, and make fingerprinting that much easier, as many of them provide additional client data/entropy that the user would rather not share, and so multiple forks of chromium have fixed multiple fingerprinting issues because they consider fingerprinting to be a violation of the users trust placed in them.

Does this mean that pale moon is no longer focused on user privacy?
Or were you simply unaware of how cloudflares request could have been in bad faith?

Pale Moon is and remains privacy and security aware in its development. Nothing has changed.
I am aware of the potential for some fingerprinting through these methods, and I've already made a critical note to CF about it as it seems to use some fingerprinting background tasks in its "challenges", and if CF would ask us to compromise our user's data privacy then the answer would simply be "no".

Thank you for that clarification. Its deeply appreciated. I asked this question in good faith, and I apologize if asking the question created a problem. I just wanted to hear the answer. Thank you for giving me the answer.

I'm worried that by having these discussions with cloudflare and agreeing to implement these Apis that you're effectively just locking the Internet behind a feature set that has to be implemented before they can be truly free to browse the web, which means that the freedom to browse the web and the freedom of speech that writing code represents would be violated, because at that point the minimum requirement would be that you speak the code to support these features.. even if you don't want to, which in my mind is a type of forced compelled speech, as well as discrimination against people unable or unwilling to speak/write the code to do it. This worries me.

I think you need to take a moment to step back and look at the big picture. The web is built on a very large, complex set of features and APIs, many of which can potentially be abused, but not implementing them would in turn have a browser fail in its essential task to be web-compatible for websites that do use these features and APIs in legitimate ways. The requested JS features (of which literally only one is not present, the other as already said is fully supported) do not a walled garden create, and I've already indicated clearly to Michael of CF that that is not something we want to do - and the response was that CF agrees that should not be something they should ask. So there is a need for your understanding to be a bit more flexible and understand that what we do and what CF does is both a complex balancing act in a dynamic environment.

Yes I'm very aware of this. I am a fellow software development engineer who also works on a privacy focused browser. I like to think that you and I are both supporting the same goal of user privacy and safety, and are unified in the shared goal of not allowing CF to dictate what browsers are allowed to browse the web. The problem here is that specific features were standardized to be cross-browser in a way that intentional or not, makes the collection of client browser and version specific fingerprints when rendering specific artifacts easier when the api is not implemented in a cross platform way, due to things like memory architecture or even cpu endian, as the API's involved are basically allowing them to set a buffer and then get it back as an object that is base64 encoded, and then use that as a hmac/hash for the Implementation in order to fingerprint the implementation. Think about that. And the api intentionally does not define the output so that you can get the most entropy. Think about that. I see this as a security issue. In addition, this doesn't actually do anything to assure that a human is driving the browser, so it also actively conflicts with public cf stated goals on bot detection to even do it. Using what I would consider to be an exploit against clients is not something that I support.

Like my original post said, I found your project was having the CF issues while I was looking for information to get around some cloud flare issues for our customers. Cloudflare is impossible to contact, and that makes them impossible to work with, or collaborate with, since they refuse to communicate with browser developers, Even ones that have historically tried to be friendly.

I think this project's attempt to show good intentions and be friendly to CF showed just how dismissive CF is to most people; The fact that you got their CTO to respond to you was an absolute miracle.

[Moonchild]

With respect I think you misunderstand. I'm well aware that these experimental standards exist. I'm fully aware that these API calls are not proprietary and are intentionally standardized to be cross browser, however I'm also fully aware that as designed, they include multiple security issues

Please enlighten us what these multiple security issues are. Because security is most definitely priority here and as far as I am aware none of the APIs involved (and we're not talking experimental, here, by the way -- these specs have been peer reviewed and adopted) have fundamental security issues in them.

I am a fellow software development engineer who also works on a privacy focused browser. I like to think that you and I are both supporting the same goal of user privacy and safety

I don't think so. All "privacy focused browser projects" I have seen so far do not keep a balance. Pale Moon isn't going to cripple user experience to cater to an extremist privacy view of the web. The web is a public place; attempting to be fully private while traversing it is folly, IMNSHO. Yes, that means that out-of-the-box, Pale Moon may allow some fingerprinting to succeed, and it's not our task or goal to prevent that at all costs. The mere fact that someone uses Pale Moon to begin with will make them more identifiable than, say, a Chrome user.
Pale Moon does attempt to keep its users safe, and provide some effective tools to make fingerprinting more difficult without reducing usability or interrupting users with prompts that would inevitably lead to confirmation fatigue. And, aside from that, our platform is fully open and extensible to "hammer shut" whatever users perceive as being "too much of a privacy risk". But, that does not include declining essential APIs and features from the browser core just because they might be abused by fingerprinting.
As you may not yet have realised, providing a unique fingerprint by Pale Moon users is intentional and desired. This will likely fly into the face of the approach you think works. I have previously posted several times explaining how this works in practice. You may want to do a forum search and read up about our canvas poisoning, to name one thing.

Cloudflare is impossible to contact, and that makes them impossible to work with, or collaborate with

I suggest you take the opportunity to reach out to Michael via e-mail to be included in the proposed browser developer program they are drafting, then. He has posted his address publicly on this forum. If you are a browser developer yourself as you say, then it would serve you well to make use of the communications channel offered as result of our month and a half long struggle to get a response from CF.

[honestduane]

Please enlighten us what these multiple security issues are. Because security is most definitely priority here and as far as I am aware none of the APIs involved (and we're not talking experimental, here, by the way -- these specs have been peer reviewed and adopted) have fundamental security issues in them.

It's too much to go over here, lol.

My problem with this is that a lot of these api's are audited in isolation, by peers that don't care and will often just LGTM, and not in the context of what else the execution engine supports. I'm fully aware of the difference between somebody doing "it looks good to me" and somebody doing an actual formal validation of the system using a truth table. The problem is when somebody is given these Apis they are often asked to test them in isolation, not the implementation, which is what the issue with fingerprinting a canvas comes from in that the API's themselves are standardized cross platform and they should interact and work with the same outputs and inputs exactly the same way, but because of architectural differences they do not, and that is where we get the variance that they're using for fingerprinting. The the ability to fill text in a canvas div and then use deserialization via toDataString/to-string or something to get back part of the DOM as a blob that you can then base64 or extract a hash from for fingerprinting as explained by https://en.wikipedia.org/wiki/Canvas_fingerprinting is still a security issue that limits peoples privacy, And is still considered a security issue even though the API calls seem benign. It's exactly these boring and benign looking things that ultimately end up being the greatest part of a exploit chain, even if the exploit chain is simply to validate that the Person is using a browser brand/version on a very short list in order to Intentionally cheat browsers not on that list from accessing the resource.

I also have professional experience as a security auditor, did that for the first time at MS Research many years ago before returning for other roles, so I know there is a process and I know that you may not consider the issues that I'm finding to be security issues but I do believe that you'll find them to be privacy issues. I consider every privacy issue to be a security issue. The problem here is communication (its lack, more specifically, As even if I use emails that have been made public I get bounce backs that show that my email is not getting sent to the right people.). And from a pure QA perspective, I envision a lot of these as poorly defined API's that could have benefited from more use of https://datatracker.ietf.org/doc/html/rfc2119 as without that these API's have lead to platform specific differences that can then be fingerprinted or create issues per the above.

I also see a lot of the newer standards enforced by Google (via them just checking it into the code with no user ability to say no or push back) as bad. The extra headers they want you to send everywhere leads to a lot of bad assumptions about user devices or users themselves, and one of my biggest pet peeves is that they seem to not care if the user is disabled or not, and seem to like to think that if somebody is using an accessibility tool, then it has to be a bot user, which is generally not the case, and ends up outright discriminating against the disabled or the blind like myself. I'm technically deafblind so I care about this. I want people who can't fully see or can't fully hear to be equals on the Internet. The problem is that this bias against people who use accessibility tools is so systemic that there's no way to push back, Especially with companies like Google and Cloud Flare refusing to acknowledge the harm they're doing.

Why is a browser telling you that I'm a desktop with multiple monitors at different resolutions if in reality I can't see because I'm blind and I actually just care about making sure I get all the text so I can have it read to me, and use a virtual space in my reader to do that? Why do you need to know its a desktop and not a laptop? What if it's a laptop that just doesn't move? Why does the remote website need to know that I have 32 cpu cores (JAWS can be slow), 6 UHD screens (for zoomtext), or 128 gigs of RAM (See JAWS and ZOOMTEXT), or track my battery charge in real time? It doesn't. The browser should work fine if I want to disable any of these. I have honestly do feel like most browser vendors have forgotten that their software runs on other people's systems. Other people own those systems, not them.

I've also seen advertising technology used to explicitly stalk, harass, or dox individually specific people, so I don't feel like ads are benign, either. Malvertisments can still kill just like they used to (Remember when an advertisement could kill you with a pop up that flashed too much? It still happens, giving people Seizures. Loud audio is also an issue. Others just install stuff that you don't really want on your system anyway.) Advertisements are a real security risk and even chromium decided to try to sandbox them, because of that. Advertisements are a very deep rabbit hole that goes into some very dark places.

Needless to say, There are multiple privacy and security issues involved.

Pale Moon isn't going to cripple user experience to cater to an extremist privacy view of the web. The web is a public place; attempting to be fully private while traversing it is folly, IMNSHO. Yes, that means that out-of-the-box, Pale Moon may allow some fingerprinting to succeed, and it's not our task or goal to prevent that at all costs. The mere fact that someone uses Pale Moon to begin with will make them more identifiable than, say, a Chrome user.

Respectfully, and I hope I'm misunderstanding you, I don't think the opinion that people have the right not to be tracked or spied on is an extremist view of privacy on the web; I effectively have the same view of the web as the EFF (EFF.org) and support https://www.eff.org/pages/surveillance-self-defense - I can only hope that we are in violent agreement that a browser should be useful to users and have its own identity it seeks to protect while doing its best to take care of users who trust it. In this case I saw CF making a request of you that I didn't think you fully understood, and I was trying to be helpful out of good will. Apologies if that was taken some other way.

Pale Moon does attempt to keep its users safe, and provide some effective tools to make fingerprinting more difficult without reducing usability or interrupting users with prompts that would inevitably lead to confirmation fatigue. And, aside from that, our platform is fully open and extensible to "hammer shut" whatever users perceive as being "too much of a privacy risk".

I'm glad about this. Congratulations.

But, that does not include declining essential APIs and features from the browser core just because they might be abused by fingerprinting.

Respectfully, I think we have a different perspective of individual Api's and what they do in the greater scope, And I hope that irony is not lost on you as we are actually two different browser development engineers working on different browser engines that still have to implement these same apis. If you think about it, it's actually kind of funny and ironic. I'm happy to continue a deeper discussion on the overall scope and how each jigsaw puzzle fits, if you're up for it. I'm even happy to submit a pull request or two if it's not against my current employers wishes (They are ok with my posting here, I asked). That stated, respectfully, I don't consider api's that track people without their consent to be essential. I fully support the EFF's absolute privacy goals as I recognize that privacy keeps people from being victimized or targeted. And your browser worked fine without these before, So clearly they were not essential until CF demanded them of you, right? Either way, I really do respect the position you're in, and what you want to do for your users, but I also wonder. It's clear CF is throwing their weight around, and from my perspective they are forcing you into something that seems suboptimal for everybody. To be honest it was my hope that you would get CF to consider that. I'm disappointed and saddened by CF's actions here. They should have treated you and the community better, And I had hoped that they would because I had hoped that they could be the sort of company that could actively help and promote humans using non-chrome browsers.

As you may not yet have realised, providing a unique fingerprint by Pale Moon users is intentional and desired. This will likely fly into the face of the approach you think works. I have previously posted several times explaining how this works in practice. You may want to do a forum search and read up about our canvas poisoning, to name one thing.

Yeah canvas poisoning is often used to mitigate this threat, but I'm glad that you're already doing it as I had not had the opportunity to check that part of your code yet. Thank you for the recommendation.

Cloudflare is impossible to contact, and that makes them impossible to work with, or collaborate with

I suggest you take the opportunity to reach out to Michael via e-mail to be included in the proposed browser developer program they are drafting, then. He has posted his address publicly on this forum. If you are a browser developer yourself as you say, then it would serve you well to make use of the communications channel offered as result of our month and a half long struggle to get a response from CF.

I have tried. Every email I send them gives me a bounce that that the email doesn't exist.

[Moonchild]

Just a quick response as I don't have time right now to read the full essay.

It's too much to go over here, lol.

Well, just name at least one or two actual security issues? Security != privacy. As a self-proclaimed professional security auditor, you should not have to be educated about that fact. Some vague statement about security audit practices or verification procedures by implementers really don't answer my question.

Also, before something is standardized formally, it does go through a 4-stage discussion/evaluation/feedback procedure before implementers are supposed to even publish it (although some mainstream browser engines *cough*Blink*cough* have an implementation-first strategy and standards are then written with the implementation as a guide...). Then, implementers will still have the freedom to make implementation changes to address security issues in their environment. Implementations will differ, and fingerprinting based on that will always be possible in some circumstances, which once again stresses that "blanking out"/not including APIs as a whole and trying to blend into the biggest portion of the pool isn't effective.

Still, nothing of that has to do with security. And nothing of that should prevent browser implementers from adopting described standards or specific implementation steps in most cases (although we have, in some outliers, assessing the trade-off was too great).

[Bilbo47]

Security != privacy

Technically true. However as a user, comparing a problem defined as one of those versus a problem as the other, the distinction makes no difference as far as the situation I would experience. From that viewpoint, these concepts live together in the same larger bucket of "using the web" (site, platform supply chain, DOS mitigator, browser, virus, it doesn't matter) somehow screwed me over. If I get hacked/doxxed/robbed via a "privacy" hole, then that was actually a security hole.

[RealityRipple]

Security != privacy

Technically true. However as a user, comparing a problem defined as one of those versus a problem as the other, the distinction makes no difference as far as the situation I would experience. From that viewpoint, these concepts live together in the same larger bucket of "using the web" (site, platform supply chain, DOS mitigator, browser, virus, it doesn't matter) somehow screwed me over. If I get hacked/doxxed/robbed via a "privacy" hole, then that was actually a security hole.

They're often obviously at odds with each other, you just don't think about it as such. Take a list of your previous login devices and locations. Total privacy violation for the sake of security.

[andyprough]

I effectively have the same view of the web as the EFF (EFF.org) and support https://www.eff.org/pages/surveillance-self-defense - I can only hope that we are in violent agreement that a browser should be useful to users and have its own identity it seeks to protect while doing its best to take care of users who trust it.

Good points, I strongly agree, sorry for flagging you earlier. I figured you for a troll, hope you'll accept my apology. Although I also hope you understand that we need to be a bit vigilant and not let this issue get hijacked. After a month and a half of doing everything we could all possibly think of, Pale Moon is finally not being hit with what amounts to a malware attack every time one of our users stumbled into a cloudflare verification page - I think the project would prefer not to continually be under attack in this specific manner.

I hope you'll let us know which browser you are helping to develop, I'd like to take a look sometime. I like your views on privacy and the EFF ideal, these are very interesting issues for me personally.

[BenFenner]

I figured you for a troll

You were right.
Poe's law (or something adjacent, Grey's law?) is working overtime here.
This poster has done the nearly impossible: reduced me to defending Cloudflare in certain circumstances.

I hope you'll let us know which browser you are helping to develop

Same.

[Moonchild]

Respectfully, and I hope I'm misunderstanding you, I don't think the opinion that people have the right not to be tracked or spied on is an extremist view of privacy on the web;

I think it is. The question is about scope, though. It depends on how you define "tracking", too. The reality is that if you move around on the web, you are moving through public spaces. The same way you can be (and are being) recorded in the street, in shops and local public places and gathering spots, your movements on the web are recorded in various ways. There are rules to follow, both by you as a visitor, and by the places you visit. If you think your visits can be and will be fully private while visiting other people's systems and virtual areas (domains) merely through the vessel you use to visit, then I think you don't understand how the Internet works, exactly. This is the same problem why DNT signals failed as a concept, but GPC signals can work.
"Being spied on" in the common sense of the meaning is slightly different, as that would be deliberately observing user actions that aren't exposed to a public space by their nature; of course I am against that, but that isn't something a browser normally does without permission; even those browsers that have potentially privacy-infringing APIs exposed to content will all have permission structures in place to prevent this.
So we can agree to disagree here.

I effectively have the same view of the web as the EFF (EFF.org) and support https://www.eff.org/pages/surveillance-self-defense - I can only hope that we are in violent agreement that a browser should be useful to users and have its own identity it seeks to protect while doing its best to take care of users who trust it. In this case I saw CF making a request of you that I didn't think you fully understood, and I was trying to be helpful out of good will. Apologies if that was taken some other way.

Respectfully, I think we have a different perspective of individual Api's and what they do in the greater scope, And I hope that irony is not lost on you as we are actually two different browser development engineers working on different browser engines that still have to implement these same apis.

A browser should indeed be useful to its users -- which is exactly why useful APIs (like canvas) should be and remain available to users. I fully understood CF's request, but it seems you did not. "FillText" is a very useful and essential canvas feature to render text on DOM canvasses, for example, but you seem to have an issue with it only because it's a common feature used in current (but possibly not future) fingerprinting routines. That isn't a problem with the feature; it's a problem with how it's being used. If a feature would have no other use than fingerprinting/profiling the user, then that would be different, because that would not be a "useful API". DOMRect.toJSON is just a convenience function that doesn't expose anything that isn't already available otherwise. The CSP functions actually make it harder, not easier, to extract user data from browsers that isn't specifically authorized by the website visited. So, that's three times where there is zero concern for negative impact on a user's privacy when looking at the APIs themselves. And as mentioned before, direct actions against the malicious use of these APIs instead of killing the APIs themselves is more effective. Compare it to a knife. You can use it to chop vegetables or to hurt someone. Does that make a knife bad and to be forbidden?

And I do add my voice here that I'd like to know what browser you are involved in. I find it convenient (for you) that your mails bounce while everyone else can e-mail Michael just fine. If your browser is to be involved with CF's browser developer program to address these issues for you, then you should definitely solve your communications channel problem. I for one won't be relaying anything outside of my own dev scope to them; it's already big enough as it is

[andyprough]

I find it convenient (for you) that your mails bounce while everyone else can e-mail Michael just fine.

I don't see this as surprising. We tried many ways to get a 2-way communication going with cloudflare, including emails and social media direct messages. I know that I tried those avenues myself, and all attempts were either ignored or died on some cloudflare spam filter. It's quite believable that this poster's email domain was rejected. By the tone of the poster's comments I wouldn't be surprised if they are running self-hosted email, which is notorious for getting rejected by big corporate spam filters.

Probably what this poster needs to do is something like go on Tor and sign up for a free protonmail account using Proton's onion service in order to have a relatively tracking-proof email address that will have a chance of not getting rejected.

[Moonchild]

I wouldn't be surprised if they are running self-hosted email, which is notorious for getting rejected by big corporate spam filters.

FTR Pale Moon e-mail is self-hosted, too. That doesn't seem to affect deliverability at all for CF mail addresses.

[andyprough]

FTR Pale Moon e-mail is self-hosted, too. That doesn't seem to affect deliverability at all for CF mail addresses.

I'm sure that you do self-hosting correctly, you are very very wise in all such things, whereas from my understanding a lot of self-hosted emailers do not know how to set it up to avoid getting consistently blocked.

Anyway, who knows - maybe it's just a convenient story the OP is telling, I don't know.