"Install through npm"
"Install through gulp"
"Install through compiling"
"Install through x"
"Install through y"

WHY CAN'T I JUST SIMPLY INCLUDE THE MOTHERFUCKING THING IN THE HTML LIKE A FUCKING NORMAL PERSON?!

ALL I WANT IS TO INCLUDE A GODDAMN UI FRAMEWORK.

When I just started web development, this stuff was so fucking easy! Why did it become so motherfucking complicated to include simple shit like this?!

All I want is to start programing this motherfucker, not spend 3 hours on compiling CSS and whatnot (because I'd have to learn this bullshit first).

Mother of god, why did this become so fucking obnoxious?

I. JUST. WANT. TO. INCLUDE. TWO. FUCKING. FILES.

I mean you can, but then you're reliant on html for controlling the load order and initialization, and load order compat between different module strategies, so it's pick your poison.

Alright, I've been where you are right now, so trust me on this. You're gonna want to install it through npm or whatever into your project and import it into your main js file and use webpack. Use Laravel Mix to for easy setup of the whole shazam (also useable without using laravel, it just simplifies shit if you want). You'll then end up with one output javascript file, minified and all, to include in the html. It's much easier than fucking around with multiple script tags and shit, I swear.

Also what framework are you using?

@epse Thanks! Although, I just managed to find the main minified CSS and JS files and it works great now!

And as for the framework, working on my own so no need for laravel!

Thanks anyways!

Use vue, they provide a cdn

@yellow-dog I'm going with a simple ui framework, not something like Vue (I know it). I also don't want to be reliant on a CDN so putting everything on my own server :)

@linuxxx that's why I said laravel-mix can be used without laravel. It's badly named, really, it's essentially a set of pre-configured webpack settings. Power to you though, you're learning!

@molaram
That's only true in the UK.

Also, I have a UK dev shop.

These things are not unrelated.

@molaram
I pay above market and we don't do overtime. It's your pond, I just take advantage of your absence of wage disparity 😘

@epse Thanks for the info!

Right now I'm suck with CSS/ui stuff I don't understand so that's great 😅

@linuxxx As a good rule of thumb, avoid anything that forces you to use npm

@molaram
I go to local user group meetings, enjoy free alcohol and network.

I also located in Scotland, the London market is hella saturated by shit web shop doing noob crud apps mon-fri.

@molaram
I market primarily to US companies and bring dev jobs to UK. That combination has several advantages:

1. All my software is an export, so I don't pay vat on anything
2. Local and national governments spray money at companies to locate foreign jobs in the UK
3. Easy immigration visas on the cheap 💷💷💷💷💷💷💷

@molaram She does - I mean, UK... *cover and hide*

@molaram
A number of reasons:

1. Western languages, I only speak English and Spanish with any degree of fluency. Training people is exponentially more difficult with a language barrier and I have to train wherever I go.
2. I don't like the sun, so that leaves Spain and Italy firmly out of the question (Italian is close enough to get by)
3. Not being a euro, Britain is easier to do business in
4. Scotland is safer than Poland, Belarus, etc
5. Our offices are Seattle, Tokyo and Edinburgh. They're all exactly 9 hours of flying time disparate. That means I can always head West while traveling and never endure jetlag or a 14-18 hour flight with multiple layovers.

@molaram
I get along with everybody.

@SortOfTested I was in Edinburgh seven years ago while on holiday in Scotland. Actually Aberdeen based. Had a printed sign taped into the rear window of my rented car: "Danger! Continental driver!" ^^

@Fast-Nop
They know what's up! Can't trust those Germans with their rigorous standards for licensing and guaranteed basic mechanical skills. What would happen if someone were to cut a Glaswegian left in front of them 😝

@SortOfTested Yeah Europe could be so well off with German mechanics, British sense of humor, Swiss banks, Italian lovers and French cuisine. Instead, it's heading for Italian banks, German sense of humor, British cuisine, Swiss lovers and French mechanics. ^^

@Fast-Nop
And now you know why I spend 2/3rds of my time in Seattle and Japan 😉

