Your support makes
all the difference!

We believe security software like Kicksecure needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 10 year success story and maybe DONATE!

Website Enhancements Planning

TODO: ADMIN - SOON[edit]

TODO: ADMIN - DELAYED[edit]

new thank you donation message[edit]

1) CORS issues are fixed now? (Patrick attempted to fix these.)

2) explain Patrick how to draft a HTML e-mail with text-only fallback in Thunderbird

3) Possible to have a plaintext fallback if HTML is disabled by the e-mail client?

4) e-mail for

Kicksecure
Whonix

5) bug?

This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.

https://developer.mozilla.org/docs/Web/HTML/Quirks_Mode_and_Standards_Mode

Valid HTML better / good idea for best e-mail reader compatibility?

DEV

How can I check CORS issues?
In thunderbird multipart email can be accomplised by going to "Options > Sending Format" and choose "Both HTML and Plain Text"
1. This Sending Format however only seems to take effect if the mail is truly sent. So saving it as a draft and then "saving as" .eml does work but does not create a multipart email
2. So maybe admin should send the email to his own email address and then save the .eml file
3. However this eml file needs to be modified for each recipient, so there needs to be more work done
4. May another mail software needs to be involved
The plaintext fallback is exactly what we want to accomplish with multipart
What is meant with task 4?
Maybe live discussion is needed

mediawiki-extensions-Purge[edit]

todo: discuss

What does https://github.com/AlPha5130/mediawiki-extensions-Purge/blob/master/resources/ext.purge.js (15 lines only) do?

Probably would have little effect for our wiki because of our custom skin? Does this functionality seem useful?

DEV

The development of this extension seems pretty interesting
The new extension (from pseudonym dev) is not much different from the original and seems to fix a faulty behavior of the original extension
Both versions consist of 2 parts: ext.purge.js and Hooks.php
- In Hooks.php in every page (without our skin) there is a link added to call the purge page (which is not part of the extension but of mediawiki itself)
- This is just a convenience shortcut, but useful - even for us. Because if a dev is already on the edit page then our purge via super menu is not available. Removing this extension however would not be a terrible loss but a small convenience downgrade
- In ext.purge.js the convenience is even more improved for Javascript users only. Because then the link does not open the purge-page but is stopped and instead the purge action is instantly performed without going to the purge page
Both versions are not perfect
- The original version fails to prevent the link to be augmented by Javascript. This might be due to it being loaded to early or other factors
- The newer version fixes this behavior but also prevents nojs users to use this button at all. It will be there but non-functional
Suggestion (in order of preferability from Dev's perspective)
1. However because it would be mainly for our convenience I suggest use the newer version
2. If not then use the older version
3. If not then write our own fork which would be the perfect solution
4. Another option would be to just add our own purge button via a simple Javascript file on pages that don't have the skin. That would also be a ONLY-JS solution but it would be a bit quicker than the "perfect fork" solution
5. If not then don't use at all, because we have instant access to purge via our skin

Patrick:

Do we even need the purge button still?
- Only for template changes?
- Otherwise cache invalidation is stable nowadays?
Weird anyhow that non-admins can clear cache.
MediaWiki's solution prevents crawlers from accidentally pressing that button.
noJS support not required.
- JS-only solution good enough.
Could we make it login-only or admin only?

add querystring to Headscript[edit]

purpose: invalidate browser cache on css changes

append querystring to our custom css/js
append to fontawesome etc too?
read version number from a local file in /srv/shared/cssversion/version-file
sanity tests
- check it is a real number
- check string length maximum
fall back to querystring=error if local file is missing or has invalid contents

how do we update the version number? options:

hardcoded in headscript
manually on file
manually in MediaWiki:cssversion
mw-combine can bump the version number but that might run too frequently (by the server, for testing, could be changed but non-ideal)
by Patrick writing a script that checks if contents of mw-autogen folder changed (counting all file names and hashing all files)

Alternative considered Cache-Control HTTP header stale-while-revalidate:

Would result in lots of If-None-Match requets and 304 responses.

Upgrade mw-multi-wiki - delete deleted files[edit]

DEV

I suggest upgrading mw-multi-wiki
Currently it is the case that files which are deleted are not updated during mw-multi-wiki deploy
This means that a dev would have to delete the other files manually and keep track somewhere which files to delete later
This is a problem because sometimes files should not be deleted before everything is finished and admin has approved development. And it also cannot be deleted before because then the wiki which is not updated yet would not function anymore
So I suggest admin upgrades the mw-multi-wiki script and checks for formerly Category:MultiWiki files that are now deleted and delete them too
Or maybe find another solution

Patrick:

How mw-multi-wiki could detect deleted files from Category:MwDeleteMe?
- Currently mw-multi-wiki uses MediaWiki API to look at https://www.kicksecure.com/wiki/Category:MultiWiki
- Once a page is deleted, it vanishes from the Category:MultiWiki page. Therefore mw-multi-wiki "forgets" about its existence.
A) mw-multi-wiki could be stateful and "remember" which pages were ever in mw-multi-wiki but that's ugly because then an idempotent, clean script would be dependent on remembering the state in some state file. The state would be difficult to share among developers.
B) A Category:MwDeleteMe could be invented. Delete all contents from the page and add that Category. Then mw-multi-wiki could remove it first from slave and eventually form the master wiki. Also non-ideal because not an intuitive process as it requires the developer to remember this because it's not a simple as using as using the wiki's internal deletion feature.
C) Deletion log https://www.kicksecure.com/wiki/Special:Log/delete doesn't contain categories.
- Parsing the deleted revision for Category:MultiWiki might be error prone (if a wiki page was MultiWiki in the past but then it was only a comment).

