Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair.
Of course this in itself doesn't mean anything. Creation of a key pair doesn't preclude existence of parallel trust paths.
and the site you're authenticating to stores the public key.
When I login to a site using this system are you saying the sites keep a database of actual public keys and validates by matching my individual public key from that databases? It doesn't simply perform validation using something more manageable higher up trust chain?
The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware
I don't understand how this is possible. Does each piece of hardware have a factory installed key pair to establish this? What is the basis for determining security of key storage?
Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.
What is the benefit of Google's CA in the first place? What functionality is enabled that wouldn't be possible without it? Is it just this idea of proving the security of key storage and nothing else? What breaks without it?
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
This is a scary argument.
Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.
You are right in that this is not because they are the root CA "for much of the" web.
It's much more basic than that. It's simply because they are a CA and therefore inherently in a position to globally issue certs trusted unconditionally by all clients using the web regardless of how many customers an individual CA has.
If Google is able to do something similar WRT to authentication then it's to borrow a phrase from Joe Biden... a big fucking deal. I would hope that Google DOES NOT have the ABILITY to bypass FIDO authenticated identity seen by applications relying on this system for authentication. If it is possible for Google to issue itself a key pair to impersonate one of my users then in fact the system is inherently broken, unfit for purpose and should not be used by anyone.
That seems to be a pretty cumbersome system for users as they would have to either pay to be recognized by a CA and/or would have to go through a rigamarole set-up procedure to install a certificate in every piece of Internet-communicating software they use.
It's not like this. The best high level explanation I can give is that client certs are like browsing to a secure site except in reverse.
1. Your browser has a listed of trusted certs handed down by the CA gods. 2. www.reallysecuresite.omg has a private/public key pair blessed by CA gods.
Client certs flip this.
1. With client authentication the browser has private/public key pair blessed by www.reallysecuresite.omg.
2. www.reallysecuresite.omg has a list of trusted root certs blessed by itself.
You don't need the blessing of third party to hand out client certs. It costs you nothing and there is no disadvantage to it.
Also, what happens if that cert gets lost? Now they have to revoke it (and we all know what a joke the cert revocation system is) and go through the whole thing again...
If the client looses it's private key to authenticate to www.reallysecuresite.omg it has to petition the site for a new one if a backup is unavailable.
It's the same thing if you lose your smart card or USB yubikey. Perhaps the site allows you to login with your username and password and have a new key automatically issued to you. This obviously isn't secure but most public facing sites do garbage like this all the time because they don't care about security. They care about ease of use and not dealing with password reset and market it as a security improvement.
If the server loses its private key then it only loses the ability to issue new certificates to users without creating a new CA which is free. It continues to have the ability to authenticate existing users. A reasonable price given the scenario.
Except the crap user experience of existing cert methods. Have you used them? I've only tried to add root certs using It directions and that didn't even work the first time. And they expire so you get to juggle them manually.
All major browsers/OS have a means of importing pkcs #12 files easily without much effort. As in you save/open the pkcs 12 file and are greeted with a prompt to add it to the user certificate store. It takes seconds.
I agree this is far from ideal.. the interaction should be more user friendly/seamless/automated yet it's still very much a trivial process.
As far as generating certs and expiration policy that's all on the application server. The system we use handles this seamlessly for us while onboarding new users. I can see how people who use third party certificate enrollment tools or CLI scripts to manage this could come away thinking that this is too hard/sucks. It doesn't have to be this way... it's within the application servers ability to control.
I assume FIDO2 is a mechanism for automatic certificate agreement and distribution. So yeah... That'd be a big boon over the existing system in my experience as an attempted consumer of said system.
All the same shit (PKI) and all of the same issues. You can more or less "automatically" establish trust with either one but the resulting trust relationship will very much reflect lack of initial input effort.
I've dealt with client certs quite a bit having been a government contractor both utilizing and writing software which does CAC/PIV (i.e. client certificate) authentication. While it is an effective way to secure an endpoint, the user experience is less than ideal. Because the client cert is negotiated as part of of the TLS handshake, when it fails it is difficult to give any meaningful feedback to the user.
Most secure authentication systems only provide pass/fail feedback by design.
Here you at least have a choice. You can setup the web site to not require certificate authentication so that if authentication fails the user is given instruction on what they can do/contact to get the issue resolved.
The UI browsers present to chose a certificate is rather rudimentary and for good reason not under the control of the application developer. In addition, most browsers pin the client certificate choice for the duration of the session, so if a user accidentally chooses the wrong certificate, they have to quit out and restart their browsers.
I completely agree the client implementation sucks in many regards but these are implementation problems that can be resolved with relatively minor effort. This isn't an excuse to reinvent the wheel.
All of this is not to mention the logistical hassle of issuing certificates, maintaining a CRL, getting smart cards out to people, etc. This and the usability issues are tractable for a large organization whose users will receive training on how to deal with mutual authentication, but for the general public I think it would be kind of a non-starter.
The issues are exactly the same regardless of key based possession system you use. It's always a series of tradeoffs between ease of use and security.
You could easily automate issuing certs on first logon for normal users. CRLs can be avoided by having application server keep a list of acceptable ID's.
When it comes to public sites small UX tweaks to close the loop on initial signup/first login would provide security benefits.
In many ways 2FA is, was and always will be a non-starter for public. The public push isn't driven by security as much as it's driven by a desire for companies to minimize dealing with the headaches associated with "I forgot my password".
Client certs can be deployed in ways that makes them every bit as feckless as most public facing 2FA systems with minimal effort/change.
One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key.
There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.
The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."
So instead of addressing usability problems the answer is to create an entirely new incompatible protocol? Fuck that. I use client certs every day and it's no more of a usability nightmare than HTTP authentication.
No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.
This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.
Backing up certificates and moving them among devices isn't easy.
This is nonsense. All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.
Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site
They are not domain based they are signer based. The proper certificate is generally always selected automatically based on who signed it in the first place unless there is a name collision with signer in which case a list of matching client certs are displayed. In no entirely preventable event are users given an infinite list of certs to choose from only the matching list.
Users on a per domain basis existing browsers can be configured prompt whether or not to use a cert to mitigate usage as tracking mechanism.
It would also be trivial to add constraints to client certs which limit domain applicability. There is no reason to invent a new standard.
Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways
This is commonly used by "enterprise" systems rather than customer facing web sites.
How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?
I agree FIDO is redundant. It brings nothing useful to the table client certs don't already provide. Any existing UX issues with deployment and management could be addressed instead of attempting to create completely new and redundant standards.
That said there are few things as deleterious to the continued security of Internet users today than "regular password fields". Continuing to allow insecure authentication as if it's somehow acceptable (Bu....uuu....ttt.. TLS..!!) results in millions falling victim to phishing campaigns that don't need to.
The fact is that the whole web must change because the whole web is "doing it wrong". Every last site on the Internet with a web login form asking for a password needs to change.
This advice is ridiculous, dangerous and irresponsible. DRC should know better.
Global deployment of DNSSEC without first addressing underlying transport issues (DNS over UDP without DNS cookies (RFC7873)) is guaranteed to have disastrous impacts on the availability of DNS itself and the Internet generally.
Until you learn that they all have a cam... Honestly, privacy is an illusion no matter where you go.
We're fucked anyway so nothing matters? Is that right?
We're all going to die what difference does it make if airlines maintain their aircraft? A sufficiently resourced actor could throw me off the plane without a parachute so what's the point in caring about flight safety?
A sufficiently resourced actor will always be able to get footage of you picking your nose, scratching yourself, or fondling your seatmate.
How would this line of argument ever be falsified?
You seriously seem to be asserting that something COULD happen therefore nothing matters and further caring about the issue at all is pointless as a result.
Airlines might be injecting cameras up our noses but so what? A sufficiently resourced actor could inject a camera up my nose so no big deal right?
Even if you didn't actually do any of those things, there's always deepfakes. It
And aliens... what possible relevance is there between the specific issue of cameras in seats and deepfakes?
might offend your sensibilities, but it's a reality that you're probably going to want to get comfortable with lest you be driven mad by it.
Madness is typically what results when a sufficient number of people fail to sufficiently assert their rights and stand up for themselves and their interests.
There is no organization more corrupt or deleterious to the continued operation of the network than ICANN. They stopped giving a fuck about best interests of the network decades ago.
Today they care only about themselves making money from proliferation of TLDs which serves no useful purpose other than assisting phishers and exposing Internet users to unnecessary risk of collision with common internal naming schemes.
It's time for wholesale change within ICANN. Leadership needs to be replaced with a structure that is accountable to the Interests of the network rather than themselves.
Sounds to me the problem isn't capitalism so much as it's lazy people (e.g. Bankers) who believe after they produce something they are entitled to sit idle and keep getting paid for doing nothing in return.
Can't be done. Visa, Mastercard, and Amex all have clauses forbidding those cash discounts, which can cause a merchant's account to be pulled.
This has already been settled in the courts. Credit card companies can't prevent merchants from charging customers transaction fees for using credit cards.
Sooner US market gets pissed off enough at visa/mc duopoly with their in your face brazen market collusion and security nightmare 'take' rather than 'give' models and instead move to something half way rational like SWIFT instant payments the better off we will all be.
NTLM, NTLMv2 and yes Kerberos are all HOPELESSLY insecure CHAP based authentication protocols subject to offline brute force campaigns simply by way of an adversary eavesdropping on authentication process. No server hacking required.
Microsoft STILL insists upon using this crap in its current software when secure alternatives are readily available.
The only way authentication works in practice today is by protecting authentication exchanges using PKI... similar in concept to all of the web login forms on present day websites. (phishers paradise)
As for stored credentials... Salting and amplification make password guessing harder.. (persistence of NTOWF is unnecessarily sad) but not in any meaningful way that would do much to limit effective impact in the event of hash table compromise. With hashes for any number of accounts compromised an attacker with access to salted amplified hashes using present day resources is still assured meaningful victory no matter what.
As policy you are way better off treating hashes as plaintext password lists and acting accordingly because effectively that's exactly what they are.
You don't know what you're talking about if you think the US is any comparison to China.
I don't think that.
Read a book. Check out the rest of the internet.
Curious, this site also suggested I read a book. http://hmpg.net/
Are you sitting in the UK with your smug attitude? Where cameras follow you everywhere, you can be jailed for an internet post, and on even the simple appearance of having offended someone? If so, it's no wonder you love China so much with their social scoring, political disappearances, inability to actually own any of your own property, inability to talk about an increasing range of topics.
Honestly I just believe if your going to BDS everything you don't like it's prudent to look in the mirror first. That's all.
And lo and behold unix time was updated to 64 bits years ago, so 2038 isn't an issue. The only unix things that will hit that wall are things that are either not dynamic (scripting language) or can't be recompiled with the 64 bit time_t size.
Some have addressed the problem long ago. For example Microsoft fixed visual studio over a dozen years previous to have time_t be 64 bit for 32-bit and 64-bit software.
Others have elected to do nothing. time_t is still 32 bit in present day 32-bit Linux systems.
Dude, your comment is 4 years too late. Google released its Hardware abstraction layer with Android version 8, it's now on Version 9, and yes, current phones get security updates very quickly from reputable vendors.
This month, my non-google phone got the February patch update a few hours before the Pixel release was available.
In what year I will be able to install a generic Linux or Android distro on my cell phone?
In order to pass certification for things like FCC the drivers need to be certified too. If they were open source then the user could just crank up the transmit power on their cellular modem or wifi to illegal levels
This is what RIL is for. Cell phones communicate with baseband processor using a standardized interface so the argument makes no sense on its face as the OS does not have the capability to command baseband to do something it isn't willing to.
The argument is further frustrated by the fact anyone can buy a USB stick with a GSM radio in it or a laptop with similar hardware to communicate over cellular networks. Yet the presence of such hardware does not preclude the successful installation of generic Linux distros nor detract from the ability to communicate with said radio.
This affects the x86 world too. Some laptops have a list of acceptable wifi cards baked into the BIOS. If you try to fit a non-certified one it won't work. Reason being that when you have 3 antennas they could potentially all be used to exceed acceptable transmission power limits if the user fits any random card, so the manufacturer has to limit to ones tested by the FCC etc. to never do that.
The FCC explicitly rejected this assertion. Systems need to be designed such that the radio interface cannot be commanded to exceed limits / bypass TDR detection..etc. They never said the entire operating system has to be locked down to achieve this.
Having said that, Google has largely fixed this now. Modern versions of Android can be patched by the Play Store services directly
No, Google play cannot update the operating system. They can only update shit that used to be part of Android but got moved into proprietary Google play malware stack as part of Google's never ending bid to own everything.
Given USA is the worlds top jailer and starter of elective never ending wars costing hundreds of thousands of lives I'm down with BDS China so long as the rest of the world does the same to the United States.
Why can't non-x86 world ever get its shit together? One unified Windows or Linux image installs on countless hundreds of different x86 things.
Meanwhile everywhere else it's always bake a custom rom specific to each and every variant of every device. Why is it still tolerated? The old excuses of abstraction costing too much made sense 20 years ago. Today it's a joke/lame excuse for tolerating the indefensible.
You're making a lot of unsubstantiated assumptions which implicitly assume that the developers of Chrome are idiots and don't care if people use their browser.
Well they sure are acting like idiots in this instance.
It's not at all a given that's the implicit assumption given market share enjoyed by chrome. Some may well get tired of broken sites and switch. A much more likely scenario is the user will complain to or blame the site owners and chrome gets a pass.
Slashdot Mirror
Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair.
Of course this in itself doesn't mean anything. Creation of a key pair doesn't preclude existence of parallel trust paths.
and the site you're authenticating to stores the public key.
When I login to a site using this system are you saying the sites keep a database of actual public keys and validates by matching my individual public key from that databases? It doesn't simply perform validation using something more manageable higher up trust chain?
The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware
I don't understand how this is possible. Does each piece of hardware have a factory installed key pair to establish this? What is the basis for determining security of key storage?
Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.
What is the benefit of Google's CA in the first place? What functionality is enabled that wouldn't be possible without it? Is it just this idea of proving the security of key storage and nothing else? What breaks without it?
Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.
What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.
This is a scary argument.
Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.
You are right in that this is not because they are the root CA "for much of the" web.
It's much more basic than that. It's simply because they are a CA and therefore inherently in a position to globally issue certs trusted unconditionally by all clients using the web regardless of how many customers an individual CA has.
If Google is able to do something similar WRT to authentication then it's to borrow a phrase from Joe Biden ... a big fucking deal. I would hope that Google DOES NOT have the ABILITY to bypass FIDO authenticated identity seen by applications relying on this system for authentication. If it is possible for Google to issue itself a key pair to impersonate one of my users then in fact the system is inherently broken, unfit for purpose and should not be used by anyone.
That seems to be a pretty cumbersome system for users as they would have to either pay to be recognized by a CA and/or would have to go through a rigamarole set-up procedure to install a certificate in every piece of Internet-communicating software they use.
It's not like this. The best high level explanation I can give is that client certs are like browsing to a secure site except in reverse.
When you go to https://www.reallysecuresite.o...
1. Your browser has a listed of trusted certs handed down by the CA gods.
2. www.reallysecuresite.omg has a private/public key pair blessed by CA gods.
Client certs flip this.
1. With client authentication the browser has private/public key pair blessed by www.reallysecuresite.omg.
2. www.reallysecuresite.omg has a list of trusted root certs blessed by itself.
You don't need the blessing of third party to hand out client certs. It costs you nothing and there is no disadvantage to it.
Also, what happens if that cert gets lost? Now they have to revoke it (and we all know what a joke the cert revocation system is) and go through the whole thing again...
If the client looses it's private key to authenticate to www.reallysecuresite.omg it has to petition the site for a new one if a backup is unavailable.
It's the same thing if you lose your smart card or USB yubikey. Perhaps the site allows you to login with your username and password and have a new key automatically issued to you. This obviously isn't secure but most public facing sites do garbage like this all the time because they don't care about security. They care about ease of use and not dealing with password reset and market it as a security improvement.
If the server loses its private key then it only loses the ability to issue new certificates to users without creating a new CA which is free. It continues to have the ability to authenticate existing users. A reasonable price given the scenario.
Except the crap user experience of existing cert methods. Have you used them? I've only tried to add root certs using It directions and that didn't even work the first time. And they expire so you get to juggle them manually.
All major browsers/OS have a means of importing pkcs #12 files easily without much effort. As in you save/open the pkcs 12 file and are greeted with a prompt to add it to the user certificate store. It takes seconds.
I agree this is far from ideal.. the interaction should be more user friendly/seamless/automated yet it's still very much a trivial process.
As far as generating certs and expiration policy that's all on the application server. The system we use handles this seamlessly for us while onboarding new users. I can see how people who use third party certificate enrollment tools or CLI scripts to manage this could come away thinking that this is too hard/sucks. It doesn't have to be this way... it's within the application servers ability to control.
I assume FIDO2 is a mechanism for automatic certificate agreement and distribution. So yeah... That'd be a big boon over the existing system in my experience as an attempted consumer of said system.
All the same shit (PKI) and all of the same issues. You can more or less "automatically" establish trust with either one but the resulting trust relationship will very much reflect lack of initial input effort.
I've dealt with client certs quite a bit having been a government contractor both utilizing and writing software which does CAC/PIV (i.e. client certificate) authentication. While it is an effective way to secure an endpoint, the user experience is less than ideal. Because the client cert is negotiated as part of of the TLS handshake, when it fails it is difficult to give any meaningful feedback to the user.
Most secure authentication systems only provide pass/fail feedback by design.
Here you at least have a choice. You can setup the web site to not require certificate authentication so that if authentication fails the user is given instruction on what they can do/contact to get the issue resolved.
The UI browsers present to chose a certificate is rather rudimentary and for good reason not under the control of the application developer. In addition, most browsers pin the client certificate choice for the duration of the session, so if a user accidentally chooses the wrong certificate, they have to quit out and restart their browsers.
I completely agree the client implementation sucks in many regards but these are implementation problems that can be resolved with relatively minor effort. This isn't an excuse to reinvent the wheel.
All of this is not to mention the logistical hassle of issuing certificates, maintaining a CRL, getting smart cards out to people, etc. This and the usability issues are tractable for a large organization whose users will receive training on how to deal with mutual authentication, but for the general public I think it would be kind of a non-starter.
The issues are exactly the same regardless of key based possession system you use. It's always a series of tradeoffs between ease of use and security.
You could easily automate issuing certs on first logon for normal users. CRLs can be avoided by having application server keep a list of acceptable ID's.
When it comes to public sites small UX tweaks to close the loop on initial signup/first login would provide security benefits.
In many ways 2FA is, was and always will be a non-starter for public. The public push isn't driven by security as much as it's driven by a desire for companies to minimize dealing with the headaches associated with "I forgot my password".
Client certs can be deployed in ways that makes them every bit as feckless as most public facing 2FA systems with minimal effort/change.
One big difference between client certificates and U2F keys like this is that compared to a web browser's client certificate store, a U2F key is somewhat more hardened against attempts to copy out the private key.
There is no reason keys can't be stored in security modules or "smart cards" or even USB sticks for those dumb enough to require the security nightmare that is USB for user authentication.
The other is that TLS client authentication have been a usability nightmare, particularly for non-technical users, in "all major browsers since the beginning of time itself."
So instead of addressing usability problems the answer is to create an entirely new incompatible protocol? Fuck that. I use client certs every day and it's no more of a usability nightmare than HTTP authentication.
No obvious button to "sign out" (use no client certificate) in order to retrieve a logged-out view of a resource or to switch between certificates associated with different user accounts.
This is impossible to fix right? A completely new protocol is required to address this because browsers don't offer obvious sign out buttons for certificate and http auth.
Backing up certificates and moving them among devices isn't easy.
This is nonsense. All systems require a key to work. Whether on a USB stick or a smart card or embedded in a computers security module it's the same issue. Nothing prevents portability and regardless of which one you select the same keying material is being guarded.
Certificates aren't associated to a domain. If the user uses the same certificate on all sites, this isn't quite as bad as sharing a password, but it does have the same cross-site tracking implications as third-party cookies. If the user uses a different certificate on each site, major browsers traditionally haven't helped the user figure out which certificate goes with each site
They are not domain based they are signer based. The proper certificate is generally always selected automatically based on who signed it in the first place unless there is a name collision with signer in which case a list of matching client certs are displayed. In no entirely preventable event are users given an infinite list of certs to choose from only the matching list.
Users on a per domain basis existing browsers can be configured prompt whether or not to use a cert to mitigate usage as tracking mechanism.
It would also be trivial to add constraints to client certs which limit domain applicability. There is no reason to invent a new standard.
Browser publishers haven't prioritized improving client certificate UX because of the low user base of client certificates. I've seen them on only two sites: StartCom (a defunct TLS CA) and Kount (an e-commerce fraud risk assessment platform).. But browsers could improve this UI in a few ways
This is commonly used by "enterprise" systems rather than customer facing web sites.
How about you design your FIDO2 thing to automatically type passwords into regular password fields instead of asking the whole web to change for your new special feature?
I agree FIDO is redundant. It brings nothing useful to the table client certs don't already provide. Any existing UX issues with deployment and management could be addressed instead of attempting to create completely new and redundant standards.
That said there are few things as deleterious to the continued security of Internet users today than "regular password fields". Continuing to allow insecure authentication as if it's somehow acceptable (Bu....uuu....ttt.. TLS..!!) results in millions falling victim to phishing campaigns that don't need to.
The fact is that the whole web must change because the whole web is "doing it wrong". Every last site on the Internet with a web login form asking for a password needs to change.
A technology that has been supported by all major browsers since the beginning of time itself.
This advice is ridiculous, dangerous and irresponsible. DRC should know better.
Global deployment of DNSSEC without first addressing underlying transport issues (DNS over UDP without DNS cookies (RFC7873)) is guaranteed to have disastrous impacts on the availability of DNS itself and the Internet generally.
Until you learn that they all have a cam... Honestly, privacy is an illusion no matter where you go.
We're fucked anyway so nothing matters? Is that right?
We're all going to die what difference does it make if airlines maintain their aircraft? A sufficiently resourced actor could throw me off the plane without a parachute so what's the point in caring about flight safety?
A sufficiently resourced actor will always be able to get footage of you picking your nose, scratching yourself, or fondling your seatmate.
How would this line of argument ever be falsified?
You seriously seem to be asserting that something COULD happen therefore nothing matters and further caring about the issue at all is pointless as a result.
Airlines might be injecting cameras up our noses but so what? A sufficiently resourced actor could inject a camera up my nose so no big deal right?
Even if you didn't actually do any of those things, there's always deepfakes. It
And aliens... what possible relevance is there between the specific issue of cameras in seats and deepfakes?
might offend your sensibilities, but it's a reality that you're probably going to want to get comfortable with lest you be driven mad by it.
Madness is typically what results when a sufficient number of people fail to sufficiently assert their rights and stand up for themselves and their interests.
I'm honestly not worried in the slightest about someone having a video of me being bored and uncomfortable for 9 hours at a time.
Personally I find it unacceptable. Way too creepy.
I guess if someone is really concerned about this they can always travel with a roll of electrical tape.
Easier to simply chose a different airline.
There is no organization more corrupt or deleterious to the continued operation of the network than ICANN. They stopped giving a fuck about best interests of the network decades ago.
Today they care only about themselves making money from proliferation of TLDs which serves no useful purpose other than assisting phishers and exposing Internet users to unnecessary risk of collision with common internal naming schemes.
It's time for wholesale change within ICANN. Leadership needs to be replaced with a structure that is accountable to the Interests of the network rather than themselves.
Sounds to me the problem isn't capitalism so much as it's lazy people (e.g. Bankers) who believe after they produce something they are entitled to sit idle and keep getting paid for doing nothing in return.
Can't be done. Visa, Mastercard, and Amex all have clauses forbidding those cash discounts, which can cause a merchant's account to be pulled.
This has already been settled in the courts. Credit card companies can't prevent merchants from charging customers transaction fees for using credit cards.
Sooner US market gets pissed off enough at visa/mc duopoly with their in your face brazen market collusion and security nightmare 'take' rather than 'give' models and instead move to something half way rational like SWIFT instant payments the better off we will all be.
NTLM, NTLMv2 and yes Kerberos are all HOPELESSLY insecure CHAP based authentication protocols subject to offline brute force campaigns simply by way of an adversary eavesdropping on authentication process. No server hacking required.
Microsoft STILL insists upon using this crap in its current software when secure alternatives are readily available.
The only way authentication works in practice today is by protecting authentication exchanges using PKI... similar in concept to all of the web login forms on present day websites. (phishers paradise)
As for stored credentials... Salting and amplification make password guessing harder.. (persistence of NTOWF is unnecessarily sad) but not in any meaningful way that would do much to limit effective impact in the event of hash table compromise. With hashes for any number of accounts compromised an attacker with access to salted amplified hashes using present day resources is still assured meaningful victory no matter what.
As policy you are way better off treating hashes as plaintext password lists and acting accordingly because effectively that's exactly what they are.
You don't know what you're talking about if you think the US is any comparison to China.
I don't think that.
Read a book. Check out the rest of the internet.
Curious, this site also suggested I read a book.
http://hmpg.net/
Are you sitting in the UK with your smug attitude? Where cameras follow you everywhere, you can be jailed for an internet post, and on even the simple appearance of having offended someone? If so, it's no wonder you love China so much with their social scoring, political disappearances, inability to actually own any of your own property, inability to talk about an increasing range of topics.
Honestly I just believe if your going to BDS everything you don't like it's prudent to look in the mirror first. That's all.
Signed int is 32 bits.
Relevance?
Y2038 exists because people elected to use only 31-bits to address time.
Using 32-bits to address time delays run out until 2106.
They went with signed because it makes it possible to detect overflows because the number goes negative
This line of thought was a bad idea then. Today it amounts to nothing short of willful negligence.
And lo and behold unix time was updated to 64 bits years ago, so 2038 isn't an issue. The only unix things that will hit that wall are things that are either not dynamic (scripting language) or can't be recompiled with the 64 bit time_t size.
Some have addressed the problem long ago. For example Microsoft fixed visual studio over a dozen years previous to have time_t be 64 bit for 32-bit and 64-bit software.
Others have elected to do nothing. time_t is still 32 bit in present day 32-bit Linux systems.
With Unix they didn't really pick 32 bits as being "good enough", it was just the largest they could easily handle at the time.
They didn't pick 32 bits they picked 31.
Dude, your comment is 4 years too late. Google released its Hardware abstraction layer with Android version 8, it's now on Version 9, and yes, current phones get security updates very quickly from reputable vendors.
This month, my non-google phone got the February patch update a few hours before the Pixel release was available.
In what year I will be able to install a generic Linux or Android distro on my cell phone?
In order to pass certification for things like FCC the drivers need to be certified too. If they were open source then the user could just crank up the transmit power on their cellular modem or wifi to illegal levels
This is what RIL is for. Cell phones communicate with baseband processor using a standardized interface so the argument makes no sense on its face as the OS does not have the capability to command baseband to do something it isn't willing to.
The argument is further frustrated by the fact anyone can buy a USB stick with a GSM radio in it or a laptop with similar hardware to communicate over cellular networks. Yet the presence of such hardware does not preclude the successful installation of generic Linux distros nor detract from the ability to communicate with said radio.
This affects the x86 world too. Some laptops have a list of acceptable wifi cards baked into the BIOS. If you try to fit a non-certified one it won't work. Reason being that when you have 3 antennas they could potentially all be used to exceed acceptable transmission power limits if the user fits any random card, so the manufacturer has to limit to ones tested by the FCC etc. to never do that.
The FCC explicitly rejected this assertion. Systems need to be designed such that the radio interface cannot be commanded to exceed limits / bypass TDR detection..etc. They never said the entire operating system has to be locked down to achieve this.
Having said that, Google has largely fixed this now. Modern versions of Android can be patched by the Play Store services directly
No, Google play cannot update the operating system. They can only update shit that used to be part of Android but got moved into proprietary Google play malware stack as part of Google's never ending bid to own everything.
Given USA is the worlds top jailer and starter of elective never ending wars costing hundreds of thousands of lives I'm down with BDS China so long as the rest of the world does the same to the United States.
Why can't non-x86 world ever get its shit together? One unified Windows or Linux image installs on countless hundreds of different x86 things.
Meanwhile everywhere else it's always bake a custom rom specific to each and every variant of every device. Why is it still tolerated? The old excuses of abstraction costing too much made sense 20 years ago. Today it's a joke/lame excuse for tolerating the indefensible.
Wwwwaaaaayyyy past time to fire the cooks.
You're making a lot of unsubstantiated assumptions which implicitly assume that the developers of Chrome are idiots and don't care if people use their browser.
Well they sure are acting like idiots in this instance.
It's not at all a given that's the implicit assumption given market share enjoyed by chrome. Some may well get tired of broken sites and switch. A much more likely scenario is the user will complain to or blame the site owners and chrome gets a pass.