(1) I run my own web server. I am not just an "user". I already have expenses! So, if I don't want to support https, then it is that way.
(2) My web site is not a commerce site, it's a personal use site. Why do I have to enable https?
See?
I don't need to support https. For my needs, http, ftp, ssh and SMTP/POP are sufficient. If I want encryption, I can implement my own ( end to end ) with a key. It will (is) far more secure than anything Google and the Gov can ever deliver. Why should I give a hoot about Google and the World telling my how to run my business?
I don't have an issue just trying to avoid the op having issues with his first speaker design software.
I do have an issue with this statement though. It might have become a good program if had been completed rather than abandoned. It has significant issues with entering parameters which can be confusing for newbies that don't understand the maths and more seriously the internal working parameters can become incorrect when parameters are modified.
It can make sense for people that learnt years ago how to deal with these issues to keep using it but it makes little sense today for someone new to speaker design to learn how to get round these issues given the existence of several programs that are more reliable, have more features, are designed to run on current versions of operating systems and are supported.
I already mentioned two reasons why. So unless you're happy having your visitors become unwitting participants in a DDOS attack, you should enable HTTPS. Fortunately, since almost all sites enable HTTPS now, that sort of attack doesn't work well anymore, so you are benefitting from a sort of herd immunity even though you don't want to contriibute yourself.
Sorry, but I most certainly don't agree with this.
In VituixCAD it's not possible to (quickly) compare multiple drivers or sets of different parameters for example.
Also comparing those with some additional EQ settings doesn't work great with VituixCAD's user interface.
Even the T/S parameter section is already multi menu's deep.
Btw, get the older 0.50a7 version, NOT the newer versions.
The newer version contain some major bugs in the EQ section.
Especially the Linkwitz Transform EQ is completely wrong.
You don't. The only reason you'd want to enable HTTPS would be to avoid the "this site is unsafe" prompt or to rank higher on Google. But if you run your own personal server you don't care about either so I'm not sure why you feel you have to enable HTTPS. I certainly don't understand your comments about the nanny state or government involvement.
I have several network appliances in my home network that give me the same warning. And, no. I'm not going to implement HTTPS on my firewall or file server. I'll just click, "yes, proceed to the 'unsafe' site". If I recall correctly, I can add the server IP addresses to a configuration file and declare them safe that way. I just haven't bothered.
Tom
HTTPS enables end to end encryption of the traffic between bowser and server. So you're not solely reliant on whatever encryption is being used by your network provider.
It's not a panacea, but it does provide another level of protection.
Remember, even if the site you're using is safe there's no guarantee that any of the various network hosts between you and a public server are safe.
Certificates are a way to ensure that the site you're talking to is actually that site and not something trying to spoof it.
HTTPS and certificates weren't invented for the sake of it. They're responses to more than two decades of criminals and governments trying and using our internet activity to spy, impersonate and steal identity and money.
DING! DING! DING!
I wholeheartedly agree. No encryption scheme will be perfect or flawless, but having a reasonably high confidence that the website you're about to give your credit card information to is legit has value.
I'm surprised when I come across sites that don't enforce HTTPS. As I pointed out earlier; implementing it is a simple one-click process on most (all?) web hosts. Even the cheap ones. There's just no excuse anymore.
Tom
The safest encryption is when you and your user shared a unique key. We don't need no stinking certificates, see?
What you do is to implement a UDP based network layer with build in encryption. Then you and your users share a key, nobody knows about it.
True, I sound like a mechanic and his own car, but this is my business after all.
And, Tom, I also run an Apache intranet server in my home LAN. It doesn't run https either. It sort of backs up the Internet server, which is hosted by a 3rd party since it makes my life easier.
There is a firewall between my intranet and the Internet. My wired devices all use static IP addresses, my wireless devices use dynamic IP addresses. There is a MAC list on the wireless access points as well.
Oh, I got two access points to cover the same house... same SSIDs but very different channels. At different ends of the house. A roaming network I designed before people knew what roaming and mesh networks were.
But I digress. My speakers and amps don't need no encryption!
What you do is to implement a UDP based network layer with build in encryption. Then you and your users share a key, nobody knows about it.
True, I sound like a mechanic and his own car, but this is my business after all.
And, Tom, I also run an Apache intranet server in my home LAN. It doesn't run https either. It sort of backs up the Internet server, which is hosted by a 3rd party since it makes my life easier.
There is a firewall between my intranet and the Internet. My wired devices all use static IP addresses, my wireless devices use dynamic IP addresses. There is a MAC list on the wireless access points as well.
Oh, I got two access points to cover the same house... same SSIDs but very different channels. At different ends of the house. A roaming network I designed before people knew what roaming and mesh networks were.
But I digress. My speakers and amps don't need no encryption!
Creditcard
Credit card information should be handled by the payment provider, who must initiate a dedicated secure connection for the purpose.
Which is what Https and certificates are about. Key exchange and encryption done in a manner where both parties can have some confidence in the quality/security of the connection.
How you manage your site is up to you, and I don't think anyone's criticising your site specifically.
But if I do a Google search and get a link to a site I've never used before and it's not got a certificate or won't do Https I consider it a red flag and try to research the site before proceeding. Or not.
If my anti-virus software gripes about a link I can ignore it or whitelist the domain. But I always check to find out a LOT more before I go to the site.
The majority of people on the internet aren't experienced or knowledgeable and in part Https and certificates are a safety net to protect them (and us) from themselves. For most, the internet is an appliance.
"For most, the internet is an appliance."
For me it has paid the bills for years.
Check out AFDX... a crazy design for avionics.
BTW, the encryption I'm referring to is far more safe. You generate the key, send it to other side and establish a unique point to point for each connection. Nobody else even knows about it. Nobody else even knows it exists or what kind of encryption you might be using.
It works very well but the self proclaimed "Internet Governing Bodies" ( an oxymoron ) think they know better... and my design is peer to peer, meaning not centralized. It can be easily done as an "appliance" but then the Controllers Of The Internet (think political) won't have any say on it.
For online credit card and money transactions, I normally use Paypal with a dedicated credit card and bank account. I do use the CC directly for Amazon and some sites like DIYAudio. ;-)
I also block javascript in my browsers by default and run an ad-blocker.
Sometimes I will also run Thor ( a nice proxy ).
Let me tell you what, IMHO, you should be worried about... creating "APPS in your cell phone" where you should be using the html interface. Every time you install stuff in your cell phone and create an account you are opening yourself to yet more data leaks... I don't create many accounts and don't install many apps in my phone... Heck, I just got a letter from AT&T that they were hacked recently... they're offering me a year's worth of "security" or something like that.
Sometimes I wonder if they are so cheap that they have so many data breaches or if they just want to sell panic and eternal subscriptions to credit security companies.
For me it has paid the bills for years.
Check out AFDX... a crazy design for avionics.
BTW, the encryption I'm referring to is far more safe. You generate the key, send it to other side and establish a unique point to point for each connection. Nobody else even knows about it. Nobody else even knows it exists or what kind of encryption you might be using.
It works very well but the self proclaimed "Internet Governing Bodies" ( an oxymoron ) think they know better... and my design is peer to peer, meaning not centralized. It can be easily done as an "appliance" but then the Controllers Of The Internet (think political) won't have any say on it.
For online credit card and money transactions, I normally use Paypal with a dedicated credit card and bank account. I do use the CC directly for Amazon and some sites like DIYAudio. ;-)
I also block javascript in my browsers by default and run an ad-blocker.
Sometimes I will also run Thor ( a nice proxy ).
Let me tell you what, IMHO, you should be worried about... creating "APPS in your cell phone" where you should be using the html interface. Every time you install stuff in your cell phone and create an account you are opening yourself to yet more data leaks... I don't create many accounts and don't install many apps in my phone... Heck, I just got a letter from AT&T that they were hacked recently... they're offering me a year's worth of "security" or something like that.
Sometimes I wonder if they are so cheap that they have so many data breaches or if they just want to sell panic and eternal subscriptions to credit security companies.
Last edited: