In case it's not obvious, here is how the attack works:
1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on an HSM on the device (generally called a "trusted enclave"), and signs the public key of the keypair with a master key
2. The device runs the attacker's software and is designed so that whenever non-attacker software is run with elevated privileges, the HSM is informed of that fact in a way that can't be reset without rebooting (and starting again with the attacker's software). For instance, the device might use a verified boot scheme, send the key the OS is signed with to the HSM in a way that is unchangeable until reboot, and it might employ hardening like having the CPU encrypt RAM or apply an HMAC to RAM
3. The HSM produces signatures of messages that contain statements that the device is running the attacker's software, plus whatever the attacker's software wants to communicate and it won't produce them if it's running software of the user's choice as opposed to the attacker's software as established above. It also includes the signature of its public key with the master keypair, allowing accomplices to check that the device is indeed not under the user's control, but rather under the control of someone they trust to effectively limit the user's freedom
4. Optionally, that attestation is passed through the attacker's servers, which check it and return another attestation signed by themselves, allowing to anonymize the device and apply arbitrary other criteria
5. Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker's software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice's code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.
This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.
Can I just say I appreciate the framing of this as an attack? Somehow I hadn't yet mentally filed Google and friends under "Man in the middle" but that's pretty much exactly what's going on.
This Web Integrity API is just a means to cement themselves as obligatory man in the middle, as opposed to an optional one.
Actually it would be useful to present the problem using your framing - in the press, blogs, everywhere. The other side is already bending over backwards to stretch the meaning of words (their introduction about DRM being "the backbone of the open Internet" made me me sick).
So the attacker in this scenario is producing my hardware? That sounds ridiculous, if that were the case they could do anything they want anyways, I see no way in which the scenario you've discussed is materially different from "attacker can literally do anything anyway, they own the hardware".
And this "attacker" gets... what? Nothing. Because this isn't an attacker... it's a device manufacturer. You've described how attestation works except you've described the TPM as an attacker, which is silly.
And of course the unfixable side-effect of the fact that we're ultimately sending electricity over wires:
6. Any additional party with sufficient ability to modify hardware can still attack the attacker and their accomplices. So such parties only benefit from this, at the cost of typical users.
Expected, but meaningless if we can't drive people towards Firefox and away from Chromium products. That's something of a responsibility we all have, especially those of us invested in the safety and security (collectively, trust) of the web.
I haven't seen anything yet on whether Brave will support it, though if I'm understanding correctly, they won't have a choice since they're using Chromium. Hopefully I'm misinformed.
I've said it elsewhere but folks need to use Firefox, because if everyone stops there'll be no-one with a voice to stand up to Google's BS because they OWN chrome and can do whatever they want with it.
Not saying it's perfect or better, just that we need it. we need a competing browser with a rendering engine that google doesn't ultimately control that has a non-trivial market share. Otherwise we may as well just stop complaining and let google do what it wants because we'll have no power to stop them anyway.
Isn't the majority of Mozilla's revenue from Google's paid placement as the default search engine? Or has this changed in recent years?
Quick googling confirms 50%+ of revenue came from Google 5-10 years ago, but couldn't find more recent data.
If Google is Mozilla's primary revenue source (especially if it's the majority), then Google effectively controls Mozilla via the leverage it has to pull Mozilla's largest revenue source.
Edit: Also raises the question, what company or organization should be developing browsers? A browser is something everyone expects to be free, but a browser is by no means free to develop, operate and maintain. For-profit browser companies (like Brave) would be forced to monetize the browser (like Brave tried to do with BAT crypto tokens, ads on the new tab page, etc)
Can Mozilla also respond with their position on their own IPA proposal[1] for tracking users across the Internet?
If you are shown a product ad whilst browsing searchengine.example and then later look up the product at reviews.example, then end up making a purchase at shop.example, your Mozilla browser will send all of these events to one or more aggregation services that allows shop.example to understand (at least in aggregate, assuming you trust the cartels running the aggregation services) that you were exposed to their product at searchengine.example and further exposed to their product at reviews.example.
Where previously an ad tech company was ultimately able to track users based on source IP address (even if cookies had been disabled by a user), IPA now allows these companies to track users across multiple IP addresses, and regardless of the user's cookie settings, via a unique tracking identifier. It is also proposed that the operating system provides the unique tracking identifier which can then be used by all applications or browsers on a device, allowing different devices behind a single IP address to be distinguished.
Attribution is necessary for advertising to work at all. If you don't have attribution that is independent of the ad platform you bought ads from, then the ad platform will defraud you[0]. This is separate from ad tracking where you build up interest profiles on users, or ad remarketing where sites can buy ads from people who have visited them in the past[1].
Most of these private attribution systems are specifically designed so that the people running the ad can count how many people clicked their ads, but not who clicked them or what other things they did. Safari had a proposal in which you could only have a certain number of campaigns running per domain, so you couldn't set up a separate """campaign""" for each user and fingerprint them all at once. I don't know how the Mozilla proposal differs.
Whether or not user-agents should care about this sort of thing is an orthogonal question.
[1] Remarketing in particular is responsible for the "feeling of being seen" from modern ads where you search for one thing and get 10,000 ads for the thing for the next week
To be fair, "Web Integrity" (aka remote attestation aka a corporate surveillance agent built into "your" hardware) is much more fundamental as it would prevent the running of forked browsers that remove deliberate security vulnerabilities like IPA. It's unfortunate that Mozilla "plays ball" on garbage like IPA, but at least as things stand users are free to disable/remove/fork/etc. Whereas remote attestation is fundamentally game over for the idea of user representing agents altogether.
The mobile equivalent, the play integrity API should be illegal and fought in court. I'm also pretty sure it goes against the right to repair and e-waste laws in the EU since it's whole idea is to remove third party roms.
We should start to orient the debate instead on the security issues created by Google and their ads.
I'd love to donate to Mozilla, but I'm concerned my money could just end up in some C-suite pockets if I do. Is there a way to donate specifically to Firefox core(-ish) team, and maybe also MDN?
That wouldn't make any sense from them. What good would donations for Firefox be if they can't pay the cleaning staff of their office or it's rent or the HR and accounting and legal people that keep the "Firefox core-ish team, and maybe also MDN" employed and running? Even the CEO, even if ridiculously overpaid (one can make an argument that to get a quality CEO in the US you need to pay them a lot, which I don't buy, surely there are people capable of being CEOs out there that aren't greedy as fuck and would be willing to accept a low salary of a 1-2 million $ per year) is necessary for the company, and a bad CEO can ruin them (see: GE, Enron, Boeing, Twitter, etc.).
For a "fun" example of how strict budget destination restrictions fail, take a look at Atlanta's MARTA, that used to have a fixed 50/50 budget split between OPEX and CAPEX by it's funding law, and therefore had brand new trains but everything else falling apart.
Do you do this same analysis for every purchase you make? Maybe the sandwich shop you bought lunch at used your money to buy a pizza for the owner & her wife, neither of whom worked at the store that day and made your lunch. Does that upset you? It's a business. Money comes in, money goes out, product gets made. Either pay them for the product you like, or don't. It's up to them how they use the money they get.
You can make a restricted donation to the Mozilla Foundation, and if they accept it, they're bound to the restriction unless you consent.
However, dollars are fungible. If you donate $500 to support MDN, that may replace $500 for MDN coming from revenue, which frees up $500 to go into something else, like a C-Suite's pocket, or Pocket or whatever. So while your dollars go where you said, it still enables whatever you didn't like. OTOH, if you donate $50B to support MDN, that's a bit different; it certainly frees up whatever money was going to support MDN before, but there wasn't $50B of MDN expense, so the excess beyond the needs of MDN doesn't go anywhere.
It's not a co-operative, just a non-profit. The devs are employees of the corporation just like for any other company. Honestly, I think the company makes good revenue and don't rely too much on donations. Using their products and being their customer is probably more valuable to them and their manifesto.
They might appose it, but if it ships in Chrome and starts being actively used they will also implement it, just like CDM.
At the end of the day, users will just see that a website works in Chrome and not in Firefox. Firefox will decide that there is no point in apposing it if there is a real cost in potential market-share.
There is a long history of hackers—in the classic sense—using computers to do things other people don't want them to do, and those other people unable to do anything about it (or, at best, engaging in an arms race with the hackers). This has been bad for those other people but overall very good for society. It is what birthed GNU, "IBM Compatible", ad blockers, Firefox, BitTorrent, YouTube ReVanced/youtube-dl, and so much more.
The goal of device attestation for consumer software is to put an end to that. Originally pioneered by Apple on iOS, now making its way to all of computing thanks to the forces of capitalism, device attestation means that the hackers lose. It is the bad ending.
The other twin threat, and I hate to say it, is the software industry sorting its security story out. In the past iOS jailbreaks used to be common, but there hasn't been an iOS jailbreak in a year. Rust isn't helping.
We are hurtling towards a world where producers and IP holders have complete control over the content they produce, and use leading-edge cryptography and ultra-secure consumer-hostile software to keep it that way. This is one of the most dangerous developments to ever happen in all of history, and once it's real there's no going back.
Well put. In practice, all this attestation crap is just DRM, as far as I can tell. It’s of course being marketed as an opt-in thing which can “improve your experience”. Similar to how giving your wallet away at gunpoint can improve your happiness.
Ironically, the biggest potential impediment to this is Apple. It is the fact that iOS is a walled garden where the website owner can’t just say “Install Chrome and come back” unless they want to lose a lot of potential users.
If you are working in a shell like that you should have outbound ports locked down and a list of allowed domains set in your proxy. Add in some antivirus and password sudo check and plenty of ways to catch this
This particular attack is actually not a concern if you're using fish (or zsh for that matter I think), as it will not execute pasted content without an additional pressing of the enter key.
Viewing the web as a platform for delivering applications, Web Integrity is an obviously good thing that I personally would use as a developer who makes software people pay for.
The opposition listed here is mostly misguided. For example, there is ~0% chance Google breaks "screen readers" or "assistive technologies" with Web Integrity. Saying that they would break seems like a bad faith argument to me.
Fundamentally this is about DRM and whether or not you think it should be allowed. I believe optional DRM for web applications would be good for developers and users of the apps. It would be bad for most other entities (crawlers, scrapers, criminals, etc). So I am in favor of it.
To the people saying "stop using Chrome", I don't think you understand the situation. Using a non-Chrome browser does not protect you from this proposal. If anything, worst case it will force you to use Chrome for specific websites, say a bank. So unless 3 billion people switch browsers overnight, avoiding Chrome does not make this go away.
IMHO, Apple has a very good opportunity to open-source Safari. If Safari were to become cross platform, out would surely help in fighting Google Chrome's dominance.
Although I do agree that means there's less competition in the browser engine world.
Safari uses webkit as the engine, which is FOSS. I mean, yes, I'd also like them to open source the whole thing and make it portable, but the engine is the hard part.
So imagine you have a separate slot in your desktop/laptop occupied by a secondary single board computer of sufficient power to run your banks website or other secure operations. Since you are going to use it to git push to import repos or move money you give two shits if it has much in the way of customization.
You hit a physical button and an internal kvm switches usb input and displayport out between primary and secondary machine. There is no shared clipboard or way for data to be intentionally be shared between machines and nothing to distinguish this setup from any other "secure" setup to disallow its use. It ticks the correct boxes to meet the described intent of the feature and unlike a secure environment one is obliged to use for everything would actually be more secure as you have no good reason to install a bunch of software or browse random websites on the slower secure environment.
How expensive would it be to rip the signing keys off the TPM? People used to do it to get free satellite TV but I imagine it's way more expensive now with the smaller transistor sizes
[+] [-] devit|2 years ago|reply
1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on an HSM on the device (generally called a "trusted enclave"), and signs the public key of the keypair with a master key
2. The device runs the attacker's software and is designed so that whenever non-attacker software is run with elevated privileges, the HSM is informed of that fact in a way that can't be reset without rebooting (and starting again with the attacker's software). For instance, the device might use a verified boot scheme, send the key the OS is signed with to the HSM in a way that is unchangeable until reboot, and it might employ hardening like having the CPU encrypt RAM or apply an HMAC to RAM
3. The HSM produces signatures of messages that contain statements that the device is running the attacker's software, plus whatever the attacker's software wants to communicate and it won't produce them if it's running software of the user's choice as opposed to the attacker's software as established above. It also includes the signature of its public key with the master keypair, allowing accomplices to check that the device is indeed not under the user's control, but rather under the control of someone they trust to effectively limit the user's freedom
4. Optionally, that attestation is passed through the attacker's servers, which check it and return another attestation signed by themselves, allowing to anonymize the device and apply arbitrary other criteria
5. Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker's software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice's code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.
This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.
[+] [-] Doxin|2 years ago|reply
This Web Integrity API is just a means to cement themselves as obligatory man in the middle, as opposed to an optional one.
[+] [-] benterix|2 years ago|reply
[+] [-] insanitybit|2 years ago|reply
And this "attacker" gets... what? Nothing. Because this isn't an attacker... it's a device manufacturer. You've described how attestation works except you've described the TPM as an attacker, which is silly.
[+] [-] o11c|2 years ago|reply
6. Any additional party with sufficient ability to modify hardware can still attack the attacker and their accomplices. So such parties only benefit from this, at the cost of typical users.
[+] [-] CalRobert|2 years ago|reply
[+] [-] eganist|2 years ago|reply
I haven't seen anything yet on whether Brave will support it, though if I'm understanding correctly, they won't have a choice since they're using Chromium. Hopefully I'm misinformed.
[+] [-] masukomi|2 years ago|reply
Not saying it's perfect or better, just that we need it. we need a competing browser with a rendering engine that google doesn't ultimately control that has a non-trivial market share. Otherwise we may as well just stop complaining and let google do what it wants because we'll have no power to stop them anyway.
[+] [-] cj|2 years ago|reply
Quick googling confirms 50%+ of revenue came from Google 5-10 years ago, but couldn't find more recent data.
If Google is Mozilla's primary revenue source (especially if it's the majority), then Google effectively controls Mozilla via the leverage it has to pull Mozilla's largest revenue source.
Edit: Also raises the question, what company or organization should be developing browsers? A browser is something everyone expects to be free, but a browser is by no means free to develop, operate and maintain. For-profit browser companies (like Brave) would be forced to monetize the browser (like Brave tried to do with BAT crypto tokens, ads on the new tab page, etc)
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] JohnFen|2 years ago|reply
[+] [-] dhx|2 years ago|reply
If you are shown a product ad whilst browsing searchengine.example and then later look up the product at reviews.example, then end up making a purchase at shop.example, your Mozilla browser will send all of these events to one or more aggregation services that allows shop.example to understand (at least in aggregate, assuming you trust the cartels running the aggregation services) that you were exposed to their product at searchengine.example and further exposed to their product at reviews.example.
Where previously an ad tech company was ultimately able to track users based on source IP address (even if cookies had been disabled by a user), IPA now allows these companies to track users across multiple IP addresses, and regardless of the user's cookie settings, via a unique tracking identifier. It is also proposed that the operating system provides the unique tracking identifier which can then be used by all applications or browsers on a device, allowing different devices behind a single IP address to be distinguished.
[1] https://github.com/patcg-individual-drafts/ipa/
[+] [-] kmeisthax|2 years ago|reply
Most of these private attribution systems are specifically designed so that the people running the ad can count how many people clicked their ads, but not who clicked them or what other things they did. Safari had a proposal in which you could only have a certain number of campaigns running per domain, so you couldn't set up a separate """campaign""" for each user and fingerprint them all at once. I don't know how the Mozilla proposal differs.
Whether or not user-agents should care about this sort of thing is an orthogonal question.
[0] https://www.theregister.com/2023/06/29/google_trueview_skept...
[1] Remarketing in particular is responsible for the "feeling of being seen" from modern ads where you search for one thing and get 10,000 ads for the thing for the next week
[+] [-] CaliforniaKarl|2 years ago|reply
[+] [-] mindslight|2 years ago|reply
[+] [-] 1vuio0pswjnm7|2 years ago|reply
How to design a website that is not accesible with Chrome. As a means of protest by certain website operators.
Would be fun to watch Google circumvent that. Especially if it was only popular amongst small, noncommercial websites.
[+] [-] realusername|2 years ago|reply
We should start to orient the debate instead on the security issues created by Google and their ads.
[+] [-] notpushkin|2 years ago|reply
I'd love to donate to Mozilla, but I'm concerned my money could just end up in some C-suite pockets if I do. Is there a way to donate specifically to Firefox core(-ish) team, and maybe also MDN?
[+] [-] sofixa|2 years ago|reply
For a "fun" example of how strict budget destination restrictions fail, take a look at Atlanta's MARTA, that used to have a fixed 50/50 budget split between OPEX and CAPEX by it's funding law, and therefore had brand new trains but everything else falling apart.
[+] [-] coldpie|2 years ago|reply
[+] [-] toast0|2 years ago|reply
However, dollars are fungible. If you donate $500 to support MDN, that may replace $500 for MDN coming from revenue, which frees up $500 to go into something else, like a C-Suite's pocket, or Pocket or whatever. So while your dollars go where you said, it still enables whatever you didn't like. OTOH, if you donate $50B to support MDN, that's a bit different; it certainly frees up whatever money was going to support MDN before, but there wasn't $50B of MDN expense, so the excess beyond the needs of MDN doesn't go anywhere.
[+] [-] potamic|2 years ago|reply
[+] [-] dblohm7|2 years ago|reply
[+] [-] Havoc|2 years ago|reply
[+] [-] doesnt_know|2 years ago|reply
At the end of the day, users will just see that a website works in Chrome and not in Firefox. Firefox will decide that there is no point in apposing it if there is a real cost in potential market-share.
[+] [-] freediver|2 years ago|reply
https://webkit.org/standards-positions/
(this one has not landed yet, likely to be opposed as well)
[+] [-] jer0me|2 years ago|reply
[+] [-] howinteresting|2 years ago|reply
The goal of device attestation for consumer software is to put an end to that. Originally pioneered by Apple on iOS, now making its way to all of computing thanks to the forces of capitalism, device attestation means that the hackers lose. It is the bad ending.
The other twin threat, and I hate to say it, is the software industry sorting its security story out. In the past iOS jailbreaks used to be common, but there hasn't been an iOS jailbreak in a year. Rust isn't helping.
We are hurtling towards a world where producers and IP holders have complete control over the content they produce, and use leading-edge cryptography and ultra-secure consumer-hostile software to keep it that way. This is one of the most dangerous developments to ever happen in all of history, and once it's real there's no going back.
Stallman was right.
[+] [-] klabb3|2 years ago|reply
[+] [-] RcouF1uZ4gsC|2 years ago|reply
[+] [-] omnimus|2 years ago|reply
Imagine we fully loose the web because iOS opens up.
[+] [-] JeremyNT|2 years ago|reply
[+] [-] realharo|2 years ago|reply
[+] [-] egberts1|2 years ago|reply
Basic malware JavaScript snippet:
[+] [-] jabart|2 years ago|reply
[+] [-] westernpopular|2 years ago|reply
[+] [-] hardcopy|2 years ago|reply
[+] [-] mgraczyk|2 years ago|reply
The opposition listed here is mostly misguided. For example, there is ~0% chance Google breaks "screen readers" or "assistive technologies" with Web Integrity. Saying that they would break seems like a bad faith argument to me.
Fundamentally this is about DRM and whether or not you think it should be allowed. I believe optional DRM for web applications would be good for developers and users of the apps. It would be bad for most other entities (crawlers, scrapers, criminals, etc). So I am in favor of it.
[+] [-] dahwolf|2 years ago|reply
[+] [-] thunderbong|2 years ago|reply
Although I do agree that means there's less competition in the browser engine world.
[+] [-] yjftsjthsd-h|2 years ago|reply
[+] [-] person3|2 years ago|reply
Also see: https://en.wikipedia.org/wiki/WebKit#Origins
[+] [-] toyg|2 years ago|reply
[+] [-] toast0|2 years ago|reply
[1] https://appleinsider.com/articles/12/07/25/apple_kills_windo...
[+] [-] boxed|2 years ago|reply
[+] [-] kazinator|2 years ago|reply
{Platform-vendor/developer/end-user}-neutral is more like it.
[+] [-] michaelmrose|2 years ago|reply
You hit a physical button and an internal kvm switches usb input and displayport out between primary and secondary machine. There is no shared clipboard or way for data to be intentionally be shared between machines and nothing to distinguish this setup from any other "secure" setup to disallow its use. It ticks the correct boxes to meet the described intent of the feature and unlike a secure environment one is obliged to use for everything would actually be more secure as you have no good reason to install a bunch of software or browse random websites on the slower secure environment.
[+] [-] 4oo4|2 years ago|reply
US:
- https://www.ftc.gov/enforcement/report-antitrust-violation
- [email protected]
EU:
- https://competition-policy.ec.europa.eu/antitrust/contact_en
- [email protected]
UK:
- https://www.gov.uk/guidance/tell-the-cma-about-a-competition...
- [email protected]
India:
- https://www.cci.gov.in/antitrust/
- https://www.cci.gov.in/filing/atd
Canada:
- https://www.competitionbureau.gc.ca/eic/site/cb-bc.nsf/frm-e...
[+] [-] rolandog|2 years ago|reply
[+] [-] alex7734|2 years ago|reply