Most of the components still come from China though. Assembly is not where most of the value sits. So GoPro will have long supply lines for the components.
I was blacklisted years ago by David Miller from contributing to the kernel, and from contributing to every other project that user vger as its mailing list server, for calling David out on his use of the word "jackass" in his review of a patch submitted by another contributor. David Miller is the vger admin.
This issue affects not only Linus but several of his lieutenants as well.
As in certain other fields of engineering, the regulatory tests are sadly inadequate at determining whether a product will meet real-world requirements. The particular shortcoming I'm thinking of in this context is the fact that the susceptibility test has to be run at frequencies that stop well short of either of the main wifi frequency bands. (From memory: only up to 1.2GHz or so). The standard also describes a test at higher frequencies which include both of the wifi bands but it is optional.
I learned the ropes being a Point, then became a Node (2:292/853) and was briefly even the Region 29 Coordinator (2:29/0). That was before I was conscripted into the army.
These attacks cause service outages because legitimate DNS lookups can't be handled by the servers that are under attack (which I'm assuming here to be the authoritative name servers for the domains that are experiencing service outages). Most users don't ever query the authoritative servers directly; the legitimate queries come from their ISPs' resolvers, and those resolvers only query the authoritative servers if they don't already have the answer in their local cache. And that only happens (in respect of popular sites) when the cache entry's time-to-live has come and gone.
So perhaps one way of at least partially mitigating these attacks is for resolvers to hang onto cached records past their TTL and to continue serving them when the authoritative name servers are unavailable. Those resolvers will then of course need a robust alternative cache ejection policy (e.g. based on the frequency with which an expired record continues to be used, how overdue it is, and overall resource usage).
I do realise that Dyn is also known for their dynamic DNS service, and that the above mitigation isn't effective for ephemeral records which intentionally have a short TTL. That can't be helped.
Yes, it's more convenient to just be able to read the 3-digit code from the card without the need for an additional device.
But it's less secure than using a card reader because (1) the 3-digit code is a lot shorter than the 8 digits the card reader I described generates, (2) it still does not protect against card theft, since anyone who has the card also has the 3-digit code, and (3) it does not validate the specific transaction, it only demonstrates that the card is in possession of the person who's trying to make payment (modulo no. 1 above) at about the time the transaction is attempted.
Chip and PIN transactions are definitely possible online.
My bank issued me with a small hand-held card reader. In order to validate an online transaction I insert my card into it, type the PIN, followed by one or more challenges (such as the amount and possibly the account number of the payee). The card reader then gives me a number to key into the website as proof that I have the card and know the PIN.
This is fully integrated into online payment handlers' systems such as Ogone, Sofort and others.
Slashdot Mirror
This is the case already. Standards-essential patents must be licensed at FRAND (fair, reasonable and non-discriminatory) terms.
Most of the components still come from China though. Assembly is not where most of the value sits. So GoPro will have long supply lines for the components.
I was blacklisted years ago by David Miller from contributing to the kernel, and from contributing to every other project that user vger as its mailing list server, for calling David out on his use of the word "jackass" in his review of a patch submitted by another contributor. David Miller is the vger admin. This issue affects not only Linus but several of his lieutenants as well.
I'm afraid it also demonstrates a lack of understanding as to what constitutes culture.
As in certain other fields of engineering, the regulatory tests are sadly inadequate at determining whether a product will meet real-world requirements. The particular shortcoming I'm thinking of in this context is the fact that the susceptibility test has to be run at frequencies that stop well short of either of the main wifi frequency bands. (From memory: only up to 1.2GHz or so). The standard also describes a test at higher frequencies which include both of the wifi bands but it is optional.
I learned the ropes being a Point, then became a Node (2:292/853) and was briefly even the Region 29 Coordinator (2:29/0). That was before I was conscripted into the army.
These attacks cause service outages because legitimate DNS lookups can't be handled by the servers that are under attack (which I'm assuming here to be the authoritative name servers for the domains that are experiencing service outages). Most users don't ever query the authoritative servers directly; the legitimate queries come from their ISPs' resolvers, and those resolvers only query the authoritative servers if they don't already have the answer in their local cache. And that only happens (in respect of popular sites) when the cache entry's time-to-live has come and gone.
So perhaps one way of at least partially mitigating these attacks is for resolvers to hang onto cached records past their TTL and to continue serving them when the authoritative name servers are unavailable. Those resolvers will then of course need a robust alternative cache ejection policy (e.g. based on the frequency with which an expired record continues to be used, how overdue it is, and overall resource usage).
I do realise that Dyn is also known for their dynamic DNS service, and that the above mitigation isn't effective for ephemeral records which intentionally have a short TTL. That can't be helped.
Yes, it's more convenient to just be able to read the 3-digit code from the card without the need for an additional device. But it's less secure than using a card reader because (1) the 3-digit code is a lot shorter than the 8 digits the card reader I described generates, (2) it still does not protect against card theft, since anyone who has the card also has the 3-digit code, and (3) it does not validate the specific transaction, it only demonstrates that the card is in possession of the person who's trying to make payment (modulo no. 1 above) at about the time the transaction is attempted.
Chip and PIN transactions are definitely possible online. My bank issued me with a small hand-held card reader. In order to validate an online transaction I insert my card into it, type the PIN, followed by one or more challenges (such as the amount and possibly the account number of the payee). The card reader then gives me a number to key into the website as proof that I have the card and know the PIN. This is fully integrated into online payment handlers' systems such as Ogone, Sofort and others.