@linuxxx When I needed some website a few years ago, I found WP too complex of a tech stack (and I didn't even know how much it sucks), and I found even the SSGs around were too complicated so that I ended up writing my own toolchain.

@Fast-Nop Slightly the same except that I did solely backend wise. (Not sure if you did that as well).

I now have a framework I can easily use for REST API's and that's all I need really! I hardly ever do the frontend of a project.

@linuxxx I found that I could go static and eliminate any backend in that project - unless Apache and some htaccess hackery would count. Fast as hell, even tolerably usable at 56k, and no security update hassle.

@Fast-Nop Good for you! 90 percent of my projects contain backend functionality so I can't do that but hey, trying to keep it as simple as I can!

Did you try using vanilla HTML5 with static CSS and no JavaScript?
HTML is easy to generate in the backend and most of the time vanilla form elements with some CSS are good enough to do the job.
You also get a pretty accessible site wich doesn't require JavaScript as a bonus...

@Oktokolo While I agree, I can't do browser crypto without JS!

@linuxxx
If the user trusts your site, use TLS with a pinned cert.
If he does not, why should he trust your JS?

@Oktokolo Nobody uses certificate pinning because if anything goes wrong, you can just trash the domain.

@Fast-Nop
Well, then just don't pin the cert - trading some security for convenience (wich may or may not be fine depending on the threat model).
The point is, that the TLS connection, over wich the JS is delivered is defining the lower bound of the security of the whole site anyway.
If someone doesn't trust that TLS connection, he logically doesn't trust the delivered JS either.
If he doesn't trust the JS wich does the crypro, then he doesn't trust the crypto.
Doing untrusted crypto is pointless.

There's nothing stopping you from making websites like it's still the 90's.

My dad's website is still handcoded HTML3 with tables for layout, a few gifs for icons, a bunch of blockquotes and centers and a marquee element and underlined blue-as-fuck hyperlinks. To show the route to his business, he drew an arrow with a sharpie on a physical map, and scanned it.

His website maintenance is pretty simple, he writes articles just directly in HTML with some <h1-6> and <p> elements.

HTML3 is super deprecated, but it still works on every device, in every browser.

It loads in a few milliseconds.

Why fix what ain't broken 🤷‍♂

@Oktokolo How on earth would I perform client side symmetric crypto without JS?!

@linuxxx
Wasm

@bittersweet You can even do that in HTML5 and use proper hand-written CSS for layout. That's still fast, but also responsive and accessible.

Shh. Just accept it. It makes your life easier. Trust me. I always thought the same (especially back in the days when I was really active on devrant) but PMs and stuff are really worth a try. So is gulp & co.

@linuxxx
In the browser? Just don't!

@Oktokolo There might be a use case if the point isn't securing the transmission (where TLS is better anyway), but to make sure that the server cannot see the decrypted data, e.g. in case of a server breach. That's only possible if the encryption is done client-side.

@Oktokolo where should he do it then?

@Fast-Nop end-to-end has to be done in the browser as well.

@Fast-Nop
In case of a server breach, the server-delivered JS isn't trusted anymore. Using server-delivered JS to do crypto is therefore just a waste of developer time.

@Oktokolo It's about the data that already exist on the server.

@Oktokolo Riiiight, so then how'd I enable end to end encryption in the browser?

@Oktokolo And if your last comment would be valid, protonmail, tutanota, wire, wickr and alll the other web apps with built-in (and in some cases also pentested and peer-reviewed and approved) end to end encryption would all be fucked.

@dsteiner Also, hey man! How are you doing? Long time no speak :)

@dsteiner
If he wants to protect data from the server, he obviously(!) needs to do it without depending on anything, wich is automatically updated from the very same server on use.
An independent stand-alone phone or desktop app could do it.

@Oktokolo The JS doesn't have to be on the same server as the data.

@linuxxx I’ve been doing quite well actually. I worked in two fucked up companies in 2019 but started at the biggest rescue coordination center in July and its really great here. Private projects are going well as well - learned much about docker, angular, java and other stuff here.

How are you doing?

@Oktokolo This is not about protecting data from the server.

I just don't want to be able to see the data in plaintext because..... its none of my goddamn business (zero knowledge, anyone?).

@dsteiner Damn, sounds good man! What IM capabilities do you have by now, if I may ask?

@linuxxx
You are still able to see the data in plaintext - in your JS. Code you deliver to a browser is still code under your control. Conceptually, there is no difference between the server code seeing it and the code just delivered by the server to a browser seeing it.

