Our great sponsors
-
BrowserBoxPro
Discontinued :cyclone: BrowserBox is Web application virtualization via zero trust remote browser isolation and secure document gateway technology. Embed secure unrestricted webviews on any device in a regular webpage. Multiplayer embeddable browsers, open source! [Moved to: https://github.com/BrowserBox/BrowserBox]
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
bikeshed
:bike: A preprocessor for anyone writing specifications that converts source files into actual specs. (by speced)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I apologize for an off-topic request, but if it's not past the edit window could you go over your comment and clean up the references/formatting? I think you may have had some errors copying and pasting quotes from my comment to reply and may have pasted more of my comment than you intended; this is very difficult to follow.
---
> But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted.
There is no evidence that Google would do this. And you're talking about a hypothetical; the fact is that LineageOS is currently blocked. That is what is factually true right now. Saying that it could theoretically be trusted in the future doesn't mean that the Integrity API doesn't block it today.
It doesn't mean that attestation won't block OSes right now. You can't deny that currently the Play Integrity API blocks Android ROMs.
> This API is not about blocking headless chromium. [...] Protecting against that [(password theft)] is unrelated to this proposal.
So first off, this is opinion you, there is nothing in the proposal that indicates that scriptable browsers would be allowed and nothing that references Headless Chromium. You are assuming that Headless Chromium wouldn't be blocked, but I would love to see any statement from Google supporting that assumption.
But more importantly, you're basically saying this proposal blocks nothing at all. Think about what you're saying, this is a proposal that supposedly prevents bots and ad fraud and you're going to allow Headless Chromium? You're like one comment away from telling me, "well, the proposal isn't about guaranteeing OS integrity."
> Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
No, this is very transparently an excuse. Of the reasons for this proposal (as specified in the proposal), kernel level malware is relevant to basically zero of them. Kernel level malware is not the reason why Netflix doesn't run on a rooted Android device. Kernel level malware is not something that matters for blocking web scrapers or bots. Kernel level malware is not the vector through which ad fraud happens. Quite frankly, kernel level malware is not the biggest concern when thinking about bank account theft of phishing attacks.
The reason Linux is blocked is because Linux does not impose computing restrictions on the user.
----
> Can you quote that section. I don't see it.
See https://github.com/RupertBenWiser/Web-Environment-Integrity/..., specifically the bullet-point list under the introduction:
> [...] This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins. [...] Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment. [...] Users playing a game on a website want to know whether other players are using software that enforces the game's rules. [...] Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users.
Of those 4 proposals, only the last one (banking security) is directly related to user security, the other 3 are site policies (ad fraud/scraping, blocking bots, blocking game modifications).
> Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
This is borderline disingenuous. I refuse to believe that you are incapable of understanding that giving website authors the ability to arbitrarily block "untrusted" browsers (and specifically telling them that the purpose is to allow blocking capabilities on untrusted browsers) is the same as blocking user capabilities.
It's especially absurd given that mainline companies like Google will be in charge of determining what environments count as "secure" and what environments will be supported for attestation, so not only is it an API that is designed to allow websites to block clients, it is also very much going to be Google's decision whether or not a given user capability is compatible with a "trusted" environment.
----
> Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
At which point it would be blocked from attestation, hence blocking user freedoms.
Also, custom-built kernels and custom user software are not side-things I can toggle on and off, my setup depends on those things. You can't go into user settings from the desktop in Arch and just turn off the kernel; if I'm using custom drivers for a monitor or input device, I can't just turn those off.
What you are saying is "your OS won't be blocked, you'll just boot into a different OS or different OS-mode without any of your custom kernels or drivers." But take a step back and think about that: the OS is blocked. And the solution you're giving me is to boot into a different OS based on a different kernel that I don't control that doesn't have my custom-compiled drivers and that might not even support my hardware. This is really silly, it's like saying that Apple Pay is fully supported on Android, you just have to boot into an iPhone.
> Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
Like I said, this is about blocking my ability to root my device. It is a reduction in user autonomy under the excuse that user autonomy to root my device makes my device untrusted.
Quite frankly, it should not be an app's choice to decide whether or not to run on a rooted device. It's none of their business whether or not my phone is rooted.
> The Play Integrity API works with apps not from the store.
Technically true in the sense that I believe Aurora spoofs Play Integrity APIs and device checks, but I'm not sure of the full details there, and in any case that's a circumvention of Google's policies, not something that Google explicitly allows. I'm not sure I understand what you mean here
----
> https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
The currently untriaged issue that hasn't been updated for over a year? That's not exactly strong evidence. Let me know when the Chromium team starts working on it and merges it.
In the meantime, it is objectively true that Chrome currently has worse adblocking capabilities (particularly around CNAME cloaking) than Firefox and that it has had worse adblocking capabilities for multiple years. This is not an API that is available for extensions to use.
And the way that CNAME cloaking has played out in Chrome -- given that they are trailing behind other browsers by years does not suggest that any of the other issues with Manifest V3 are going to be better handled. The overwhelming trend here (and what this issue shows) is that Chrome is going to lag behind other browsers on adblocking.
I'm having a hard time figuring out how you're looking at an arguably orphaned issue and seeing that as evidence that the Chromium team cares about adblocking APIs or that they can be trusted to make sure that adblocking capabilities aren't broken.
> Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.
Right, that's what I said. It was for advertisers, not for users.
Firefox and Safari removed cross site cookies without supplying an alternative just fine, that was a user-focused change. Chrome refused to make a user-focused change until after it introduced a spec (FLOC, later Topics) purely for the benefit of advertisers. In addition, it introduced other specs (Same Site Sets) that weakened those same protections.
Many comments on here are about this protecting the ad business model, but I think it's actually about protecting against competitor browsers.
If official Google Chrome is the only browser that passes this attestation proposal, you can effectively own the market and prevent new competitors.^0
I'm sure the technical specifics will be slithered over with enough worm-tongue to make it vague and innocent enough to not trigger anti-competitive lawsuits or whatever, but that might still be an option.
From a legal view, isn't this worse than microsoft force bundling IE into its OS? Taken to its full realization, it seems attestation is Alphabet force bundling Chrome into the whole web (that ubiquitous, "global OS", used my almost everyone). It's not there yet, but is it impossible to go from current zero to very-scary one?
As a maker of a competing browser technology (that uses Chrome under the hood), I'm worried about this, but heartened by the fact that as we are also an open-source product, the solution (that I've talked about elsewhere in this thread), if it's possible, will be distributed and built by people.
It's plain that Alphabet faces a conundrum: how do they prevent their investment in the open-source product being used against them? How do they prevent competitors (like brave, and BrowserBox) benefiting from the code Alphabet pays its employees to write, essentially using Alphabet's money to gradually chip away at (or threaten chipping away at) Alphabet's Chrome market share.
I understand the paradox they face, but I don't think "DRM" level control of a global and ubiquitous "means of access" is the way to solve it. But as owner of an open-source company myself, I don't think the solution is one where Google can't capture any value from what they invest in creating.
In terms of the long term economics, I don't have a solution. But I don't think that matters. I think technically there will be solutions to this, and they'll be built in the open.
DOSYAGO is really not an activist company, nor do we seek to be. But some things are worth standing up for. Future of the web should be one, I think. If you'd like to get involved, come on over to BrowserBox and contribute!
https://github.com/dosyago/BrowserBoxPro
0: With a current "monopoly", these new competitors may seem theoretical, but I think internally their viewed as very real threats over the long term. Brave, etc. And the fact that anyone can use Chromium to build a new browser.
[1]: https://github.com/w3c/encrypted-media
I am not a hopeful romantic, but the EU has been investing on vendor neutral web-browsers like Nyxt [0] and the UR Browser [1] through the Horizon Europe program. I doubt that legislators (at least in the EU) will view this as a positive development, assuming EU legislators know what they are doing. On the other hand, lobbying by big tech is still very much a threat.
[0] https://nyxt.atlas.engineer/
[1] https://www.ur-browser.com/en-US
Most likely https://github.com/speced/bikeshed
Oh by "Web Environment" you mean "my machine" lol!
I already got caught by this - a https://github.com/nativefier/nativefier app wrapping Youtube Music doesn't work, because Google detects somehow that you are not using a trusted browser and refuses to serve.
>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do with extentions.
First of all, extensions are not serverside code, so no. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run.
And attestation has even more to do with extensions when extended to websites because if the point of this is to established "trusted" environments, then arbitrary extension access means an environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not, extension APIs allow for automation and scraping. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API.
If this doesn't block extensions, then it's not a useful proposal for blocking bots.
> With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.
Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API.
And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level.
Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal.
> And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it.
https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out.
> uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is not very difficult to look up, you should have been able to find this link yourself.
> FLOC is [another long explanation of why advertisers are the victim]
I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."