Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox Prepares To Mark All HTTP Sites 'Not Secure' After HTTPS Adoption Rises (bleepingcomputer.com)

Posted by BeauHD on from the secretly-configured dept.

An anonymous reader quotes a report from Bleeping Computer: The increased adoption of HTTPS among website operators will soon lead to browsers marking HTTP pages as "Not Secure" by default, and Mozilla is taking the first steps. The current Firefox Nightly Edition (version 59) includes a secret configuration option that when activated will show a visible visual indicator that the current page is not secure. In its current form, this visual indicator is a red line striking through a classic lock that's normally used to signal the presence of encrypted HTTPS pages. According to Let's Encrypt, 67% of web pages loaded by Firefox in November 2017 used HTTPS, compared to only 45% at the end of last year.

48 of 244 comments (clear)

  1. Not everything need story be encrypted by Anonymous Coward · · Score: 4, Insightful

    Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature. If it's valid, the file is usable. Encrypting the entire download is a waste of resources for both the server and client. Not everything needs to be encrypted, so this is a little silly. Plus, hosting providers often charge extra fees for https, at least based on my experience.

    1. Re:Not everything need story be encrypted by truedfx · · Score: 2

      Indeed not everything needs to be encrypted, and in some specific circumstances HTTP may be the better option, but firstly, the average user cannot tell what does and does not need to be encrypted, and secondly, even in those cases where HTTP is the better option, it's usually close enough nowadays that it doesn't make that much of a difference. Because of that, I'd be perfectly happy with HTTPS becoming the norm, HTTP flagged as insecure, but HTTP nonetheless continuing to be supported in browsers indefinitely.

  2. Stupid by Anonymous Coward · · Score: 2, Informative

    This is completely retarded. Not every site needs https.

    1. Re:Stupid by Man+On+Pink+Corner · · Score: 2

      But it's apparently very important to educate users to ignore yet another legitimate warning indication.

    2. Re:Stupid by TechyImmigrant · · Score: 2

      But it's apparently very important to educate users to ignore yet another legitimate warning indication.

      What's worse is the implication that if it isn't telling you that it is not secure, it must be secure, because it's using https.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  3. Servers on your LAN are probably Not Secure by tepples · · Score: 5, Informative

    HTTPS requires a certificate, and a certificate that requires a fully qualified domain name. The CA/Browser Forum's Baseline Requirements forbid issuing certificates in RFC 1918 private networks (such as 10/8 and 192.168/16) or the mDNS reserved domain (.local). This means everything on the average user's local area network will end up marked "Not Secure", such as the administration interface of the user's router, printer, or network attached storage (NAS) device.

    The document "Deprecating Non-Secure HTTP" states that Mozilla is aware of this problem but fails to offer a solution:

    Q. What about my home router? Or my printer?

    The challenge here is not that these machines can’t do HTTPS, it’s that they’re not provisioned with a certificate. A lot of times, this is because the device doesn’t have a globally unique name, so it can’t be issued a certificate in the same way that a web site can. There is a legitimate need for better technology in this space, and we’re talking to some device vendors about how to improve the situation.

    It should also be noted, though, that the gradual nature of our plan means that we have some time to work on this. As noted above, everything that works today will continue to work for a while, so we have some time to solve this problem.

    1. Re:Servers on your LAN are probably Not Secure by RightwingNutjob · · Score: 2, Insightful

      Great. Another layer of DRM. Printer doesn't work unless you're plugged into the internet and paying for 'up-to-date' certificates from the vendor.

    2. Re:Servers on your LAN are probably Not Secure by WaffleMonster · · Score: 2

      Q. What about my home router? Or my printer?

      The challenge here is not that these machines canâ(TM)t do HTTPS, itâ(TM)s that theyâ(TM)re not provisioned with a certificate. A lot of times, this is because the device doesnâ(TM)t have a globally unique name, so it canâ(TM)t be issued a certificate in the same way that a web site can. There is a legitimate need for better technology in this space, and weâ(TM)re talking to some device vendors about how to improve the situation.

      It should also be noted, though, that the gradual nature of our plan means that we have some time to work on this. As noted above, everything that works today will continue to work for a while, so we have some time to solve this problem

      The solution is logging into the device using TLS-SRP but this doesn't enrich the CAs so no chance in hell.

    3. Re:Servers on your LAN are probably Not Secure by vux984 · · Score: 2

      We don't care.

      What we care about is the interstitial page the browser throws up that prevents us from reaching the device until we click agree twice, add an exception, click advanced, click yes, we really mean it, click settings click enable user to view insecure sites... just to get it done. Its not this bad yet, but its getting there.

    4. Re:Servers on your LAN are probably Not Secure by vux984 · · Score: 2

      And the solution is really simple:

      firefox, chrome etc should have different rules when accessing devices on 10.x.x.x and 192.168.x.x etc.

      Especially if localhost is on the same subnet. Or a tracert to the device never crosses a public internet address. With equivalent rules for IPV6.

      For me at least the VAST majority of the time I'm accessing these devices I'm on the same private subnet. There's a couple scenarios at work where things are separated, and I might be accessing 10.1.1.x from 10.5.5.x etc,

      It can still flag it as an insecure connection, because it is, but it shouldn't make a big fuss about it or try and warn me the sky is falling and block me. Because its not touching the internet.

  4. If the signature itself is tampered with by tepples · · Score: 5, Insightful

    Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature.

    How can you be sure that the SHA-256 value against which you are verifying the disk image hasn't itself been tampered with on its way to your device?

    Encrypting the entire download is a waste of resources for both the server and client.

    No it isn't. If you fail to encrypt, your ISP, your ISP's ISP, and any snooping government can tell conclusively what you have downloaded. If you do encrypt, the eavesdropper can see only what domain you're accessing and the sizes of what you download. You can obfuscate even the sizes by using range requests to pull the 4 GB disk image a 4 MB chunk at a time.

    Plus, hosting providers often charge extra fees for https

    Then take your business elsewhere. Switch from a hosting provider that charges extra for HTTPS to a competing hosting provider that does not charge extra for HTTPS.

    1. Re:If the signature itself is tampered with by RightwingNutjob · · Score: 3, Insightful

      And sometimes you don't care. Like when you're on an internal network and don't want to confuse your users with a red warning signal.

    2. Re:If the signature itself is tampered with by truedfx · · Score: 2

      How can you be sure that the SHA-256 value against which you are verifying the disk image hasn't itself been tampered with on its way to your device?

      Even if the main download is done using HTTP, the SHA-256 value can be requested over HTTPS.

    3. Re:If the signature itself is tampered with by WaffleMonster · · Score: 2

      No it isn't. If you fail to encrypt, your ISP, your ISP's ISP, and any snooping government can tell conclusively what you have downloaded. If you do encrypt, the eavesdropper can see only what domain you're accessing and the sizes of what you download.

      For most publically available sites this is simply not true. Counting bytes and timing analysis is more than enough to reconstruct users activities with a high degree of confidence.

      You can obfuscate even the sizes by using range requests to pull the 4 GB disk image a 4 MB chunk at a time.

      Is it really more difficult for an adversary to sum up a bunch of 4MB chunks?

      Then take your business elsewhere. Switch from a hosting provider that charges extra for HTTPS to a competing hosting provider that does not charge extra for HTTPS.

      Telling someone who doesn't see the point of HTTPS for x,y and z to get a new provider is probably not likely to result in a positive outcome.

    4. Re:If the signature itself is tampered with by tepples · · Score: 2

      How to render the SHA-256 Pre-image collision attacks effectively moot: Check the Fucking File Size.

      The attack I'm concerned about doesn't involve a hash collision. The attacker who intercepts an HTTP connection can replace both the disk image with a replacement of the same size and the hash with the hash of the replacement image. And this interception (sometimes mistakenly called "transparent proxying") is much more difficult with HTTPS than with cleartext HTTP.

      This will just increase the cost of entry

      Increasing the cost of interception to where only nation-states can afford it and there's evidence if they do it anyway is the entire point of HTTPS.

    5. Re:If the signature itself is tampered with by tepples · · Score: 2

      Is it really more difficult for an adversary to sum up a bunch of 4MB chunks?

      Yes. For example, once you have the content length, you can always request the end of a roughly 4 GB file as a full 4 MB range rather than a partial chunk by seeking 4 MB before the content length. Or for an additional data cost smaller than 1 percent, you can randomly request one to ten extra chunks at various points in the file.

      Telling someone who doesn't see the point of HTTPS for x,y and z to get a new provider is probably not likely to result in a positive outcome.

      That was directed at people who do see the point "but...".

    6. Re:If the signature itself is tampered with by hairyfeet · · Score: 5, Insightful

      Insightful? Really mods? Lets take a site like Megofan...all it has is scans of old Mego adverts and interviews with the guys that worked there. No sign in, no information from the user at all, just some static images and text....now WHY IN THE FUCK does this need to be encrypted? Anybody? Beuller?

      You want to make the web safe? KILL JAVASCRIPT DEAD and while you are at it BAN accepting code from third parties like these sleazy as fuck advert companies...tada! Web is safe as in your mama's arms...oh but that would mean website owners might have to get off their overfed asses, wipe the Cheetos dust off their fingers and actually VET THEIR ADS instead of just bitching and whining when we block them! Can't have that, nope so lets make every site in the free world including those that are nothing but text and jpegs encrypt for...not a damned reason other than SECURITY THEATER.

      This is a classic example of the "we have to DO SOMETHING!" bullshit, a variation of the "think of the children!" kind of thinking...does it solve the REAL problem, which is our devices spying on us, malware filled adverts, or any of the real nasty things we've been dealing with? Nope. But hey it lets CA vendors make more money while putting on the appearance of giving a fuck and that is just as good in these days of hastag "our hearts are with" insert name of city...right?

      --
      ACs don't waste your time replying, your posts are never seen by me.
    7. Re:If the signature itself is tampered with by tepples · · Score: 2

      The web should have been fully encrypted from the start.

      With what? 40-bit keys? At the start of the web, competent encryption was considered a munition in some economically important countries.

    8. Re:If the signature itself is tampered with by Aristos+Mazer · · Score: 2

      Also, the CPUs weren't as good -- the time needed to encrypt and decrypt would have been a far greater percent of the available CPU than today, even with the shorter keys of the era. It wasn't practical to do a lot with encryption in the mid-1990s. Zipping up some files the size of a floppy disk into a password-protected .zip could take 20 minutes on the desktop I had; only a couple minutes without the password.

    9. Re:If the signature itself is tampered with by Askmum · · Score: 3, Insightful

      This is a classic example of the "we have to DO SOMETHING!" bullshit, a variation of the "think of the children!" kind of thinking...

      I totally agree. I have a small personal website that hosts some stats about my server (disk usage and such) and hosts pictures I want to share with people.

      Why would that site be unsafe? I use no cookies, I do not require logins. Why would my site be branded like that because some has-been company pushes their agenda?

    10. Re:If the signature itself is tampered with by TheRaven64 · · Score: 2

      The concern was that for large (multi-gigabyte) files, HTTPS becomes a waste of resources. I'm not going to comment one way or another on the correctness of that claim

      I am, by pointing out that Netflix is able to saturate 40GigE NICs in a single machine (I think they can now saturate two of them) serving nothing but HTTPS traffic, and the bottleneck for them is usually the disk and sometimes DRAM, but never the encrypt. On a modern CPU, you're DMAing from cache and you can encrypt a lot faster than line rate (particularly with AES, where it's almost entirely in fixed-function hardware) and then the encrypted data is right next to the DMA unit ready to send to the NIC. With newer NICs, you can offload most of the TLS (not the handshake, but all of the bulk encrypt) to the NIC, so you pay a tiny power cost but nothing else.

      --
      I am TheRaven on Soylent News
    11. Re:If the signature itself is tampered with by Dagger2 · · Score: 4, Informative

      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.

  5. How to Disable it by jwhyche · · Score: 3

    Outstanding. Now how will I disable this problem?

    --
    I read at +2. If your post doesn't reach that level I will not see or respond to it.
    1. Re:How to Disable it by vlueboy · · Score: 5, Insightful

      The rest of us can simply disable "security.insecure_connection_icon.enabled" in about:config.

      Oh?
      Just like Firefox's extensions fiasco where some similar about:hack "allowed" your unapproved extensions to continue running if it wasn't publicly vetted by the mozilla version of an app store? That respite, like many Firefox moves was killed on v48 a year ago and blew away a Firefox extension that was developed in-house and had no business being available to the world. And just a year earlier? the Chrome and Safari side grenade exploded with a different "security" feature that cost us man hours, training and bug stabilization time. Browserwise, there is nowhere safe of these whims.

      When Mozilla is saying the http sites will work "for a while" for local printers / routers, they're taking the haughty tone appropriate for someone saying we'll be allowed to be beggars at their house until they tire of taking pity on us... as if browser makers were paying US for using THEIR products. One reason open source projects aren't taken seriously, mind you, is present in that vacuous statement: unlike closed source companies like MS and Oracle, the statement of EOL comes with no hard dates. That's a red flag right there, considering Firefox has more or less had "courage" in announcing pulling the plug on other features or forcing unwanted garbage as well.

      I'm tired after seeing the bleakness of all the bug threads with complaints of business burdens produced by these changes that just keep falling on deaf ears: All browsers do this deprecation game on a whim without any standards emporium behind the stupidity (though sometimes the W3C is part of the problem.) The only winning move is NOT to upgrade, because freedoms imaginaryly lost n% of the time to some unseen enemy in a potential hack are less concrete than the freedom lost right now for 100% of the time in the form of loss of value and features.

  6. Let's Encrypt is gratis by tepples · · Score: 2, Informative

    The only "certification company" to which you'd need to "pony up cash" is the domain registrar, which you need anyway for a public website. Once you have a domain, you can automate provisioning of certificates issued without charge by Let's Encrypt using an ACME client such as Certbot.

  7. Who has 192.168.123.45 in your coffee shop? by tepples · · Score: 2

    http (IP on private network) = secure

    How so? When your laptop or phone is on restaurant or public library Wi-Fi, you don't know who has 192.168.123.45. This is why the definition of a "potentially trustworthy origin" in the W3C candidate recommendation "Secure Contexts" includes localhost but not RFC 1918 private IP addresses.

  8. Technically correct, in some situations by neiras · · Score: 2

    Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature. If it's valid, the file is usable. Encrypting the entire download is a waste of resources for both the server and client.

    As long as the signature file was delivered over HTTPS and you didn't have any evil root certificate authorities installed on your client, you would be fine. If the insecure download was tampered with, signature verification would fail, as you say.

    Encrypting downloads is not that big of a deal resource-wise these days, though. Why not let HTTPS handle MITM detection for you? ;) Most users won't check a sig file anyway.

  9. The LAN FQDN problem in a previous AMA by tepples · · Score: 2

    I mentioned the same planned obsolescence concern in my question to Jacob at Let's Encrypt in an AMA on reddit a year ago.

  10. How to use a private CA with BYOD? by tepples · · Score: 4, Insightful

    How is "make and install your own certificates" practical when users bring their own devices, such as public library patrons bringing their laptops or phones to a branch or friends or relatives bringing their laptops or phones to someone's home?

    1. Re:How to use a private CA with BYOD? by tepples · · Score: 2

      Similarly, BYOD on the home network should be segregated to an Internet-only guest wireless connection.

      That wouldn't help if you want to let guests print to your printer or view videos on your NAS.

    2. Re:How to use a private CA with BYOD? by tepples · · Score: 2

      it's probably easier just to use Let's Encrypt.

      As I wrote in my other comment, Let's Encrypt requires a fully-qualified domain name, not a 192.168 or .local.

    3. Re:How to use a private CA with BYOD? by tepples · · Score: 2

      I edited it out because nobody answered my previous question about practical methods of distributing the root certificate of "roll your own CA" to guests' devices.

    4. Re:How to use a private CA with BYOD? by TheRaven64 · · Score: 2

      No reputable CA will let you have a cert for the 192.168/16 subnet or anything in the .local TLD, because these hosts are not unique and foo.local on your network isn't foo.local on mine. The best solution for these is to give them global IPv6 addresses, but only open a pinhole in your firewall for the Let's Encrypt dialback. This lets you get a proper cert for them, but doesn't allow anything off network to access them.

      --
      I am TheRaven on Soylent News
  11. Re:The bigger problem by tepples · · Score: 2, Interesting

    The percentage covers only the subset of users who have opted into Firefox telemetry. If you want to make your votes not count, that choice is yours. Just don't whine when Mozilla cuts your pet feature for lack of usage share justifying the maintenance cost.

  12. FFS by fyngyrz · · Score: 4, Insightful

    Good thing that the cost is essentially zero on modern hardware, then.

    You know what cost isn't zero?

    Changing the billions of http: links on billions of web pages to billions of other web pages, that's what.

    Firefox - and Google, for that matter - are damaging the very integrity of the net, ironically, while claiming to improve it. They're not improving it. This is anal-retentive nonsense. Not everything needs to be encrypted. If something does need to be encrypted, that falls into the realm of the reasonable decision of the page owner, not the web browser author or the search engine.

    We've gotten along just fine without this nonsense thus far; I see no reason - other than the use of force by these bad actors - that we should have to arbitrarily change huge portions of the Internet.

    You want to encrypt, go ahead. You can if you want. And of course, if you do, it'll be fine. But using force to make you do it... no. That's just evil.

    And we know that browser warnings will put people off. This isn't an "otherwise-harmless" act. It'll do real damage.

    --
    I've fallen off your lawn, and I can't get up.
    1. Re:FFS by lucasnate1 · · Score: 2

      Sure, because http can't redirect to https at all.

      --
      Avantgarde Hebrew science fiction
    2. Re:FFS by Zero__Kelvin · · Score: 3, Informative

      Calm down Sally. They aren't stopping anyone from using HTTP, they are merely making sure uses are aware that their connection is not secured. They aren't breaking anything. The fact is that the S in HTTPS is the secure part, and without that S your connection is not secure. If communicating facts to the user is breaking things then lets hope more people start breaking things.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    3. Re:FFS by Aristos+Mazer · · Score: 2

      > We've gotten along just fine without this nonsense thus far;

      No, we haven't. You mention "other than the use of force by these bad actors" -- yes, exactly, that is the sole and complete reason for us having to secure the Web. If you can find a way to force people to stop attacking the integrity of the network, we can avoid this change. But otherwise, help out by grepping /s/http/https in pages you own.

  13. Domain-validated vs. Extended Validation by tepples · · Score: 3, Insightful

    It's why a CA can charge hundreds of dollars to perform 50ms of compute effort.

    The "50 ms of compute effort" certificates are domain-validated, with just CRL and OCSP as ancillary services. Those typically cost $15 for three years (ssls.com) or nothing for 90 days (letsencrypt.org). The certificates that cost hundreds of dollars are Extended Validation, which ensure not only a connection between the certificate and the domain owner but also that a vandal isn't typosquatting the domain itself. These often come with greater insurance guarantees.

    1. Re:Domain-validated vs. Extended Validation by TechyImmigrant · · Score: 3, Insightful

      It's why a CA can charge hundreds of dollars to perform 50ms of compute effort.

      The "50 ms of compute effort" certificates are domain-validated, with just CRL and OCSP as ancillary services. Those typically cost $15 for three years (ssls.com) or nothing for 90 days (letsencrypt.org). The certificates that cost hundreds of dollars are Extended Validation, which ensure not only a connection between the certificate and the domain owner but also that a vandal isn't typosquatting the domain itself. These often come with greater insurance guarantees.

      And all those services and fees have nothing to do with my options for securing my own stuff. In fact they just make things worse.
      As I wrote on another thread, I ran Let's Encrypt's scripts and they crashed. It's a joke built with shoddy code.

      I built a CA once, with bespoke software, a screened room, air gaps, man traps and the whole malarky. All to certify communication devices, because all the cert vendors were not interested in selling certs for a few cents each for millions of devices.

      The more I have dealt with the cert industry, the more I hate it.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    2. Re:Domain-validated vs. Extended Validation by thegarbz · · Score: 2

      As I wrote on another thread, I ran Let's Encrypt's scripts and they crashed. It's a joke built with shoddy code.

      Did you file a bug report? There's millions of people who had no problem running the scripts on wide variety of hardware and software.

      The more I have dealt with the cert industry, the more I hate it.

      So you should be on board with what Lets Encrypt is trying to do, which is removing the unnecessary garbage from the CAs for what is handled by a simple automated domain ownership check.

    3. Re:Domain-validated vs. Extended Validation by Octorian · · Score: 2

      So you should be on board with what Lets Encrypt is trying to do, which is removing the unnecessary garbage from the CAs for what is handled by a simple automated domain ownership check.

      Lets Encrypt is probably a great option if you're trying to secure a general purpose Linux server somewhere.
      But if you're trying to secure something their scripts won't run on, then its a PITA that isn't really helping.
      Most of what we're complaining about is stuff their scripts won't run on.

  14. Re:why does my site need to be secure by Sloppy · · Score: 4, Interesting

    I am generally curious why someone would need EVERY site to be secured by https.

    I can't answer that question, but this..

    What about small businesses who dont offer any downloads or have any contact forms and as such their websites function like a digital flier.

    .. is easy. You don't want ISPs altering the flier. And people may recall, one of the big calls to arms for the whole Network Neutrality thing everyone has been talking about, is that ISPs were altering web replies to insert ads. I've heard Comcast users even say that Comcast still communicates some kinds of things to their customers by just barging into whatever web page a user happens to have loaded, and changing it to include a message from Comcast. (Because apparently email is too hard.)

    MitM can't only snoop; they can also change things.

    Examples involving intranets, though, I can't possibly get into Firefox's head. I am pretty sure whatever reason they come up with, will be bullshit. But I guess I ought to hear 'em, first...

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  15. Use HSTS by tepples · · Score: 4, Informative

    Changing the billions of http: links on billions of web pages to billions of other web pages, that's what.

    If your HTTPS server sends the Strict-Transport-Security header for one request, the browser will automatically rewrite subsequent requests to http: scheme URLs on the same domain to use the https: scheme instead. If you enable this long-term for all subdomains, you can get the header "preloaded", or included with the browser itself so that even the first request gets rewritten. The HTTPS Everywhere extension by EFF is an additional source of preloads.

  16. breaking web proxies is stupid. by anon+mouse-cow-aard · · Score: 2

    I run software that distributes non-sensitive data across wide area networks... many people at each site want the same data, so I stick a web caching proxy on the site, and the big data (many gigs worth) are all transferred once, and then served from the local caching proxy. encrypting means the caching proxy needs to man-in-the middle, or it's just borked. stupid.

  17. Idiotic by slashmydots · · Score: 3, Insightful

    Oh good, now I can pay like $100 a year for an encryption cert that I don't need just to run my static, read-only website that tells people what my business does and where it is and how to contact me. Awesome.

  18. And yet firefox hides http:// by default.. by Anonymous Coward · · Score: 3, Interesting

    The geniuses at Mozilla decided to hide the http: prefix from the user some time ago, so instead of http://www.cnn.com/ the user sees www.cnn.com

    The http: prefix indicates that THERE IS NO ENCRYPTION.

    Why hide it from the user and then add a non-standard indicator that there is no encryption?

    So many UI designers should be shot...

  19. Unintended Consequences by Dangerous_Minds · · Score: 2

    It does concern me about some of the smaller sites struggling to survive. If a hypothetical site is barely able to pay the server bills, the last thing they need is an additional $15 charge per year (or more) tacked on just to allow a percentage of users to access their site without having users complain about alarms blaring that it's an unsecured site. I mean, sure, $15 a year doesn't sound like much, but if you're not a major site pulling in hundreds off of ad impressions or subscription fees, that seemingly small fee is going to sting on the bottom line. No matter how you slice it, this is going to raise the barrier for entry for new sites.

    This added to what is going on with the destruction of network neutrality in the US is almost like pouring salt on the wound. The number of users being able to reasonably access your site may very well drop, but Mozilla decided that web admins need to add another layer of security that come with fees in the process.

    --
    Daily read for tech news: Freezenet.ca