adeekshith / watomatic

Auto reply app to enable auto reply for messengers like WhatsApp and Facebook Messenger
https://watomatic.app
GNU General Public License v3.0
444 stars 87 forks source link

Make website tracker-free (and maybe no-JS) #167

Closed aschrijver closed 3 years ago

aschrijver commented 3 years ago

The website has 3 trackers. It would be a great boon to get rid of them, and it can be easily done.

Now you use scripts to have an easy Markdown2Html translation. But if you'd choose a basic Jekyll theme, all you'd have was plain old HTML generated once by Github after committing a change (instead of dynamically each time someone views your page).

AND.. now your site is no-cookies, no-javascript. A gem, simply put.

You might consider the latter, because your most dedicated fans in terms of contributions, donations and advocacy are in the privacy-minded folks, FOSS world and on the Fediverse, where they really value these things.

mawoka-myblock commented 3 years ago

Without Javascript won't be possible right now, because the Website uses Docsify.js which uses Javascript.

adeekshith commented 3 years ago

Avoid the jsdelivr CDN and self-host the scripts you include.

This slipped through my radar. Wonder what I was using jsdelivr for. Will check back when I have my laptop with me tomorrow.

Dunno, but it seems there's no need for a Google Play cookie to be present.

I see no need for a cookie either. Will check if we can avoid using local source for images. @mawoka-myblock might know Google badge rules better

mawoka-myblock commented 3 years ago

At first: docsify uses Jsdelivr, over a http connection and Google Fonts. I removed that with some other tweaks in my fork. I couldn't find a Google play 🍪 when I tested everything out.

adeekshith commented 3 years ago

Currently we are using JS (docsify) to render markdown pages for these reasons:

Not necessarily a fan of Docsify but just used as it worked.

I prefer CDNs over self hosting in public projects like this so they are upto date without us updating anything from our end. Basically low maintenance. Outdated libraries cause more harm to users than CDNs. That said, need to switch to CDNs that are privacy friendly.

Above are the reasons why I picked JS rendered Markdown solution but I am personally not a fan of it either. Website has been relatively low priority compared to the app so didn't bother much about it 😊

adeekshith commented 3 years ago

docsify uses Jsdelivr, over a http connection and Google Fonts. I removed that with some other tweaks in my fork.

👏👏👏😃 Great job @mawoka-myblock I think we should also submit a patch to Docsify so they don't use HTTP

mawoka-myblock commented 3 years ago

Idk why but in html it was the following: <script src="//CDN.js..." ></> which resulted in a http request. What I want to say is that you would have to edit the whole docs of docsify to make it HTTPS.

mawoka-myblock commented 3 years ago

With the cdn-thing: we could create a GitHub action which automatically updates the script from Jsdelivr and saves it locally. I'll do that asap.

adeekshith commented 3 years ago

Which the cdn-thing: we could create a GitHub action which automatically updates the script from Jsdelivr and saves it locally. I'll do that asap.

Awesome! Thanks @mawoka-myblock 😃

mawoka-myblock commented 3 years ago

Btw in my fork is an optional cookie, because of my noobie JavaScript skills. The average user won't get this cookie.

aschrijver commented 3 years ago

Nice to see you are making improvements. Thank you :pray:

Currently we are using JS (docsify) to render markdown pages for free reasons.

Jekyll and other static site generators also use markdown, and after the PR (which you still require) Github Pages will do an auto-build and deploy without any user interaction required.

The features of Docsify confuse me, because they seem anti-features:

With Docsify and JS disabled the entire site is a blank screen that just says "Loading...".

mawoka-myblock commented 3 years ago

Nice to see you are making improvements. Thank you

Currently we are using JS (docsify) to render markdown pages for free reasons.

Jekyll and other static site generators also use markdown, and after the PR (which you still require) Github Pages will do an auto-build and deploy without any user interaction required.

The features of Docsify confuse me, because they seem anti-features:

  • Static site generator: One-time compile + deploy auto-triggered by commit/PR, static HTML, no JS required.
  • Docsify: Every page is compiled client-side over and over again on each and every request.