status:

Patrick asked on the MediaWiki mailing list. https://lists.wikimedia.org/hyperkitty/list/mediawiki-l@lists.wikimedia.org/thread/DIREH7YFVQPYHIJFFUXNBE6PVJ6OSMUX/

new idea: diff the categories in the different wikis

report only

Logos Misc TODO[edit]

TODO:

github sponsors credit card
Content in Kicksecure wiki and Whonix wiki
wiki text inconsistencies
- Chapter "Definitions" currently shows:
  - Logo - seems to unspecific
  - Landscape logo
  - Text logo
  - Icon logo
- Chapter "Current Kicksecure logos" uses a different language.
- Chapter "Current Whonix logos" uses a different language.
logo consistent naming
projectname-logo-definition
- example: kicksecure-logo-rectangular
- rename File, Special:ReplaceText to update old references

misc[edit]

MultiWiki: Think about PHP files[edit]

For the workflow it would be good to not only deploy the js and css files to the "slave" wikis, but also the php-scripts for combined and headscript content
Pro: if there are more than 2 wikis (which are not at the moment) then it's way easier to manage
Con: At the moment it's not necessary. And we would need to be very careful with who gets the rights

Stage Server as Master[edit]

MultiWiki feature requests:
- The idea is the separate MultiWiki files into "code" (js, css files) and "content" (content pages)
- pull code (CSS, JS, widgets) from Kicksecure stage server
  - How about templates such as Template:Header?
    - These need to be in a special category to be recognized as code?
stage server feature request:
- The stage server becomes the master server for code files. That way new scripts can be developed and tested on the stage server without disrupting the normal production use of the public wikis. Once a new feature is ready it can be multiwiki deployed from the stage server (master) to the slave wikis
For content pages the Kicksecure wiki might still be the master however

Newsletter Widget[edit]

Widget here means "widget" generally as in a box with a special feature.
- Not necessarily a MediaWiki widget.
- Is there a better terminology than widget to avoid confusion?
features:
- subscribe
- unsubscribe
- add the newsletter subscribe/unsubscribe to homepage
- the widget should be re-usable in other places in the wiki
- Ideally noJS compatible.
- Just two (subscribe/unsubscribe) POST submit boxes.
- The backend on the server could be a simple PHP script that just appends the e-mail address to a file subscribe.txt / unsubscribe.txt.
  - The PHP script should reject invalid e-mail address formats (such as with spaces in the middle or missing @ sign)
  - The PHP script would return "Success. Thanks for signing up!" or "Failure to sign-up. Please report this bug in the forums."
