Re: Privacy concerns raised in the WAN show 21/12/19

[Ace2213]

I recently decided to start a social network the addresses the problems that exist with current implementations. I quickly found myself facing all these privacy challenges that were discussed on the WAN show last night, regarding user data and human tracking. I was extremely troubled by what I felt was the industry cornering me into making choices that essentially serve up my users' data on a platter. I decided to take a stand and try to find a privacy-friendly solution for each scenario. Not all of these are related to websites. Some are examples that Linus brought up and I have found a solution for.

Weather? Ask the user to input their city. Is it as accurate as geolocation? Probably not, but good enough.

Navigation? Unavoidable. That said, it's not necessary that Google constantly tracks you and makes suggestions/guesses about places you visit frequently and asks if these are your home/work. Home and work are very useful to program in, but they should be done manually by the user. It's not that hard.

Voice assistants? Great, but turn off trigger phrases by default. Or better yet, for everyone. It's not that inconvenient to (long) press a button or squeeze your phone to have it begin listening.

Biometrics? Should only be stored locally on the device and encrypted.

Facial recognition? Should be banned.

Habits/interests/demographic/history? Obviously not only completely unnecessary, but also borderline predatory.  Unfortunately marketers love the shit out of this, and that's not my area so I don't have a solution.

 

Advertising? Ads suck. But they don't have to. Classifieds are nice, don't require spying on you, are not repetitive or monotonous, don't show up when you don't want them to or for things you don't care about, and they encourage individuals and small businesses, as opposed to ads which are usually ran by inhuman corporations. Perhaps if corporations tried to become more human about this instead of shoving ads down our throats after spying on us and still being creepy rather than interesting, people wouldn't hate them so much.

IP addresses? Unavoidable, so keep them for a few days or a week tops. Blacklists make sense, until you remember that VPNs exist. Maybe encrypt IPs?

External services? Whenever you integrate a third-party service into your website, you're inevitably sharing some data with them, like SSO for example. You can control what data you give them, and if they insist on requiring certain unnecessary data, find another provider for the same service that is more respectful of privacy. It's that simple.

Payment gateways? By integrating them and their buttons, you're allowing them to serve cookies through your website (on every page, even ones that don't show the button and have nothing related to payment on them). Floatplane's homepage for example, without being logged in, in incognito mode, serves 14 cookies. One by sails.sid, one by Cloudflare and the rest are all by Stripe or Paypal. Unless you know what each of those cookies is doing and can vouch for them, it's best to not serve them since they can be used to spy on users. Most buttons use an HTML form, an image and/or a javascript file hosted on the gateway's website and by requesting it in your website's code, your visitors also pull the cookie. So while it takes some work, it's possible to emulate the view of the button using HTML, CSS and local images (on your server) to bypass the querying of the gateway's website without affecting its functionality.

The big one, Cloudfrickingflare? Despite my best efforts, I was unable to find a suitable way of deploying their services. Using them as a DNS is fine (aside from the obvious ramifications of that), but if you want to take advantage of most of their services, you have to allow them to proxy your website and serve it for you. This gives you access to their CDN, DDoS protection, firewall features, apps, SSL certificates (which I think are extremely problematic but won't get into them here), analytics, etc. But when you use them as a proxy they start serving their controversial _cfuid cookie. And since they are the edge node, they are the final line between you and your end user, so there's nothing you can do about it (short of maybe using javascript to delete their cookie after it gets served to the user). They can modify your website, inject content and cookies into it, block your own content, but you can't do anything to their modifications. Their cookie is controversial because it doesn't have a "secure" flag, which triggers security warnings in some tests. My issue however is with the existence of the cookie all together. Cloudflare refuses to explain what the cookie is used for, hiding behind excuses like "security purposes" (which is false because that cookie is served even without using Cloudflare SSL or any of their security features), and their publicly facing information explains that they place this cookie on every single internet user's device. If this cookie is discovered, you are considered "safe", because you have visited a website proxied by Cloudflare in the past. If the cookie does not exist, you are considered "risky". Obviously this is a ridiculous way of conducting "security", assuming that's all the cookie does. I got banned from Cloudflare's forums for asking about the issue and referring to it as spyware, after being given the runaround by their mods and told to simply "don't use it if you don't like it". So, I don't use it. Is it ideal having to find different, more expensive providers for each of their features separately? No. But it's worth it. Cloudflare has become too powerful to be given the benefit of the doubt and entrusted in this way. And the EU cookie consent law is quite frankly crap and only annoying because as mentioned in the WAN show, very few people read and even less understand privacy policies, that use intentionally cryptic language like "we only share data with our partners or with our other departments". "Informed consent" is such a commonly brought up phrase nowadays when it comes to sex. Shouldn't it be equally important for our data?

I look forward to hearing what other scenarios you can think of that require giving up our data, so that we may find a solution to it together.