With Docsify and JS disabled the entire site is a blank screen that just says "Loading...".

I know that! I would also prefer something else but @adeekshith wants Docsify

mawoka-myblock commented 3 years ago

With the cdn-thing: we could create a GitHub action which automatically updates the script from Jsdelivr and saves it locally. I'll do that asap.

Done with that!

adeekshith commented 3 years ago

Jekyll and other static site generators also use markdown, and after the PR (which you still require) Github Pages will do an auto-build and deploy without any user interaction required.

Oh I need to check how Jekyll works with GitHub. I thought we need to compile ourselves or use GitHub actions like thing to deploy Jekyll sites. I'll take a look. Thanks for clarifying it @aschrijver 😊

mawoka-myblock commented 3 years ago

Everything removed except JavaScript which isn't possible at the moment. Thanks for the advice, @aschrijver !

aschrijver commented 3 years ago

Thank you for considering these improvements :)

PS. There's one tracker still present, atm: Google Fonts (fonts.googleapis.com)

mawoka-myblock commented 3 years ago

Yes, there is a problem with the script which updates everything

mawoka-myblock commented 3 years ago

it would work if @adeekshith would remove the protection for the github-pages branch if possible

adeekshith commented 3 years ago

it would work if @adeekshith would remove the protection for the github-pages branch if possible

Oh removing branch protection totally is not safe as any contributor including myself can accidentally push to it without a PR. Will see if I can exclude Github Actions from branch protection.

mawoka-myblock commented 3 years ago

Ok I am not that familiar with protected branches. If that won't work, the script could create a new branch and a pr

adeekshith commented 3 years ago

Avoid the jsdelivr CDN and self-host the scripts you include

@aschrijver Is there anything specifically wrong with jsdelivr CDN or do you just mean not to use a CDN?

IMO if the CDN is good enough privacy wise, there is not much we are gaining by self hosting.

Advantages of CDNs:

But that said, I like your idea of using Jekyll if Github already deploys it without us setting up a CICD pipeline 😊. Will explore that in coming weeks.

adeekshith commented 3 years ago

Ok I am not that familiar with protected branches. If that won't work, the script could create a new branch and a pr

Yayy! Thats good. Making it create a PR should fix the issue. We can also make it run it once a day instead of once every 2 hours. Thanks @mawoka-myblock

mawoka-myblock commented 3 years ago

It runs every two hrs?! My fault, I wanted to set it for every week!

mawoka-myblock commented 3 years ago

I need to have a look how an action create a pr

adeekshith commented 3 years ago

It runs every two hrs?! My fault, I wanted to set it for every week!

Oh no probs. Yeah once a week should be good.

I just saw this line on cron: "0 2 * * *" and thought it is once every two hours. My mistake. It is daily at 2am :) https://crontab.guru/#02*_*_*

mawoka-myblock commented 3 years ago

But still wrong...

aschrijver commented 3 years ago

@aschrijver Is there anything specifically wrong with jsdelivr CDN or do you just mean not to use a CDN?

CDN's are often used to save bandwidth and data transfer when self-hosting a site. On busy sites this can save you money. Using GH Pages is an argument for self-hosting the script too.

The fact that EFF Privacy Badger marks this CDN as a tracker means it has been found to track cross-site browsing behavior. In theory a CDN provider can be ethical and proper, but they pay for that service and that usually means they want something in return (i.e. you are the product).

By self hosting scripts, we are polluting our git history with minified Javascript files

That is only on your gh-pages branch. Plus there isn't a lot of JS or the need to frequently update it, right?

adeekshith commented 3 years ago

The fact that EFF Privacy Badger marks this CDN as a tracker means it has been found to track cross-site browsing behavior.

Oh that is not acceptable. Thanks for pointing this out.

That is only on your gh-pages branch. Plus there isn't a lot of JS or the need to frequently update it, right?

That is true. I am just a Git purist and this irks me a little 😄. But I agree this is a reasonable compromise for now.

In the near future, will explore Jekyll or something similar.

Thanks a lot for your time and insights @aschrijver . That really helped!