The way it works is that accelerometers, gyroscopes and magnetometers all have some degree of systematic error from the manufacturing process so phone makers calibrate them at the factory. This attack is able to derive the calibration values from about 1 second of sensor data. As these values are unique to each phone, they can form a fingerprint that's impossible to erase or alter.
That’s a really neat trick but actually not so obscure. I would have thought Apple would catch it, this is actually a huge miss by their security team. It’s not the first abuse of browser APIs used to fingerprint a device (e.g. Battery API) and won’t be the last.
Any kind of ability to sample data from a device should be thoroughly analyzed for fingerprinting side-channels as part of the underlying specification as a mandatory section. Is this not actually done?
Is there any kind of similar calibration that is done on thr camera sensor (e.g. for color correction) that can be teased out of the resultant
image files? What about in RAW mode?
How about a sound recording? Does the microphone have any kind of correction factors you might be able to observe somehow?
Similarly for color temperature of the screen. Maybe there is an unexpected side-channel to get at those correction values as well, although this one seems trickier because how would you sample the screen output remotely?
The distinction with accelerometer data is that some platforms do not require the user to grant permission to access, as opposed to camera/microphone access.
Apparently, prior to iOS 12.2, Apple did not require the user to grant a website permission to access motion & orientation sensor data [1]. They have since introduced an off-by-default toggle to globally enable access to this sensor data. Unfortunately, it seems to be all-or-nothing - if you want to allow any site access to this data, you need to allow every site access to this data. Hopefully this is a temporary band-aid fix and Apple will introduce per-site permission a la camera/microphone/location permission prompts.
I wonder if any other data sources exist which don’t require user permission.
> I wonder if any other data sources exist which don’t require user permission.
There really should not. Apple should know better than this and give these sensors the same permission requirements as direct GPS location, i.e. per app / per website.
I wonder if this could be used to verify a device is who it claims to be, like an alternative MAC with additional security by obscurity. It seems like it'd be useful for apps like password managers or OTP/2FA, though I know next to nothing about this stuff.
Pixel phones are also affected (and probably many others), and Google did not publicly patch them 163 days after disclosure.
To be fair, Apple had a 129 days head start, and took 234 days to issue a fix:
> How did vendors respond to this attack?
> We followed a coordinated disclosure procedure and reported this vulnerability to Apple on 3rd August 2018. On iOS 12.2, Apple adopted our suggestion and added random noise to the ADC outputs (CVE-2019-8541). Apple also removed access to motion sensors from Mobile Safari by default. This vulnerability was disclosed to Google on 10th December 2018. Google has contacted us and is investigating this issue.
The Pixel fingerprints aren't as unique since only the accelerometer is factory calibrated.
>In the case of iOS devices, the SensorID includes both the calibration fingerprint of the gyroscope (GyroID) and magnetometer (MagID). In the case of Google Pixel 2 and 3, the SensorID includes the calibration fingerprint of the accelerometer (AccelID).
You can also stop websites from doing this by turning off JS in browsers like Firefox Focus or using something like NoScript.
>We only have access to a few Pixel devices,and therefore we are unable to perform the same analysis as we have done on iOS devices to determine whether the fingerprint we obtain for Pixel devices is globally unique or not. The IMU in other Android devices is also likely factory calibrated but the calibration is typically restricted to offsets(i.e., bias compensation). Our approach targets the gain matrix and cannot recover bias compensation.
If you want "to be fair", why not mention all these details too?
Recall that our approach to recover the gain matrix is based on the fact that the values in the ADC output, A, are all integers. This property allows us to recover the values of ΔA using Equation 6. However, if we add random noise ε ∈ R3×1, from the uniform distribution in the range [−0.5, 0.5], to each ADC output A. Then we have:
O = G(A + ε) + B (12)
It is clear to see that the application of random noise with distribution ε ∼ U (−0.5, 0.5) followed by a truncation of the output down to 16-bit resolution means there is no easy way to recover the values of ΔA. Therefore, attackers can no longer generate the SENSORID using the approach described in this paper. The cost of adding ε is negligible in most cases, but it offers significant advantages in terms of user privacy.
Alternatively, we could round the factory calibrated sensor output to the nearest multiple of the nominal gain to prevent recovering the gain matrix. This approach is more practical to apply and it does not require knowing the gain matrix in advance. Therefore, mobile browsers can adopt this approach to protect user privacy.
I’ve generally considered websites being able to access gyroscope data without asking to be surprising and invasive: why isn’t there a permission prompt before Safari provides access to this?
I think it's a case of "what's the worst that could happen?", because apart from a site detecting that you're reading it walking around maybe I can't think of anything either.
"However, a study shows that motion sensor data is accessed by 2,653 of the Alexa top 100K websites, including more than 100 websites exfiltrating motion sensor data to remote servers."
12.2 is the release that mitigated this attack. So 12.2 also contains random noise in the sensor data - releases before this did not disable it by default (according to the article).
There are a few comments about the fear that many of the top websites of the world get/use this data. I understand that people would be scared about this.
However, fraud is big problem, and any site that is dealing with anything precious is (hopefully) doing whatever they can to prevent fraud to protect their and your resources/data. From what I can tell from the JavaScript from some of the top 100 sites, it looks like many are using this data, and if the data is not what they expect, the transaction can be rejected.
I do not like when a company like Facebook would use this data, but it is a tradeoff for allowing other companies to use it.
Not sure if someone from CloudFlare, Akamai, or another company (Coinbase?) can publicly comment on what they do.
Would be nice if the browsers would at least notify of its use.
Fraud can be solved by having proper authentication solutions in place. We shouldn't leave fingerprinting vulnerabilities open just because the banking industry can't be bothered to come up with something better than a static card number & expiry date for authentication.
I agree that just using a credit card number and the expiry date is definitely bad, but I am not aware of any authentication solution that fully solves this problem (but please enlighten me if there is).
We know passwords have many problems.
Two factor authentication with SMS has problems with SIM hijacks.
Physical tokens (e.g. RSA tokens) have problems when users lose them.
Feel free to enlighten me if someone has a better solution for all of this.
Ironically, both iOS and Android have payment solutions built in, and on Apple devices this uses the secure enclave. Fingerprinting a phone is a vastly inferior solution to that.
Which is useful if you happen to live in an Apple Pay / Android Pay supported country with contactless payment widely rolled out.
However, considering contactless was pretty rare even in the US until recently, it’s wise to have other solutions - and cover other use cases like online banking, loan applications etc etc.
In the real world people seem to hold onto their cards pretty well - why not just use that? The majority of phones nowadays has an NFC chip capable of talking to contactless-enabled cards (most of them), and for those that don't, smartcard readers are pretty cheap (banks give out those calculator-like things for logins, why not add an USB port to them or Bluetooth capability for mobile devices).
2-factor authentication doesn't necessarily imply SMS. TOTP apps like Google Authenticator are reasonably secure.
Finally auth doesn't have to be 100% bulletproof (in fact, fingerprinting isn't either), it just has to solve the majority of problems. There's always someone that's going to be stupid enough to get compromised despite all the security solutions, but as long as the majority of users is safe then all is good.
I can. During a short stint in an ad tech company in Shanghai in 2016 (my second time in ad tech after running an ad farm myself in my teen years), I noticed that Samsung Internet (a browser) does not require permission for sensor data. Then, just few month later, Chrome team put sensors live without them too.
I remembered reading about Kalman techniques used in radionav in high school, and it instantly came into my head that you can as easily reverse the process to substract clean, kalman filtered, signal from noisy one to get an "anti-pattern."
And with it you can easily do whatever you want from FFT, to reverse manchester coding, to more esoteric techniques to quantitise it.
Everybody in the collective got quite fired up with it, thinking about it being a "that's it" moment for us to do some sweet arbitrage on ad exchanges with it. We were few weeks from filling a patent, but it was decided to keep it hidden after all with logic that: 1. big ads will shoot us down, 2. botters will get whiff of it, 3. patents don't work for "small" companies
I got symbolic premium, arbitrage results were far from super good as originally expected. At that point we found a silly thing: 20 to 30% of MoPub traffic had accelerometers and gyros playing same data in a 5 second loop!
Later after I left the company, I learned of ours sales people finally managing to sell it under wraps to "somebody big" , whose identity I was not told
I do remember right around that time flaming on bugzilla with either google or mozilla employees who claimed that you can't extract fingerprint from 60 hz data, and me claiming otherwise to no avail.
My point was to put mandatory permission prompt on it, and I remember being turned down.
"Fraud" presupposes a surveillance advertising ecosystem. The data is not being used to verify transactions, but to figure out if your ad impression should count as bogus or real. Change the business model and a lot of incentive for this highly invasive tracking goes away.
Note: If on an iPhone with iOS 12.2+. This attack has been mitigated by Apple adding random noise to the sensors and disabling motion api access in safari by default.
I’m still surprised this wasn’t caught sooner as many techniques have been used over the years to effectively fingerprint devices.
How accurate are these types of sensors and how unique are an individual's tremors? Given a long enough scan period is it possible to uniquely identify someone just from their grip (not just device calibration data per this attack)?
Does anyone know of websites that make genuine use of motion sensor data? It'd be interesting to read about why the Safari Motion API came about in the first place.
They should, but they won't. Apple's whole "It Just Works" pitch is predicated on them controlling the entire stack. The browser is such an important layer of that stack these days that if they yielded that layer to third parties it'd inevitably lead to cases where some popular third party browser didn't work right with some sites or some other elements of Apple's stack. Which they don't want, because it undermines their entire strategic raison d'être.
Alternate browsers are at least available in the "Share" menu throughout iOS. Some apps (e.g. Wire) allow the user to define the default browser for opening links. It's mainly the Apple apps (like Mail) which force the use of Safari.
Someone commented on HN recently about an app that lets you do this.. you install it, remove Safari, and then it get's launched and then launches your browser.
Unfortunately I am having trouble finding the name of it now.
This seems highly optimistic. I would assume the opposite, that we will look back and wish for the days when the worst we could expect is device fingerprinting through the gyroscope API.
The constant downvotes and endless snarky comments that ignore the fact that 2 of the biggest companies on the planet are ad networks which have provided tremendous value to both customers and shareholders, and are a key ingredient in the marketing and growth of basically every business.
The ignorance that advertising itself is a fine model that subsidizes 99% of the content on the internet and allows for fast, easy, and egalitarian access for billions of people, as well as increased opportunity for creators of all kinds.
And finally the obliviousness to the technical and business solutions that already exist to make the experience better instead of going down an endless arms race where nobody wins.
>The constant downvotes and endless snarky comments that ignore the fact that 2 of the biggest companies on the planet are ad networks which have provided tremendous value to both customers and shareholders, and are a key ingredient in the marketing and growth of basically every business.
I think wording it as "tremendous value" is a stretch but that's just me. Also, businesses are fully able to grow without the likes of the two biggest companies. So, not every business has those companies as a key ingredient. It's not a "too big too fail", doomsday scenario, where the (business) wold is entirely dependent on the two companies to exist, yeah?
>The ignorance that advertising itself is a fine model that subsidizes 99% of the content on the internet and allows for fast, easy, and egalitarian access for billions of people, as well as increased opportunity for creators of all kinds.
You're delineating in your own retort and creating double-speak. Advertising, as a whole, can be fine but the two aforementioned companies can be total shit. That doesn't create a dichotomy or ignorance.
You're already speaking about your audience as unwilling to view your arguments but you treat them as ignorant, which means you're unwilling to be malliable in your own view and see it from their perspective. Isn't that ignorance, in and of itself? :)
>And finally the(y are) obliviousness to the technical and business solutions that already exist to make the experience better instead of going down an endless arms race where nobody wins.
I don't think taking a stance that your solutions are the only ones that work and because no one will accept them, it's an arms race to the bottom is conducive to anything. If anything, that leads directly to your aforementioned arms race to the bottom.
To spin it a different way and benefit your supposed enemy in discourse: Advertising markets worked fine before the two big companies, yeah? The internet still existed? Pages were able to be reached in a fast, easy, egalitarian, and free way, yeah?
Aside from that model being "dead", simply because it's no longer used, why do you believe that this is such an implicitly binary situation of the two companies must exist and be allowed free rampant growth or nothing at all?
I hope that you take this as constructive criticism but it would seem to me, from this exchange, that it's you who's coming to these conversations not willing to listen.
You focused entirely on the companies. That's not the point at all.
Advertising is a core part of the marketing necessary to grow a business and thus a core part of the overall economy. It will always exist and be served by major companies from the sheer size of the total spend, whether it's Google and Facebook or someone else. And advertising is the only model that has paid for the vast majority of commercial content online today, and is incomparable to some time in the past where that didn't exist.
You can search my name if you want the background [1] because I'm not what you assume I am. Regulation and privacy are not the problem, it's the lack of any cooperation and workable solutions. Adtech looks for efficiency, not more workarounds to battle giant corporations like Apple which ignore industry concerns while being contradictory in their own actions.
The way it works is that accelerometers, gyroscopes and magnetometers all have some degree of systematic error from the manufacturing process so phone makers calibrate them at the factory. This attack is able to derive the calibration values from about 1 second of sensor data. As these values are unique to each phone, they can form a fingerprint that's impossible to erase or alter.
That’s a really neat trick but actually not so obscure. I would have thought Apple would catch it, this is actually a huge miss by their security team. It’s not the first abuse of browser APIs used to fingerprint a device (e.g. Battery API) and won’t be the last.
Any kind of ability to sample data from a device should be thoroughly analyzed for fingerprinting side-channels as part of the underlying specification as a mandatory section. Is this not actually done?
Is there any kind of similar calibration that is done on thr camera sensor (e.g. for color correction) that can be teased out of the resultant image files? What about in RAW mode?
How about a sound recording? Does the microphone have any kind of correction factors you might be able to observe somehow?
Similarly for color temperature of the screen. Maybe there is an unexpected side-channel to get at those correction values as well, although this one seems trickier because how would you sample the screen output remotely?
Dust or other scratches on taken pictures can be a side channel. See the previous discussion: https://news.ycombinator.com/item?id=18835377
The distinction with accelerometer data is that some platforms do not require the user to grant permission to access, as opposed to camera/microphone access.
Apparently, prior to iOS 12.2, Apple did not require the user to grant a website permission to access motion & orientation sensor data [1]. They have since introduced an off-by-default toggle to globally enable access to this sensor data. Unfortunately, it seems to be all-or-nothing - if you want to allow any site access to this data, you need to allow every site access to this data. Hopefully this is a temporary band-aid fix and Apple will introduce per-site permission a la camera/microphone/location permission prompts.
I wonder if any other data sources exist which don’t require user permission.
[1] https://www.macrumors.com/2019/02/04/ios-12-2-safari-motion-...
> I wonder if any other data sources exist which don’t require user permission.
There really should not. Apple should know better than this and give these sensors the same permission requirements as direct GPS location, i.e. per app / per website.
I wonder if this could be used to verify a device is who it claims to be, like an alternative MAC with additional security by obscurity. It seems like it'd be useful for apps like password managers or OTP/2FA, though I know next to nothing about this stuff.
It wouldn't add much security. If any web page can read the configuration data, an attacker can capture it by tricking you into opening a web page.
Pixel phones are also affected (and probably many others), and Google did not publicly patch them 163 days after disclosure.
To be fair, Apple had a 129 days head start, and took 234 days to issue a fix:
> How did vendors respond to this attack?
> We followed a coordinated disclosure procedure and reported this vulnerability to Apple on 3rd August 2018. On iOS 12.2, Apple adopted our suggestion and added random noise to the ADC outputs (CVE-2019-8541). Apple also removed access to motion sensors from Mobile Safari by default. This vulnerability was disclosed to Google on 10th December 2018. Google has contacted us and is investigating this issue.
https://sensorid.cl.cam.ac.uk/
The Pixel fingerprints aren't as unique since only the accelerometer is factory calibrated.
>In the case of iOS devices, the SensorID includes both the calibration fingerprint of the gyroscope (GyroID) and magnetometer (MagID). In the case of Google Pixel 2 and 3, the SensorID includes the calibration fingerprint of the accelerometer (AccelID).
You can also stop websites from doing this by turning off JS in browsers like Firefox Focus or using something like NoScript.
>We only have access to a few Pixel devices,and therefore we are unable to perform the same analysis as we have done on iOS devices to determine whether the fingerprint we obtain for Pixel devices is globally unique or not. The IMU in other Android devices is also likely factory calibrated but the calibration is typically restricted to offsets(i.e., bias compensation). Our approach targets the gain matrix and cannot recover bias compensation.
If you want "to be fair", why not mention all these details too?
Thanks for the additional details.
How well does random noise work? With enough samples, and a fixed phone, the randomness will average out, no?
Hopefully the random value isn’t being changed for each sample, but every minute or hour or such.
They can only add so much noise before impacting the actual results, right?
Details in the research paper[1]:
Recall that our approach to recover the gain matrix is based on the fact that the values in the ADC output, A, are all integers. This property allows us to recover the values of ΔA using Equation 6. However, if we add random noise ε ∈ R3×1, from the uniform distribution in the range [−0.5, 0.5], to each ADC output A. Then we have:
O = G(A + ε) + B (12)
It is clear to see that the application of random noise with distribution ε ∼ U (−0.5, 0.5) followed by a truncation of the output down to 16-bit resolution means there is no easy way to recover the values of ΔA. Therefore, attackers can no longer generate the SENSORID using the approach described in this paper. The cost of adding ε is negligible in most cases, but it offers significant advantages in terms of user privacy.
Alternatively, we could round the factory calibrated sensor output to the nearest multiple of the nominal gain to prevent recovering the gain matrix. This approach is more practical to apply and it does not require knowing the gain matrix in advance. Therefore, mobile browsers can adopt this approach to protect user privacy.
1. https://www.ieee-security.org/TC/SP2019/papers/405.pdf
I would like details, but I am sure the thought it through.
Mods: suggestion to update to the URL and title of the above site. The submitted link provides little beyond a link to the research paper.
> Apple adopted our suggestion and added random noise to the ADC outputs
It will not stop Kalman filter
Just axe it away Apple
I’ve generally considered websites being able to access gyroscope data without asking to be surprising and invasive: why isn’t there a permission prompt before Safari provides access to this?
According to the standard, there should be: https://developer.mozilla.org/en-US/docs/Web/API/Sensor_APIs...
I don't understand why it wouldn't be happening in practice.
I think it's a case of "what's the worst that could happen?", because apart from a site detecting that you're reading it walking around maybe I can't think of anything either.
Real link with more information: https://sensorid.cl.cam.ac.uk/.
"However, a study shows that motion sensor data is accessed by 2,653 of the Alexa top 100K websites, including more than 100 websites exfiltrating motion sensor data to remote servers."
This is scary.
Settings > Safari > Motion & Orientation Access to disable this for iOS. I think it's disabled by default.
Correct. It is disabled on a brand new iOS 12.2 install.
12.2 is the release that mitigated this attack. So 12.2 also contains random noise in the sensor data - releases before this did not disable it by default (according to the article).
The option isn't present on iOS 12.1.4, the previous version.
There are a few comments about the fear that many of the top websites of the world get/use this data. I understand that people would be scared about this.
However, fraud is big problem, and any site that is dealing with anything precious is (hopefully) doing whatever they can to prevent fraud to protect their and your resources/data. From what I can tell from the JavaScript from some of the top 100 sites, it looks like many are using this data, and if the data is not what they expect, the transaction can be rejected. I do not like when a company like Facebook would use this data, but it is a tradeoff for allowing other companies to use it.
Not sure if someone from CloudFlare, Akamai, or another company (Coinbase?) can publicly comment on what they do.
Would be nice if the browsers would at least notify of its use.
Fraud can be solved by having proper authentication solutions in place. We shouldn't leave fingerprinting vulnerabilities open just because the banking industry can't be bothered to come up with something better than a static card number & expiry date for authentication.
I agree that just using a credit card number and the expiry date is definitely bad, but I am not aware of any authentication solution that fully solves this problem (but please enlighten me if there is). We know passwords have many problems. Two factor authentication with SMS has problems with SIM hijacks. Physical tokens (e.g. RSA tokens) have problems when users lose them.
Feel free to enlighten me if someone has a better solution for all of this.
Ironically, both iOS and Android have payment solutions built in, and on Apple devices this uses the secure enclave. Fingerprinting a phone is a vastly inferior solution to that.
Which is useful if you happen to live in an Apple Pay / Android Pay supported country with contactless payment widely rolled out.
However, considering contactless was pretty rare even in the US until recently, it’s wise to have other solutions - and cover other use cases like online banking, loan applications etc etc.
In the real world people seem to hold onto their cards pretty well - why not just use that? The majority of phones nowadays has an NFC chip capable of talking to contactless-enabled cards (most of them), and for those that don't, smartcard readers are pretty cheap (banks give out those calculator-like things for logins, why not add an USB port to them or Bluetooth capability for mobile devices).
2-factor authentication doesn't necessarily imply SMS. TOTP apps like Google Authenticator are reasonably secure.
Finally auth doesn't have to be 100% bulletproof (in fact, fingerprinting isn't either), it just has to solve the majority of problems. There's always someone that's going to be stupid enough to get compromised despite all the security solutions, but as long as the majority of users is safe then all is good.
They are entirely separate layers. Not every service that wants to prevent fraud involves a payment transaction.
> can publicly comment on what they do.
I can. During a short stint in an ad tech company in Shanghai in 2016 (my second time in ad tech after running an ad farm myself in my teen years), I noticed that Samsung Internet (a browser) does not require permission for sensor data. Then, just few month later, Chrome team put sensors live without them too.
> https://news.ycombinator.com/item?id=18247690
I remembered reading about Kalman techniques used in radionav in high school, and it instantly came into my head that you can as easily reverse the process to substract clean, kalman filtered, signal from noisy one to get an "anti-pattern."
And with it you can easily do whatever you want from FFT, to reverse manchester coding, to more esoteric techniques to quantitise it.
Everybody in the collective got quite fired up with it, thinking about it being a "that's it" moment for us to do some sweet arbitrage on ad exchanges with it. We were few weeks from filling a patent, but it was decided to keep it hidden after all with logic that: 1. big ads will shoot us down, 2. botters will get whiff of it, 3. patents don't work for "small" companies
I got symbolic premium, arbitrage results were far from super good as originally expected. At that point we found a silly thing: 20 to 30% of MoPub traffic had accelerometers and gyros playing same data in a 5 second loop!
Later after I left the company, I learned of ours sales people finally managing to sell it under wraps to "somebody big" , whose identity I was not told
I do remember right around that time flaming on bugzilla with either google or mozilla employees who claimed that you can't extract fingerprint from 60 hz data, and me claiming otherwise to no avail.
My point was to put mandatory permission prompt on it, and I remember being turned down.
"Fraud" presupposes a surveillance advertising ecosystem. The data is not being used to verify transactions, but to figure out if your ad impression should count as bogus or real. Change the business model and a lot of incentive for this highly invasive tracking goes away.
Note: If on an iPhone with iOS 12.2+. This attack has been mitigated by Apple adding random noise to the sensors and disabling motion api access in safari by default.
I’m still surprised this wasn’t caught sooner as many techniques have been used over the years to effectively fingerprint devices.
"Apple has patched this vulnerability in iOS 12.2."
FYI
According to MDN the Sensors API requires an opt-in permission on each site that wants to use it. Does Safari grant this without asking?
https://developer.mozilla.org/en-US/docs/Web/API/Sensor_APIs...
Chrome does not
How accurate are these types of sensors and how unique are an individual's tremors? Given a long enough scan period is it possible to uniquely identify someone just from their grip (not just device calibration data per this attack)?
Does anyone know of websites that make genuine use of motion sensor data? It'd be interesting to read about why the Safari Motion API came about in the first place.
Apple should allow the user to select their default browser, e.g. Brave, which can enable Javascript on a per-site basis.
They should, but they won't. Apple's whole "It Just Works" pitch is predicated on them controlling the entire stack. The browser is such an important layer of that stack these days that if they yielded that layer to third parties it'd inevitably lead to cases where some popular third party browser didn't work right with some sites or some other elements of Apple's stack. Which they don't want, because it undermines their entire strategic raison d'être.
Alternate browsers are at least available in the "Share" menu throughout iOS. Some apps (e.g. Wire) allow the user to define the default browser for opening links. It's mainly the Apple apps (like Mail) which force the use of Safari.
Someone commented on HN recently about an app that lets you do this.. you install it, remove Safari, and then it get's launched and then launches your browser.
Unfortunately I am having trouble finding the name of it now.
We live in the wild west of data privacy and security. We'll look back one day at this time and wonder how things were so broken.
This seems highly optimistic. I would assume the opposite, that we will look back and wish for the days when the worst we could expect is device fingerprinting through the gyroscope API.
Apple making the device’s Advertising ID available to browsers would solve a lot of these tracking issues.
Killing the patient would solve a lot of their diseases.
It's the exact mechanism already used in iOS apps for a decade, approved by Apple with all the necessary controls for the user.
Of course irrationality will prevail when it comes to any comments about ads on HN though.
>Of course irrationality will prevail when it comes to any comments about ads on HN though.
Elucidation would be appreciated: How does irrationality prevail?
The constant downvotes and endless snarky comments that ignore the fact that 2 of the biggest companies on the planet are ad networks which have provided tremendous value to both customers and shareholders, and are a key ingredient in the marketing and growth of basically every business.
The ignorance that advertising itself is a fine model that subsidizes 99% of the content on the internet and allows for fast, easy, and egalitarian access for billions of people, as well as increased opportunity for creators of all kinds.
And finally the obliviousness to the technical and business solutions that already exist to make the experience better instead of going down an endless arms race where nobody wins.
>The constant downvotes and endless snarky comments that ignore the fact that 2 of the biggest companies on the planet are ad networks which have provided tremendous value to both customers and shareholders, and are a key ingredient in the marketing and growth of basically every business.
I think wording it as "tremendous value" is a stretch but that's just me. Also, businesses are fully able to grow without the likes of the two biggest companies. So, not every business has those companies as a key ingredient. It's not a "too big too fail", doomsday scenario, where the (business) wold is entirely dependent on the two companies to exist, yeah?
>The ignorance that advertising itself is a fine model that subsidizes 99% of the content on the internet and allows for fast, easy, and egalitarian access for billions of people, as well as increased opportunity for creators of all kinds.
You're delineating in your own retort and creating double-speak. Advertising, as a whole, can be fine but the two aforementioned companies can be total shit. That doesn't create a dichotomy or ignorance.
You're already speaking about your audience as unwilling to view your arguments but you treat them as ignorant, which means you're unwilling to be malliable in your own view and see it from their perspective. Isn't that ignorance, in and of itself? :)
>And finally the(y are) obliviousness to the technical and business solutions that already exist to make the experience better instead of going down an endless arms race where nobody wins.
I don't think taking a stance that your solutions are the only ones that work and because no one will accept them, it's an arms race to the bottom is conducive to anything. If anything, that leads directly to your aforementioned arms race to the bottom.
To spin it a different way and benefit your supposed enemy in discourse: Advertising markets worked fine before the two big companies, yeah? The internet still existed? Pages were able to be reached in a fast, easy, egalitarian, and free way, yeah?
Aside from that model being "dead", simply because it's no longer used, why do you believe that this is such an implicitly binary situation of the two companies must exist and be allowed free rampant growth or nothing at all?
I hope that you take this as constructive criticism but it would seem to me, from this exchange, that it's you who's coming to these conversations not willing to listen.
You focused entirely on the companies. That's not the point at all.
Advertising is a core part of the marketing necessary to grow a business and thus a core part of the overall economy. It will always exist and be served by major companies from the sheer size of the total spend, whether it's Google and Facebook or someone else. And advertising is the only model that has paid for the vast majority of commercial content online today, and is incomparable to some time in the past where that didn't exist.
You can search my name if you want the background [1] because I'm not what you assume I am. Regulation and privacy are not the problem, it's the lack of any cooperation and workable solutions. Adtech looks for efficiency, not more workarounds to battle giant corporations like Apple which ignore industry concerns while being contradictory in their own actions.
1. https://news.ycombinator.com/item?id=19593812
Apple claims that their iOS is "Secure By Design". They use that exact phrase. (See https://www.apple.com/business/resources/docs/iOS_Security_O... for example.)
Does this mean anything?
If you read the architecture security documentation, you can see the lengths they have gone to secure the whole system.
The system was built with security as a first principle, not something added after the fact.
Since humans are not perfect, you could say the statement is effectively ‘Security as a Primary Design [Goal]’.
> Following our disclosure, Apple has patched this vulnerability in iOS 12.2.