non-features:
- double opt-in (this will be done manually at a later stage before sending any e-mails)
TODO: discuss

DEV

Topic was discussed. Script should be simple and at best not using a database
Dev did newsletter research. Conclusions
- Most scripts are paid and proprietary, e. g. https://www.formget.com/newsletter-php-script/
- Most scripts are rather complex
- Most scripts use MySQL
Options
- We could write a completely new scripts
- We could base a widget on the research by admin: https://github.com/rodhilton/maillister (an old script)
- We could by a modern script and set it up with mysql
Admin said he will do script research again

FlaggedRevisions CacheClear Workaround[edit]

TODO

TODO DEV[edit]

video production - Hidden Text Attacks[edit]

Dev/videos

todo produce

Template:Flatpak_Install[edit]

Please port to using tab controller.

https://www.kicksecure.com/wiki/Template:Flatpak_Install

The A, B, C would be nicer if using tab controller.

Whonix homepage - Form elements do not have associated labels[edit]

https://pagespeed.web.dev/ shows some suggestions:

Form elements do not have associated label

Labels ensure that form controls are announced properly by assistive technologies, like screen readers. Learn more. https://dequeuniversity.com/rules/axe/4.4/label

Failing Elements

div.section-banner > div.inner-wrapper > div.overview-image-and-video-player > input#hide-overview-image
<input type="checkbox" id="hide-overview-image">

Patrick fixed a similar warning here: https://www.kicksecure.com/w/index.php?title=Widget%3ADonation_Panel&type=revision&diff=66939&oldid=58997
TODO: Only fix for our custom HTML/CSS/JS. We didn't invent many forms anyhow? homepage, about, donate
- Kicksecure
- Whonix

Heading elements are not in a sequentially-descending order[edit]

Heading elements are not in a sequentially-descending order
- Heading elements in order is a very impractical metric which probably very few websites adhere to. Headline levels are very rarely used structurally (exception example MediaWiki and similar), but often rather as style choices. Especially smaller headlines which are very rarely used anyways h4-h6 are often used exclusively as style elements. For our project that would be possible especially if it's limited to few sites. But it would mean changing HTML as well as CSS
- TODO: discuss

DEV

I would say this is very difficult because headlines are not only used by us but by mediawiki itself or extension in the "wrong order"

TODO:

write bug report draft for phabricator.wikimedia.org if issue can be reproduced on mediawiki.org (or wikipedia.org)
document this was discussed on dev/mediawiki

DEV

This "bug" is not due to mediawiki
As documented here this CAN be solved on our part https://vaihe.com/quick-seo-tips/tip-for-fixing-heading-elements-order/
However this might be time consuming to find ALL pages where the headlines are not in correct order
Maybe admin can create a list of pages that he really wants to be fixed in this regard (important pages). Then dev can fix those pages in a reasonable time frame.

Patrick:

no local fixes
important thing is only that upstream bug report exists or is going to be created

DEV

I mean that this might be "our fault"
So mediawiki might not have "bugs" in this regard, but it was just our practice before to use these headlines in the wrong context
So this is not a workaround, but just fixing our own code
So a bug report would not be justified

Patrick:

upstream https://m.mediawiki.org/wiki/MediaWiki has the same bug when testing with pagespeed insights

homepage html optimizations[edit]

For Kicksecure and Whonix homepage. To reduce DOM size.

Something doable, useful here?

Instead of using this code;

<div id = ”navigation-main”>

    <ul>

            etc ..

    </ul>

</div>

It would be better to use this other one;

<ul id = ”navigation-main”>

    etc ..

</ul>

Defer Upstream MediaWiki JavaScript[edit]

now:

<script async="" src="/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector"></script>

Patrick could server side easily rewrite that to:

<script defer src="/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector"></script>

(Nobody uses script async="" (not a syntax error - asked upstream). This is easily string replaced to script async using nginx.)

Progressive Web App PWA[edit]

resources:

You can find the site.webmanifest here:

mediawiki-customized-dist: public/favicons-kicksecure/site.webmanifest
mediawiki-customized-dist: public/favicons-whonix/site.webmanifest

todo:

