Closed aschrijver closed 3 years ago
Without Javascript won't be possible right now, because the Website uses Docsify.js which uses Javascript.
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
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.
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 😊
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
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.
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.
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 😃
Btw in my fork is an optional cookie, because of my noobie JavaScript skills. The average user won't get this cookie.
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...".
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
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!
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 😊
Everything removed except JavaScript which isn't possible at the moment. Thanks for the advice, @aschrijver !
Thank you for considering these improvements :)
PS. There's one tracker still present, atm: Google Fonts (fonts.googleapis.com)
Yes, there is a problem with the script which updates everything
it would work if @adeekshith would remove the protection for the github-pages branch if possible
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.
Ok I am not that familiar with protected branches. If that won't work, the script could create a new branch and a pr
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.
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
It runs every two hrs?! My fault, I wanted to set it for every week!
I need to have a look how an action create a pr
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*_*_*
But still wrong...
@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?
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!
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.