The future is now old man

@linuxxx slack, telegram, signal. Discord, kik.

@Oktokolo Oh yes there is. A client can do whatever they want, on the server I'm the boss.

@dsteiner You're on goddamn signal?!

Web development is cancer and web decelopers are patients.

📌

@Wombat Best comment in this thread

Amen brother.. amen. Couldn't have said it better myself.

@linuxxx
There isn't in the context of data visibility. That you can't trust the results of your code executed in the client browser, does not imply that the client can trust end-to-end-encryption performed by that code.
Security-wise you get the worst of two worlds: Neither the server, nor the client can trust that code for end-to-end encryption (and if it is not end-to-end, it just is redundant to TLS anyway).

@Oktokolo The "fun" thing about this is that next to being a back end programmer (studied software development), I'm a cybersecurity engineer as for my job right now and I genuinely don't get what you're saying, could you rephrase your last comment?

I really want to understand because as far as I can see, I'm writing this in a good way.

@linuxxx
Your goal seems to be to hide data from the server by encrypting it on the client using code wich is loaded from the server.
Code loaded from a server should not be trusted by the client for hiding information from that server.
The trust model does not differ from not encrypting that data. The client does not get any additional security guarantee. So from its point of view, the additional layer of encryption does not change anything.

In theory, users could audit the delivered JS. And then they would get that additional security guarantee. But in practice, nobody does that and companies have gotten away with the worst of security incidents in the past without taking any damage.
So (in practice) the potential discoverability isn't worth consideration.
You end up with a layer of encryption, the client should not trust.

@Oktokolo I could load the JavaScript from another one of my servers as well but that's not the point.

While I get your point more, now, i still disagree.

If this would be a high security project, I'd definitely agree. But this is not the case. Every additional security/privacy consideration is adding a little bit to the overall security/privacy. The generated keys are long numeric strings which would take a trillion+ years to brute force, while keeping it user friendly. And then, I'm not going against APT's, this is just a simple tool.

The code being open source does definitely make a difference. Even if nobody looks through the code, if the ability isn't there at all, then you'd get a black box delivered, in some way.

I think that the only improvement I could make would be loading the JavaScript library from a different server which I could do in like a minute or so (I'd want the server to be in my control but I've got many servers so that isn't an issue). Except for that (and I've ran this by multiple security people), this level of added crypto definitely adds to the security/privacy of the application.

The idea seems to be that if the server is hacked, the attackers could also alter the JS code to transmit the keys in cleartext and then decipher the data on the server.

Even putting the script on another server wouldn't help because if they have the first server that delivers the HTML, they could just let it point to their modified version of the script.

But first, it's much more work for the attackers than just hacking in and copying off the data. More work for the attackers means more security because it raises the bar. Once it is too expensive for the attackers vs. the value of the data, attackers will not do this. There is no absolute security, you have to consider the threat model.

Second, it gets elegantly around the whole question whether the GDPR is applicable for data in backups. The user has gone and deleted the key? Yeah the data are still in the backups, but not accessible to anyone.

@Fast-Nop Fair points! The one good thing here is that this server is built around the idea of discardability. Data is automatically removed after x time of inactivity and I literally don't save anything more than unique URL identifier, last seen time (for the automatic removal after x time) and the data being synced (random server side generated identifier and client side encrypted other data string).

Also, I don't keep backups of this data.

@molaram Amen. I have a million reasons to look for another job but that shit just turns me off of larger companies time and again.

@epse

Thanks for meitioning this I am trying to set up a simple webpack project right now and having issues.

Waiting for somebody to go in depth with these comments and arrange them into a book with technical examples. Growing popcorn in the meantime.

@cprn its just called corn at this point!

@Wisecrack Nah, it's a specific specie of corn called popcorn.

@cprn I never knew that popcorn was grown from a specific kind of corn.

Does it *have* to be that kind of corn? Can other kinds of corn be used?

@Wisecrack No idea 🤷‍♂️ but I'm pretty sure I'll date a farm girl sooner or later... so I'll let you know after. 🌽

@Wisecrack yes and no. Regular corn does not have the required amount of water in the corn when dry and would just burn.