do we need the extension or do we create our own
read https://web.dev/progressive-web-apps/
use Lighthouse (integrated in chromium developer console)
- Content is not sized correctly for the viewport

The viewport size of 396px does not match the window size of 360px.

If the width of your app's content doesn't match the width of the viewport, your app might not be optimized for mobile screens. Learn more. https://web.dev/content-width/

Manifest doesn't have a maskable icon

A maskable icon ensures that the image fills the entire shape without being letterboxed when installing the app on a device. Learn more. https://developer.chrome.com/docs/lighthouse/pwa/maskable-icon-audit/

critical css test[edit]

info:

https://web.dev/codelab-extract-and-inline-critical-css/

goals:

A simplified test if critical CSS inclusion into the head results in faster website speed at all.

non-goals:

Making mediawiki use critical CSS. How to integrate this with mediawiki will be considered at a later time in a separate task.

tools:

todo:

1) Use a browser where you are logged out and have no cookies. This is because cookies and being logged in has an influence on the HTML provided by mediawiki.
2) on /test/ add Kicksecure homepage with the normal HTML document that we have now: kicksecure-hp-normal-not-critical-css.html. This will be needed for speed comparison.
3) create a copy kicksecure-hp-critical-css.html
4) use some tool to extract the critical css. add the critical css to the head. (https://web-dev.imgix.net/image/admin/RVU3OphqtjlkrlAtKLEn.png)
5) out-comment all other CSS for a simple test. Search the HTML document for stylesheet. (CSS load with media="print" onload="this.media='all'" can and probably should be ignored and left enabled as it already loads async.)
6) load all other CSS async
7) compare speed of the two different HTML documents

Wiki Content[edit]

Whonix-Host[edit]

https://www.whonix.org/wiki/Whonix-Host

TODO:

improve introduction, consider using font awesome using widget:Icon_Bullet_List if sensible
How understandable is https://www.whonix.org/wiki/Whonix-Host#Terminology ? Please suggest improvements.
https://www.whonix.org/wiki/Whonix-Host improvements:
that page needs to be properly contextualized (Whonix-Host in development, volunteer help welcome, Whonix live available already anyhow)
goal of page: illustrate goal, ask for contributions (very much worthwhile. The current progress as of now is for large part based on contributions.)

Features[edit]

todo

general review
content improvement

soft todo:

note: Whonix wiki/Features nicely shows a table when googleing for "Whonix features"
- Therefore keep/improve "Whonix ™ Soft Features" table

DEV

irritating: The features listed here have other names and other profiles than the features listed on Homepage -> Somehow rename the page or chapter to make that better or other suggestions=
Anonymous Browsing and Anonymous Communications, Hosting and Publishing seem to be more like use cases than features -> OK.
Platform Flexibility
- What does "based on" have to do with flexibility? -> See chapter About#Based_on_Debian. In short: anything possible with the things its based on should work with Whonix too. No artificial restrictions or limitations which are often falsely assumed.
- What does "Free, Open Source, Libre, Freedom Software." have to do with flexibility? -> Customization is possible and relatively simple.
- What is "Virtual machine images with Type I or 2 hypervisors." ? -> https://www.techtarget.com/searchitoperations/tip/Whats-the-difference-between-Type-1-vs-Type-2-hypervisor Why is that mentioned? Shows that Whonix is flexible enough to be ported to different hypervisors.
Pre-installed software - why are there not all apps mentioned like on the homepage? -> Please update any missing ones. On wiki/Features it can be more use case based and more elaborated.
What is "torification" for the uninformed user? -> Torification means the process of routing traffic over Tor.
Security and Anonymity Protection: They are not real sentences. And it's highly technical. The reader does not know what is even meant by most of this -> True. Can be elaborated?
Tor Network / Torification
- The text consists of sentences but is a pretty cold start. "Most applications can be" - where in Whonix or elsewhere? What is Tor? -> ""Most applications can be" - applies anywhere. Outside and inside of Whonix. But in that chapter, it's probably best to talk about Whonix. If mentioning the outside Whonix use case, then that there is a much higher risk for leaks. Related to https://www.whonix.org/wiki/About#Security_by_Isolation
- "Both, pre-installed and custom installed applications can be use" - does this have anything to do with tor? -> Related to flexibility of Whonix. Some people assume only pre-installed applications can be used. This is false. Also most custom installed applications can be installed. That should me mentioned somehow.
- This whole chapter seems like a technical documentation, not like a promotion. -> Good if it's both?
Tunnel and Chaining Support: Very little explanation. Unintelligeble for non-technical users -> True. Please add more context.
Tunnel Other Anonymizing Networks: like Tunnel and Chaining Support
Tunnel Support: Very technical sentence and even more technical table
Whonix ™ Soft Features: Explanations are mid-technical and rather "lifeless" -> True.

Mobile_Phone_Security wiki page content enhancements[edit]

TODO:

read https://www.kicksecure.com/wiki/Mobile_Phone_Security
keep notes about the most shocking security and privacy issues, these will be needed for the summary chapter that is to be invented
summary: on the very top, add a new chapter "Summary", write a summary on top why securing a smartphone and not being spied on is doable in theory but in practice pretty much unfeasible for most users.
add a few more bulletpoints on the very top (currently there is only "Massive Data Harvesting by Most Phones." and "There are backdoors in most mobile devices."
add introduction chapter on the very top?
advice on a better page title as well as
- SEO description
- find/create better illustrative image
other content suggestions?

Whonix Homepage Image Fixes[edit]

any illustrative images looking non-ideal and should be replaced?

Kicksecure illustrative images[edit]

any illustrative images looking non-ideal and should be replaced?

illustrative images creation[edit]

Implementation probably needs discussion.

Hiding your identity is harder than just hiding your IP.
You can't be anonymous without being secure.
your Whonix with Tor versus your IP without Whonix
route randomization
Ask yourself - privacy by design / privacy by policy
freedom / freedom security / security
why security matters
why anonymity matters

WAITING ON[edit]

REVIEW PLEASE[edit]

Thumbnails improvement[edit]

Admin didn't like thumbnails "double border"
Maybe more slick design?

DEV

Minimal design was tried here: Testpage1
Maybe already a good solution?

check ticket[edit]

Please add role=button in Collapsible Elements to a.mw-collapsible-text - anything we should answer there?

DEV

Dev read the claims, did research and tested the suggestions
Below is the text Dev would suggest replying to the current threat (two answers currently). Copy from source code

In response to matmarex' reply we would agree that this is not technically a bug with Collapsible Elements regarding HTML validity. Also we support the role="none" solution. We tested this already and it worked.
We also agree with Izno that <button class="mw-collapsible-text">Expand</button> might be the better solution altogether. And CSS is already used to add the brackets before and after. So it would just be changing the CSS and not introducing more complexity by adding CSS where there was none before.
An [a] typically represents a link, a download or a jump label (with the name attribute before this solution was generally replaced by ids as jump labels). [a] is not designed to be used as an interactive element. So while syntactically correct and valid the use of [a] could be considered wrong here regarding context and use case.

FlyInNotification mobile small version[edit]

On mobile FINotification too big, fills screen
Mobile version please

DEV

Dev chose breakpoint at 550px screen width, because then the large version takes up half the screen
Then it breaks to smaller version which fills half the screen on 380px (our lowest supported screen width)
Dev could do more breakpoints but one seems enough
Dev also suggest not making the notification smaller because its purpose IS to get into the users field of view and be noticed

Total Blocking Time[edit]

Total Blocking Time went up on google pagespeed for mobile. Ideas why? Anything changed? Related to uglifyjs?

DEV

Research was conducted on possible issues
Source maps could not be found in research to cause performance issues
Then it was tried to change the use of source map via customized wiki. But "run-git-pull" failed with: Exit code: 128 output: ""
Admin please fix wiki pull

Patrick:

fixed (github changed SSH fingerprint)
use kicksecure.com/test for testing this?

DEV

Really hard to find out, because it seems kind of a black box
However: page map was not the problem. It was activated and deactivated without much difference
4 testing pages were compared and tested twice
- OLD: https://www.kicksecure.com/test/font-awesome-test-01-normal.html
- NEW: https://www.kicksecure.com/test/kicksecure-test_2023-03-28_homepage.html
- NEW_NoUserScripts: https://www.kicksecure.com/test/kicksecure-test_2023-03-28_homepage_without-scipts.html
- NEW_NoNewUserScripts: https://www.kicksecure.com/test/kicksecure-test_2023-03-28_homepage_without-new-scipts.html

Cat	OLD	NEW	NEW_NUS	NEW_NNUS
First Contentful Paint	1.6s / 1.7s	1.1s / 1.2s	1.1s / 1.2s	1.1s / 1.1s
Total Blocking Time	50ms / 70ms	370ms / 580ms	110ms / 220ms	370ms / 210ms
Speed Index	1.8s / 1.9s	1.9s / 1.9s	1.6s / 1.4s	1.7s / 1.5s
Largest Contentful Paint	3.3s / 3.4s	3.0s / 3.6s	3.4s / 3.7s	3.4s / 3.0s

- Analysis
  - It seems the only metric truly affected IS total blocking time, the rest is pretty much the same
  - It seems also obvious that the new scripts - prism and instant page - have a significant impact on TBT, but are NOT the only reason because without scripts (meaning also without combined.min.js) it's still not as fast as before
  - Dev did a diff of OLD and NEW and saw some differences and found that in flyinnotification the image should be decoding="async" loading="lazy" which was already fixed too but didn't change much for pagespeed
  - Dev also thinks it's possible that deferring Javascript leads to a worse TBT, because [Total blocking time] = [Time to interactive] minus [First contentful paint] → so the longer JS is deferred the longer it might take to reach time to interact. That is however just a speculation. This page here is a great overview over the topic https://www.fasterize.com/en/blog/understand-and-improve-the-time-to-interactive/ - not that this page states "It is important to specify that Time To Interactive is not a standardized indicator. It may therefore evolve. Note also that, although Google has included this metric in the calculation of the Lighthouse and PageSpeed Insights score, its weight has decreased during recent changes in the calculation of the score, to the point that it seems to be bound to disappear eventually."
  - Here is some more explanation for total blocking time and suggestions to improve and possible reasons why it might have increased in our development https://calibreapp.com/blog/total-blocking-time
- How to proceed
  - Dev suggests admin to define a course: Invest more time into improving this metric or waiting for this metric to phase out?
  - Because - this was not mentioned before - there were also tests done with gtmetrics which gave very good results and slightly worse results when the "connection" was heavily throttled, indicating that maybe only server speed or dome size could be improved

Patrick:

check with chromium 112 with built in lighthouse in chromium developer toolbar
Lighthouse 10 will be available in Chrome 112, currently scheduled for release on March 29, 2023.
also happens with mediawiki therefore probably a pagespeed bug or less likely a mediawiki issue

DONE / Log of DevSprint since 2021-12[edit]

2023-03-31
- FlyInNotification mobile small version
- Bug report answer Collapsible Elements
- Video Hidden Text Attacks production + title image
- Thumbs double border improvements

2023-03-29
- Video Hidden Text Attacks production

2023-03-28
- Whonix wiki/Linux content fix
- Pagespeed improvements
  - Headline research
  - Research “Links are not crawlable”
  - Total blocking time research and testing

2023-03-25
- Donate pages improvements text image design
- Content fix Whonix Linux installer page
- Discussion ToDo
- PayviaPaypal change amount on interval change
- "Time to Interactive" performance research
- Software pitch

2023-03-24
- PayViaPaypal upgrades usability, simple design
- FlyinNotification upgrades functionality, design, smallery file size
- Strategy discussion

2023-03-22
- mwcombine source maps + uglify syntax + documentation
- Discussion ToDo
- PayViaPaypal redesign (guardian) + cleanup

2023-03-21
- Video Kicksecure 001 script
- Cookie warning bug analysis
- Pagespeed optimizations
- mwcombine error output + add source map for custom js

2023-03-15
- Discussion Todo
- Image optimization SVG and hero + analysis
- Improved Whonix Linux installer page
- Repo web interface research

2023-03-14
- Instantpage documentation
- purge extension and fork analysis
- Donors page thumbnail
- multipart email thunderbird research
- Discussion instantpage and multipart email

2023-03-11
- Discussion Todo
- mw-combine upgrade feature justcopy + refactoring + documentation
- DonorCard.css upgrade + DonorTestpage link threshold correction (only s and higher examples)
- Integration and testing instantpage.js
- Headscript refactoring
- Thumbs design fix for gallery thumbs

2023-03-10
- Design fixed KS Trust page + Whonix HP
- Discussion ToDo
- BackToTopButton mobile fadeout
- Responsive Thumbnails + docu
- Source map research

2023-03-08
- Discussion Todo, DonorCard etc
- Donor cards feature + design upgrade + documentation update
- Donors and Testpage Donors texts
- Template intro thumbnail fixes + notpageimage research
- Content attribution, Design improvements
- Extension:Popup reference preview research and suggestions

2023-03-07
- Bugfix PayViaPayPal + upgrade design
- Research image thumb generation mediawiki
- Template:intro CSS Firefox fix + upgrade hidden thumbnail thumb parameter + documentation Dev/mediawiki#Intro_paragraph
- Donors Wiki page related tasks

2023-03-04
- Discussion ToDo
- new Template:DonorCard design + 5 levels and anon + Link feature and link indicator + documentation Dev/mediawiki#DonorCard
- new Testpage_Donors
- new Donors page
- Template:Intro visual improvements

2023-03-03
- Bugfix Kicksecure homepage overview-image
- Bugfix newline bug in HeaderMultiWiki
- Sitenotice close button upgrade optically and functionally
- Check image quality
- PagePreview / TextExtracts bugfix on some pages
- Template:intro upgrade + documentation
- Fontawesome preloading
- Donor Page card design

2023-03-01
- Banner bigger close + cookie bugfix
- Discussion CSS optimization and CSS extension
- Banner rewrite with new method and documentation
- Multiwiki deploy and testing

2023-02-28
- Image optimization + metatag Research + new helper program
- Codeselect upgrade optional img lazy load + docu
- extension:pagePreviews broken fixes
- intro template and css upgrade

2023-02-27
- Discussion ToDo
- ShareTooltip regexp-bugfix + new mediawiki share logo
- Textextracts extension research
- Footer fixing
- Reduce warnings of w3c validator
- Banner slim variants
- short debugging discussion mw-combine error

2023-02-22
- Bugfix for mobile back button broken
- Bugfix fors Anchors missing
- Discussion Todo
- Fixed Kicksecure Badge svg file
- Banner dev wanted for Kicksecure was created
- New banners were uploaded and installed

2023-02-15
- Creation of 5 banners
- Discussion donor recognition

2023-02-14
- MiniModal upgrade all modals close on back button + documentation
- MwCombineWrapper refactoring
- Whonix Kicksecure HP minor fixes
- optimized SVG versions for some logo images
- coming soon sign

2023-02-13
- Discussion ToDo
- PageHomepage
  - Modals share anchors introduced
  - Text can now again be marked and individually copied
  - Highlighting of selected card via url hash + extending hidden areas if needed + open modal if available + back button can be used to return from modal
  - CSS reduction + Firefox fixes
  - MiniModal upgrades + documentation Dev/mediawiki#Mini_Modal

2023-02-06
- Discussion ToDo
- CodeSelect highlight language extension variable externalization
- Minify JS-HTML suggestion
- mw-combine sanity test and conditional folder creation for src-copy + documentation
- forums year end banner repair
- Page editing via header super menu oldid fix
- Removed nojs.css mentions and updated documentation
- fonts.css relevance checked and deleted on all wikis
- multi-wiki-deploy, tests and small bugfixes

2023-02-04
- CodeSelect Highlight upgrades: less code, better usage, bugfix + documentation
- Optimization mw-combine: better naming, spacing, formatting, usage

2023-02-03
- Discussion Todo highlight / prism, discussion strategy
- Replaced highlight-js with prism-js for CodeSelect + new tests on Testpage + feature target highlight + prevent highlight for CodeSelect icon form for speed optimization
- Nojs.css deleted and purged from build.json + styles moved to other style files (closer to nojs styles
- mw-combine improved: folder sanity check, array check for build.json categories

2023-02-02
- Discussion Todo
- Research highlight js libs, removed Highligh extension, installation of highlight.js
- CodeSelect integration of deferred highlight.js + new Feature "lang" to control highlight language or set to auto / none
- CodeSelect examples were created Testpage1
- CodeSelect documentation was updated Dev/mediawiki#CodeSelect

Footnotes[edit]

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

Kicksecure ™ A secure by default operating system with the latest security research in place.

Donate

FREE · PLUS · PREMIUM Support

Dark mode

At Kicksecure we believe in freedom and trust. That's why we fully support Open Source and Freedom Software.

Kicksecure ™ is supported by Evolution Host DDoS Protected VPS.

The personal opinions of moderators or contributors to the Kicksecure ™ project do not represent the project as a whole. By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service , Privacy Policy , Cookie Policy , E-Sign Consent , DMCA , Imprint Kicksecure

ENCRYPTED SUPPORT LP, 2023

ToDo for Kicksecure ™ Wiki Devs

Your support makes
all the difference!

Contents

TODO: ADMIN - SOON[edit]

TODO: ADMIN - DELAYED[edit]

new thank you donation message[edit]

mediawiki-extensions-Purge[edit]

add querystring to Headscript[edit]

Upgrade mw-multi-wiki - delete deleted files[edit]

Logos Misc TODO[edit]

misc[edit]

MultiWiki: Think about PHP files[edit]

Stage Server as Master[edit]

Newsletter Widget[edit]

FlaggedRevisions CacheClear Workaround[edit]

TODO DEV[edit]

video production - Hidden Text Attacks[edit]

Template:Flatpak_Install[edit]

Whonix homepage - Form elements do not have associated labels[edit]

Heading elements are not in a sequentially-descending order[edit]

homepage html optimizations[edit]

Defer Upstream MediaWiki JavaScript[edit]

Progressive Web App PWA[edit]

critical css test[edit]

Wiki Content[edit]

Whonix-Host[edit]

Features[edit]

Mobile_Phone_Security wiki page content enhancements[edit]

Whonix Homepage Image Fixes[edit]

Kicksecure illustrative images[edit]

illustrative images creation[edit]

WAITING ON[edit]

REVIEW PLEASE[edit]

Thumbnails improvement[edit]

check ticket[edit]

FlyInNotification mobile small version[edit]

Total Blocking Time[edit]

DONE / Log of DevSprint since 2021-12[edit]

Footnotes[edit]

Navigation menu

ToDo for Kicksecure ™ Wiki Devs

Your support makesall the difference!

TODO: ADMIN - SOON[edit]

TODO: ADMIN - DELAYED[edit]

new thank you donation message[edit]

mediawiki-extensions-Purge[edit]

add querystring to Headscript[edit]

Upgrade mw-multi-wiki - delete deleted files[edit]

Logos Misc TODO[edit]

misc[edit]

MultiWiki: Think about PHP files[edit]

Stage Server as Master[edit]

Newsletter Widget[edit]

FlaggedRevisions CacheClear Workaround[edit]

TODO DEV[edit]

video production - Hidden Text Attacks[edit]

Template:Flatpak_Install[edit]

Whonix homepage - Form elements do not have associated labels[edit]

Heading elements are not in a sequentially-descending order[edit]

homepage html optimizations[edit]

Defer Upstream MediaWiki JavaScript[edit]

Progressive Web App PWA[edit]

critical css test[edit]

Wiki Content[edit]

Whonix-Host[edit]

Features[edit]

Mobile_Phone_Security wiki page content enhancements[edit]

Whonix Homepage Image Fixes[edit]

Kicksecure illustrative images[edit]

illustrative images creation[edit]

WAITING ON[edit]

REVIEW PLEASE[edit]

Thumbnails improvement[edit]

check ticket[edit]

FlyInNotification mobile small version[edit]

Total Blocking Time[edit]

DONE / Log of DevSprint since 2021-12[edit]

Footnotes[edit]

Donate

Navigation menu

Search

Your support makes
all the difference!