Firefox won't even load bootstrapped extensions now unless signed by Mozilla's system addons key, which is unavailable to the public and which they won't use to sign any non-Mozilla addons (even though they were happy to use it to sign a marketing tie-in with a TV show, but that's a whole separate issue). They also won't allow you to upload the new version to AMO which prevents you from shipping updated versions to anybody that installed the extension from AMO in the first place (even if those users could use the updated version, which they can't).
If your extension happens to be simple enough to be possible within the WebExtensions API then you can convert it to a WE and you'll be fine, but many extensions simply can't be done as WEs (and a lot of those that can are only possible with some pretty bad hacks -- e.g. having to inject your code into each and every website that's loaded rather than just once per browser window).
You are right, but v6 subnetting is a lot easier than v4 subnetting because of the way that hex lines up with binary more easily than decimal does, so this seems more like an argument in favor of v6 rather than against it.
Note that most stuff ships with privacy addresses enabled, so your "IPV6 unique ID" used for outbound connections will change to a new, completely random ID every time you restart a device, reconnect one to the network, or in any case after 24 hours, which should limit its usefulness for tracking.
Of course, as you say, everybody is already tracking you via cookies and fingerprinting anyway.
Facebook have done measurements that show v6 as giving ~10-15% faster page loads compared to v4. On some specific ISPs the difference will be even higher (for instance T-Mobile in the US backhaul all of their v4 traffic across the country to the datacenters that host their NAT64 infrastructure, while routing v6 more directly).
Actually, 64 bits might be enough for the internet, especially if you were willing to put up with some degree of increased costs and admin headache (and oh boy are we willing to do that), but "might" isn't good enough. If you're going to do an incredibly difficult protocol switchover to increase the address size, you really want to get it big enough the first time.
"Whoops. Tehee. It's still not big enough. We need to make it bigger again." is just not going to cut it.
You need state tracking for NAT, not a stateful firewall. Yes, it just so happens that state tracking is also necessary for stateful firewalls, so it's quite common to find firewalling and NAT functionality combined into the same piece of software, but they're separate things. You can do NAT without having a firewall just fine.
...and if you do, then you'll find that anybody that can send packets to your router with the dest address set to the IP of a machine on your LAN will be able to connect to that machine. The good news is that if you're also using RFC1918 addresses on the LAN (which isn't a requirement!) then the set of people that can actually do that will be limited to only your ISP, and anybody that can gain either physical or remote access to your ISP's network, and anybody (such as the police or government) that can convince or coerce the first two sets of people into helping.
They do. If you take a dual-stack network and measure the traffic on it, you'll find that about half of it by volume already goes via v6.
Technically the priority is usually set by the OS/system resolver library, which sorts DNS results by an algorithm that is roughly "v6 first if you have a public v6 address, otherwise v4 first". Some software does override the ordering, and other software (like Firefox) has ADHD and will try to connect over v4 if the first connection attempt hasn't finished within 300ms, but as a rule v6 will be preferred if you have it.
That wasn't a mistake, it was a necessity. v4 only has space for 32 bits in its src/dest address header fields, and v6 addresses are longer than that, so you can't fit them in. It's v4 that's incompatible with v6, not the other way around.
That said, you can accept both v4 and v6 connections on a single v6 socket, so I'm not entirely sure what you're on about for that. On Linux the behavior is controlled by net.ipv6.bindv6only or a socket option, with the default being to permit v4 connections to v6 sockets.
If you have an ecommerce site that requires downtime to rotate certs, then you have a problem that needs fixing. If you really can't fix it for some reason, then it just makes automation even more important to you.
As I understand it, that's not exactly what it does. Third-party sites are still allowed to use cookies, but they get access to a different set of cookies depending on which first-party site they were loaded from.
You can reject all cookies from third-party sites by setting network.cookie.cookieBehavior=1.
It is, however, reasonable to permit extension devs to update their extensions to fix breakage. However, for many extensions, Mozilla are not permitting them to do that.
Endless backwards compatibility is indeed not possible for these extensions, but that was never expected anyway and it's not a reason to prevent devs from putting the work in if they want to.
Why the heck did you not just use the national currency of whatever country your store is in?
Bitcoin is not a currency. It's a payment network, and its properties make it best for transactions between two distant people, i.e. online shopping. If you can meet in person then just use cash.
Let's Encrypt are who I was thinking of (for all I know there may be others, but if there are then they aren't making a lot of noise).
You don't need to download LE's software to get certs from LE. All you need is an ACME client (which can itself be used with any ACME-supporting CA). Some software, including Apache httpd, has built-in ACME support, and for other software I can see at least 3 ACME clients in the Debian repositories which should be just as trustworthy as any other piece of software in the repos. There is no particular reason to download anything from LE's site.
Don't forget that ACME clients are generally automated, so the time you spend setting them up is the only time you spend dealing with them. With CAs that don't support ACME, generally you are stuck manually renewing the cert every time it expires.
If you don't care that the site is unsafe, then just ignore the note that says it's unsafe.
But the warning will push sites to use HTTPS, which does fix real security and privacy problems. Admittedly there are some problems that HTTPS won't fix (like the site itself tracking you, or that squeaky hinge on your garden gate) but that's not a good reason not to use it.
HTTPS itself is fine, but some of the algorithms it can use are questionable. In particular, the NIST p curves (which are the most widely supported curves used for elliptic curve cryptography) are mega suspicious -- the method for picking them was to have an NSA employee tell NIST "here are the curves you're going to use". Also, the justification for those curves was their performance, yet they aren't actually very fast, _and_ they have certain characteristics that make it easy to screw up your implementation. One wonders why the NSA wanted these particular curves to be standardized rather than a different set.
There is now the much better choice of Curve25519, but it has only recently gained support in TLS libraries and browsers.
(If you want more detail on the issues with NIST's p curves, see this talk, and if you're wondering whether the NSA would really try to undermine a public standard, see the Dual EC random number generator.)
What scripts were you running? I've been using dehydrated and it hasn't been fragile at all, plus it's a bash script and bash is widely supported on pretty much any flavor of Linux I've ever used. You don't even have to run it on the machine that will be using the certs (though I did have to write a custom script to do DNS updates; presumably there are other clients that have that built-in).
There's also built-in support for ACME in some webservers (e.g. Apache) if you really can't get an ACME client running on at least one system.
I have some good news for you: you don't need to pay $15/year for an SSL cert. There is at least one CA providing certs for free, via a generic and open protocol called ACME.
A few years ago you would have had a point, but not today.
LE's software mostly works with everything. It generates standard SSL certs that you can install with a script, and if you can't get that working then either you don't know enough to be running a public server on today's internet or your software/devices are utterly broken and need to be fixed.
the way https is now is a money making scam for a certain cartel
I just can't fathom how you could say this when you clearly know that LE exists. If you have some situation where LE doesn't work and yet a paid CA does work, surely the scam is being pulled by whoever created that situation?
Because it's open to MITM and passive snooping. There have been cases of networks inserting DDoS code into unencrypted webpages to recruit clients into attacking an unrelated site. (Or if you prefer, cases of networks inserting cryptocoin miners.) It's also possible to exploit security vulnerabilities in the client by injecting code into a plain-text connection, thus hiding the source of the exploit (and saving you the effort of tricking the client into visiting your own site).
Plain-text HTTP is just plain unsafe. That's why it should be branded as unsafe.
Interestingly, I've seen a lot of people who believe this, and yet:
The company was formed in March 2006 by the merger of NTL and Telewest, which created NTL:Telewest. In July 2006, the company purchased Virgin Mobile UK, creating the first "quadruple-play" media company in the United Kingdom, offering television, internet, mobile phone and fixed-line telephone services. In November 2006, the company signed a deal with Sir Richard Branson to license the Virgin brand for the combined business. All of the company's consumer services were rebranded under the Virgin Media name in February 2007.
...that is not actually how it went. It's surprising how effective a name change can be in getting people to think that you're a different company.
Much like net neutrality- Comcast would never ever throttle your connection or block certain sites, they just want the ability to do so, even though they would never ever do that. But they want to be able to anyway. Hmmm.
three seconds later "Hey, here's how to pay us to remove this throttle we just added."
Between improved health care and demographic changes, we have more old people around that need more treatment. That'll be part of it.
But probably the biggest part is cost disease, which affects the NHS just as much as it affects healthcare, and other industries, in other countries. Without all the cuts, spending would (...presumably?) have gone up even further.
Yes, you can. Just because the sandbox exists doesn't mean it has to be used for every extension. It should be used for the extensions which can be sandboxed, and the ones which can't should just run under your normal user permissions like all the rest of your software does.
Slashdot Mirror
Firefox won't even load bootstrapped extensions now unless signed by Mozilla's system addons key, which is unavailable to the public and which they won't use to sign any non-Mozilla addons (even though they were happy to use it to sign a marketing tie-in with a TV show, but that's a whole separate issue). They also won't allow you to upload the new version to AMO which prevents you from shipping updated versions to anybody that installed the extension from AMO in the first place (even if those users could use the updated version, which they can't).
If your extension happens to be simple enough to be possible within the WebExtensions API then you can convert it to a WE and you'll be fine, but many extensions simply can't be done as WEs (and a lot of those that can are only possible with some pretty bad hacks -- e.g. having to inject your code into each and every website that's loaded rather than just once per browser window).
You are right, but v6 subnetting is a lot easier than v4 subnetting because of the way that hex lines up with binary more easily than decimal does, so this seems more like an argument in favor of v6 rather than against it.
Note that most stuff ships with privacy addresses enabled, so your "IPV6 unique ID" used for outbound connections will change to a new, completely random ID every time you restart a device, reconnect one to the network, or in any case after 24 hours, which should limit its usefulness for tracking.
Of course, as you say, everybody is already tracking you via cookies and fingerprinting anyway.
Facebook have done measurements that show v6 as giving ~10-15% faster page loads compared to v4. On some specific ISPs the difference will be even higher (for instance T-Mobile in the US backhaul all of their v4 traffic across the country to the datacenters that host their NAT64 infrastructure, while routing v6 more directly).
The internet does.
Actually, 64 bits might be enough for the internet, especially if you were willing to put up with some degree of increased costs and admin headache (and oh boy are we willing to do that), but "might" isn't good enough. If you're going to do an incredibly difficult protocol switchover to increase the address size, you really want to get it big enough the first time.
"Whoops. Tehee. It's still not big enough. We need to make it bigger again." is just not going to cut it.
You need state tracking for NAT, not a stateful firewall. Yes, it just so happens that state tracking is also necessary for stateful firewalls, so it's quite common to find firewalling and NAT functionality combined into the same piece of software, but they're separate things. You can do NAT without having a firewall just fine.
...and if you do, then you'll find that anybody that can send packets to your router with the dest address set to the IP of a machine on your LAN will be able to connect to that machine. The good news is that if you're also using RFC1918 addresses on the LAN (which isn't a requirement!) then the set of people that can actually do that will be limited to only your ISP, and anybody that can gain either physical or remote access to your ISP's network, and anybody (such as the police or government) that can convince or coerce the first two sets of people into helping.
They do. If you take a dual-stack network and measure the traffic on it, you'll find that about half of it by volume already goes via v6.
Technically the priority is usually set by the OS/system resolver library, which sorts DNS results by an algorithm that is roughly "v6 first if you have a public v6 address, otherwise v4 first". Some software does override the ordering, and other software (like Firefox) has ADHD and will try to connect over v4 if the first connection attempt hasn't finished within 300ms, but as a rule v6 will be preferred if you have it.
That wasn't a mistake, it was a necessity. v4 only has space for 32 bits in its src/dest address header fields, and v6 addresses are longer than that, so you can't fit them in. It's v4 that's incompatible with v6, not the other way around.
That said, you can accept both v4 and v6 connections on a single v6 socket, so I'm not entirely sure what you're on about for that. On Linux the behavior is controlled by net.ipv6.bindv6only or a socket option, with the default being to permit v4 connections to v6 sockets.
If you have an ecommerce site that requires downtime to rotate certs, then you have a problem that needs fixing. If you really can't fix it for some reason, then it just makes automation even more important to you.
As I understand it, that's not exactly what it does. Third-party sites are still allowed to use cookies, but they get access to a different set of cookies depending on which first-party site they were loaded from.
You can reject all cookies from third-party sites by setting network.cookie.cookieBehavior=1.
It is, however, reasonable to permit extension devs to update their extensions to fix breakage. However, for many extensions, Mozilla are not permitting them to do that.
Endless backwards compatibility is indeed not possible for these extensions, but that was never expected anyway and it's not a reason to prevent devs from putting the work in if they want to.
Why the heck did you not just use the national currency of whatever country your store is in?
Bitcoin is not a currency. It's a payment network, and its properties make it best for transactions between two distant people, i.e. online shopping. If you can meet in person then just use cash.
Not entirely. In fact, everything I mentioned in my post other than cryptocurrency miners is possible without touching Javascript.
Let's Encrypt are who I was thinking of (for all I know there may be others, but if there are then they aren't making a lot of noise).
You don't need to download LE's software to get certs from LE. All you need is an ACME client (which can itself be used with any ACME-supporting CA). Some software, including Apache httpd, has built-in ACME support, and for other software I can see at least 3 ACME clients in the Debian repositories which should be just as trustworthy as any other piece of software in the repos. There is no particular reason to download anything from LE's site.
Don't forget that ACME clients are generally automated, so the time you spend setting them up is the only time you spend dealing with them. With CAs that don't support ACME, generally you are stuck manually renewing the cert every time it expires.
If you don't care that the site is unsafe, then just ignore the note that says it's unsafe.
But the warning will push sites to use HTTPS, which does fix real security and privacy problems. Admittedly there are some problems that HTTPS won't fix (like the site itself tracking you, or that squeaky hinge on your garden gate) but that's not a good reason not to use it.
HTTPS itself is fine, but some of the algorithms it can use are questionable. In particular, the NIST p curves (which are the most widely supported curves used for elliptic curve cryptography) are mega suspicious -- the method for picking them was to have an NSA employee tell NIST "here are the curves you're going to use". Also, the justification for those curves was their performance, yet they aren't actually very fast, _and_ they have certain characteristics that make it easy to screw up your implementation. One wonders why the NSA wanted these particular curves to be standardized rather than a different set.
There is now the much better choice of Curve25519, but it has only recently gained support in TLS libraries and browsers.
(If you want more detail on the issues with NIST's p curves, see this talk, and if you're wondering whether the NSA would really try to undermine a public standard, see the Dual EC random number generator.)
What scripts were you running? I've been using dehydrated and it hasn't been fragile at all, plus it's a bash script and bash is widely supported on pretty much any flavor of Linux I've ever used. You don't even have to run it on the machine that will be using the certs (though I did have to write a custom script to do DNS updates; presumably there are other clients that have that built-in).
There's also built-in support for ACME in some webservers (e.g. Apache) if you really can't get an ACME client running on at least one system.
I have some good news for you: you don't need to pay $15/year for an SSL cert. There is at least one CA providing certs for free, via a generic and open protocol called ACME.
A few years ago you would have had a point, but not today.
Except not, because you can get SSL certs for free (via a mechanism that is actually easier than paying for the certs).
If you had to pay then you would have a point, but you don't.
LE's software mostly works with everything. It generates standard SSL certs that you can install with a script, and if you can't get that working then either you don't know enough to be running a public server on today's internet or your software/devices are utterly broken and need to be fixed.
I just can't fathom how you could say this when you clearly know that LE exists. If you have some situation where LE doesn't work and yet a paid CA does work, surely the scam is being pulled by whoever created that situation?
Because it's open to MITM and passive snooping. There have been cases of networks inserting DDoS code into unencrypted webpages to recruit clients into attacking an unrelated site. (Or if you prefer, cases of networks inserting cryptocoin miners.) It's also possible to exploit security vulnerabilities in the client by injecting code into a plain-text connection, thus hiding the source of the exploit (and saving you the effort of tricking the client into visiting your own site).
Plain-text HTTP is just plain unsafe. That's why it should be branded as unsafe.
Interestingly, I've seen a lot of people who believe this, and yet:
The company was formed in March 2006 by the merger of NTL and Telewest, which created NTL:Telewest. In July 2006, the company purchased Virgin Mobile UK, creating the first "quadruple-play" media company in the United Kingdom, offering television, internet, mobile phone and fixed-line telephone services. In November 2006, the company signed a deal with Sir Richard Branson to license the Virgin brand for the combined business. All of the company's consumer services were rebranded under the Virgin Media name in February 2007.
...that is not actually how it went. It's surprising how effective a name change can be in getting people to think that you're a different company.
Much like net neutrality- Comcast would never ever throttle your connection or block certain sites, they just want the ability to do so, even though they would never ever do that. But they want to be able to anyway. Hmmm.
three seconds later "Hey, here's how to pay us to remove this throttle we just added."
Between improved health care and demographic changes, we have more old people around that need more treatment. That'll be part of it.
But probably the biggest part is cost disease, which affects the NHS just as much as it affects healthcare, and other industries, in other countries. Without all the cuts, spending would (...presumably?) have gone up even further.
Yes, you can. Just because the sandbox exists doesn't mean it has to be used for every extension. It should be used for the extensions which can be sandboxed, and the ones which can't should just run under your normal user permissions like all the rest of your software does.