De-AMP: Cutting out Google and enhancing privacy
brave.com
brave.com
They've actually been pushing to confuse that boundary even more since 2019, with their Signed Exchanges specification[0][1]. In essence, when you (unintentionally) visit an AMP page from Google Search, the URL typically starts with google.com/amp/websiteyouwantedtogoto.com. Signed Exchanges is essentially a way to drop the "google.com/amp/" bit, as demonstrated by one of the animations on [0].
Even Cloudflare supported this and rolled it out on their free tier[2].
[0]: https://developers.google.com/search/blog/2019/04/instant-lo...
[1]: https://www.theverge.com/2019/4/16/18402628/google-amp-url-p...
If you do introduce such signals into your search ranking in the future, should we assume you have bad intent?
As we don’t propose any such AMP-analogue, and we don’t perf-rank, your selective “you might do it too!” response falls flat.
The new system adds verification that the content is exactly what was intended by the original site, despite being served through a cache, so the user agent is no longer lying about which website the user is visiting. Sure, the data was fetched from Google, but that's not the important part. It's been verified to have originated from the server shown in the address bar.
Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...
I gave up information on what site I was visiting, but if I enter any information on the page, won't that still go to Google? It's going to look like I have an https end-to-end channel with the site I'm visiting, but really Google is Man-In-The-Middleing the whole thing?
So far as I can tell the user agent uses the original (non-Google) URL for the purpose of same-origin tests when it's returned from Google's cache using the Signed Exchanges standard, so the risk is effectively the same as if the page were served from the original server and Google were not involved. The page could send anything you enter to Google, but it would need to be coded that way to begin with. It wouldn't do so just because it was served through their cache.
If this were truly the case (that it didn't matter), the argument can be made that there is no reason to change the host -- just show it as google.com like it does now. The only reason that you'd want the address bar to show a different domain (i.e. the "author" rather than "publisher") is exactly because it _does matter_ to the user!
There is only a single way that the source[+] can guarantee[*] knowledge of a click through: Linking to their own domain with a unique identifying tag[**] and subsequently redirecting to the real target.
Without SE, this kind of tracking behavior is readily apparent to the user:
- The link goes to the source's own site [***] - The link contains elements of entropy relevant to tracking - The browser must briefly flash the source's domain being loaded before the redirect comes in. An obvious behavioral difference.
With SE, however, this behavior is no longer apparent:
- The link can visibly go to the publisher directly yet still actually hit the distributor (likely just also the source) even with scripts and referers disabled. Unless browsers offer a way to disable SE specifically, there is no way to prevent it. - The browser has no observable behavior differences from a site not using SE. The only way to distinguish a site using SE (besides the browser making this explicitly visible in the UI) is by capturing connections at a layer below the browser (i.e. sniffing packets at the OS or upstream network level) .
Like with most tech, it is certainly possible to implement SE in a privacy preserving way on the client side, but it also seems to be solving a problem that only the likes of Google will care about.
[+] I'm going to use the terminology in the proposal where: - source = the thing hosting the link (i.e. Google) - publisher = the thing producing the content (i.e. YourBlog.com) that is linked to - distributor = the thing re-distributing a copy of the content (i.e. also Google) in lieu of the publisher
[*] While other methods like JavaScript and 'Referer's may also leak this information, they depend on a cooperative client voluntarily disclosing such info. It is quite trivial for a privacy conscious client to disable both sources of leaking click through information.
[**] This must also be part of the URL, as using cookies or the such can be foiled by loading the link in a clean/fresh alternative sandbox environment (no identifiable info), and then sending back the address it resolved to. A lot of URL "un-shorteners" do this already.
[***] This can be hidden by JavaScript (and Google has done exactly that right now by replacing href= URLs on click), but again, a privacy conscious user would have disabled such a script.
I really think you overestimate how likely users are to notice a redirect URL appearing in the address bar for a fraction of a second. Regardless, even with SE the distributor's URL will appear for a short time until the content has been downloaded and the signature can be validated, just as it would with a redirect. Anyone who actually cares to see which connections are made (which covers much more than what you can infer from the address bar alone) can open up the browser's developer tools and inspect the network traffic. Or you can fire up Wireshark if you're paranoid, but there is nothing in the proposals about hiding the true endpoints of the connections from the developer tools—just main URL shown in the address bar.
If you want to avoid giving the data to Google in the first place there is no substitute for checking the URL before clicking on the link, which will show the distributor's domain regardless of SE.
Anecdotally, it's how I learned how Google tracked click-throughs. I used to (when I was very young) live in a jurisdiction that had no Google datacenters. All requests to Google came with a 100ms+ latency hit. It was painfully apparent the day they started doing the redirects (I even wrote an extension to undo that redirect-- not for privacy reasons, but just because it was _that annoying_.)
As for the rest of the argument, again, I'm not claiming the design of SE itself is somehow broken or even that most users would gain privacy/be tracked less if we didn't have SE. Rather the argument is similar to that against AMP or FLoC, it solves a problem that only Google (and similar) has, not one that users have. SE does not benefit publishers (it actually hurts them), it does not benefit users, it only benefits the middle-man. That is reason enough to not care about supporting it.
Given Signed Exchanges are entirely opt-in by the publisher/website operator, what's the difference between this and a CDN? Isn't that "lying" about what site you're on? It's not theverge.com - it's Cloudflare!
> There has been discussion of allowing a publisher to restrict the set of distributors that can host its signed content. If that's added, then the privacy situation becomes more similar to the situation with CDNs, where a publisher chooses a CDN to serve their content, and the CDN learns about all requests for that content. Here the publisher would choose one or more distributors, and the distributor(s) would learn about requests for the content.
Basically a signed exchange .sxg as it is right now allows anyone to be a distributor. It authenticates only that the content has not changed, but not who is distributing it was allowed to distribute it.
Imagine I use SXG to sign "myBlog.com/some-post/" as "some-post.sxg" and serve it via "myCdn.com/myBlog.com/some-post.sxg" on "myBlog.com/index", like I would with a CDN. EvilSearchEngine (now being both the source that sends a results page and a distributor CDN) can crawl this index, nab the .sxg and then when it serves results, serve it via "EvilSearchEngineCDN.com/myBlog.com/some-post.sxg" instead. The client browser checks the sxg, finding it is validly signed and thus shows it as "myBlog.com/some-post/".
However, (1) the EvilSearchEngine has now gained tracking data on visits to "myBlog.com/some-post/" (which it may or may not already have), but more importantly (2) I've now lost the ability to do first-party tracking of visits to "myBlog.com/some-post/" since EvilSearchEngine users never hit my server and I must now beg EvilSearchEngine to give me their tracking data for my content.
Maybe they'll introduce "allowing a publisher to restrict the set of distributors", maybe they won't. But until they do, it behaves nothing like a real CDN.
See, this is one of the good things about the SE proposal. The source page already has all the tracking data; that's a given. But if the content is served via SE it reduces the number of other sites that get tracking data, which is very much a win for privacy.
> Maybe they'll introduce "allowing a publisher to restrict the set of distributors", maybe they won't.
It would make no sense for user agents to enforce such a restriction, since a valid signature shows that the content is authentic regardless of the identity of the distributor.
This is a lie. The source page does not have any access to referral data. Without things like JS supporting it, it does not and cannot know that a user has clicked on any of its links.
> if the content is served via SE it reduces the number of other sites that get tracking data
This is also a lie. It does not _reduce_ the number of sites that gets tracking data. Rather it takes the ability to control who gets to track away from a publisher (who you'd reasonably expect to be able to track your visits to _their own site!_ ), and puts it into the hands of an aggregator (like Google, who you would _not_ expect to be able to track views on third party content).
In this sense it is exactly like AMP, it is a shift of who holds power over data. Users do not gain anything (privacy could be argued to be no worse, but it is certainly no better than before) but publishers have everything to lose.
AMP was never a battle between users (readers) and Google. It was a battle between _content publishers_ and Google. Nothing has changed when it comes to SE. It's the same old formula just in a new bottle.
Unless SE ultimately allows specification of a list of allowed distributors as part of the bundle, framing SE as "just like using a CDN" and that "Google/aggregating site doesn't benefit more from this" is at best a bit ignorant about the power struggles between publishers and aggregators.
The source page determines the target of the link and can add whatever tracking data they want to it. You can see from the link target that it's going back to the same site. That is all they need to get the referral data.
> It does not _reduce_ the number of sites that gets tracking data.
It does, as the source page has the tracking data either way but the publisher's page does not if SE is used.
Frankly I'd rather trust Google with that data—they have access to it anyway, through several different channels—than a bunch of publishers I have no other relationship with.
> Unless SE ultimately allows specification of a list of allowed distributors as part of the bundle, …
It won't matter if the bundle contains a list of "allowed distributors" if user agents don't enforce that restriction. And why would they? They know the content is correct regardless of where it came from due to the signature. Refusing the data won't improve privacy at all, as the server already knows that the link was followed. The only one seeing any benefit here is the publisher, who would get tracking data at the expense of the user's privacy. The user agent doesn't represent the publisher, it represents the user.
This is ridiculous. Of course it makes a difference. The address bar is how basically 100% of users know what site they are on.
i'd say probably 50% of users couldn't tell you the difference between the address bar and the google search box.
Google would know that you clicked on the link, and the URL you visited but that doesn't necessarily mean they know what the content on the page you requested was. In practice, most of the time it would, but since a site could serve very different pages to different users it wouldn't always be the case.
> It makes no difference at that point what is shown in the address bar, as the page has already been served.
Some things should be kept sacred to protect users and the address bar is one of those things. It should always display where content is coming from. browsers have been degrading the address bar for ages (turning it into a search box/advertising platform, or hiding parts of the URL from the user) but this really is a step too far.
At this point we really need a separate browser feature that shows us what server we're actually communicating with (host, cache, CDN, etc). The address bar itself is pretty much useless now.
SE is only supposed to be used for public pages ("Cache-Control: public") which will be the same for every user. If they have the URL they can just request the page themselves to see the content.
> It should always display where content is coming from.
And with SE it does show where the content came from. Not the cache, which is irrelevant, but the original source. Or do you want it to show all the routers and CDN platforms which were involved in getting the data from the publisher's server to your PC?
> At this point we really need a separate browser feature that shows us what server we're actually communicating with (host, cache, CDN, etc).
We have that; it's called developer tools. As there can be many resources from many different sources making up a single page the results are too complex to reduce to a single line in the address bar, but they are available for those who are interested.
You're right that's not the concern held by the people accessing the content, but the target here seems to be the websites who partner with Google. If I publish something on the web and another company wants to host my content (including caches and CDNs) and I expect many of my readers will access my content without ever touching my servers directly, I would absolutely be concerned about my content being modified where it's outside of my control.
Seems it'd be a lot of trouble to track down and verify that it were happening at all since google could change content any number of ways or not at all depending on the individual making the request.
I am pretty skeptical, however, given the way Google will (ab)use this.
[1] https://apps.apple.com/us/app/amplosion-redirect-amp-links/i...
I rarely end up in AMP pages on my mobile, but when it happens I immediately feel like I stepped on a turd, and promptly backtrack / close the tab before it hijacks my back button, half the screen, standard controls (including doing something weird to scrolling) and other unpleasantries like banners whose "x" somehow overlaps my browser's bars, and are therefore out of reach (and said browser bars somehow do NOT autohide when scrolling, unlike on normal pages)
Getting AMP results from Google search has been one of the drivers leading me to switch to DDG, so congrats Google, one less customer.
Firefox literally sends your keystrokes to Google, right out of the box. Brave, however, was found to be the most private popular browser by reputable researchers: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf.
Brave [never] hijacked links either. Affiliate Links were offered among suggested sites for relevant search input. So if you searched "Binance," the browser would offer (among other suggestions), an affiliate link for the site. Users could then choose to browse to the property with the affiliate link, and in so doing support the development of Brave. No impact to privacy or security at all.
The mistake here was with input handling. Built to handle search input, this feature also mistakenly handled fully-qualified domains. While we intended the app to offer affiliate links (when relevant) to something like "what is binance?", it was also offering them for "binance.us". The latter case was corrected quickly (and the feature itself was disabled out of the box).
More about that on our blog: https://brave.com/referral-codes-in-suggested-sites/.
To your second point, about setting up crypto wallets and soliciting donations on behalf of non-participating publishers, you're mistaken there as well.
To prime the support-system in Brave (called Brave Payments at the time), we staked Brave users with tokens, inviting them to direct those tokens to creators they would like to support. More clearly, Brave gave Brave users say over where Brave ought to direct its own tokens.
Unfortunately, our UI/UX wasn't very clear about which creators were verified, and which were not (we followed the Twitter approach, marking verified creators with a checkmark, but doing nothing for others). This resulted in some confusion at the end of 2018, where users were directing Brave's tokens to non-participating creators (most notably Tom Scott).
We received considerably helpful feedback about how the system could be improved (both from a UI/UX side, and operationally). Frankly, I don't think I've ever seen our team work so hard, and churn out such a monumental update in so little time. We had made massive changes within 48 hours IIRC. Creators were explicitly marked as verified or unverified in all cases, the BAT that Brave stakes with users would remain in the local wallet until it could be received by a verified creator. And BAT that sat pending for 90 days would be unlocked again for the user to direct elsewhere.
Tom Scott was kind enough to review our changes, and explicitly gave us his approval soon-thereafter. What is now 'Brave Rewards' wouldn't be doing so well today were it not for Tom and so many other incredible users helping us find the best path forward.
More about that on our blog: https://brave.com/rewards-update/
It doesn't look like this is the case, fwiw. (Unless your HN profile lists an outdated handle?)
Keystrokes in the URL bar.
Describing the cost without explaining the why is really putting a spin on things.
It would have been better to say "by default Firefox literally sends every keystroke you type in the URL bar to Google".
In my opinion it is a user-hostile "feature", and should be pointed out, but not in way that could be so wildly misinterpreted.
I agree. I don't like a lot of what Mozilla does but I don't like Brave at all, so I'll gladly defend Mozilla against hyperbole coming from Brave. Brave isn't even a browser, so I just ignore it most of the time.
This is a touch of FUD. Firefox sends what you type into the search/address bar to google for search suggestions by default, yes. Your perhaps unintended implication here is that all keystrokes are being logged and sent to google.
> Brave, however, was found to be the most private popular browser by reputable researchers: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf.
This is a bit of a misstatement of the research; Rather they found that Brave doesn't tag users' installs with persistent IDs by default in startup telemetry or update requests, while most of the rest of the competition do. This means Brave has a superior initial privacy state but says nothing about the overall usage posture. Is it better? Possibly but that's not the conclusion the researchers actually came to.
Here's an example of why the first line of FUD is dangerous: "Brave's BAT is basically just a way for users to be tracked as they go about navigating the web."
This is an easy throw-away statement with little substance and likely little to no truth behind it.
A more concrete example might be that the so-called "Privacy Preserving Product Analytics API" that collects data on Brave users' installs gets enough data to pretty easily fingerprint a user if you wanted to. You don't need many data points to identify an individual from a large group.
Some of the ire is earned but I have yet to see how Mozilla is supposed to fund Firefox development without that google search bar.
If we’re talking about the Mozilla foundation, they should seek donations and grants and focus on being the best user web tooling.
If we’re talking about the corp, they could’ve kept rust under the umbrella and pioneered the WASI runtime and built an alternative to k8s that runs webassemblies and built out a paid cloud infra.
It doesn’t make sense to have a foundation that is user aligned and a corp that is user hostile. There should be aligned incentives.
There's a lot that can be added here:
Mozilla promised to opensource pocket server and never did.
They promised to hire someone full-time for Thunderbird, but never did. afair there is a German company that has full-time developer working on Thuderbird.
They promised a VPN... yes, delivered something.
They promised anonymous email, I know they were giving access by invites, but nothing more about it.
They promised to unfork Tor browser and integrate Tor into Firefox, they were even running a few Tor nodes.
Remember how hyped everyone here was for Servo in Firefox and electron competitor?
MDN could have integration with GH or GL and educational content for web development, they literally had resources, brand and ability to join an online university and give degrees or at least serious bootcamps. Mozilla was a meaningful brand to do it.
They had a lot of opportunities to sell privacy, we literally demanded it from them, but they weren't interested in listening. Instead they delivered 6 rebrands each breaking my muscle memory.
Do you remember how they advised EU to regulate monopoly on the webbrowser market? There was time when they had all ability, but 0 will to keep it this way https://en.wikipedia.org/wiki/BrowserChoice.eu
Developing a browser isn't easy and requires a few teams of developers, but in 2020 it spent 242 million dollars in software development costs, 137 million dollars in administrative costs and 37 million dollars in marketing and branding costs. I don't live in a lala land where I think you can develop a browser for free, but I think we can all agree that you don't need to spend this amount of money on it either. Are 100 developers enough? 200? How much does that cost? Do they all need San Francisco salaries to develop a good browser?
In terms of funding, they got 440 million dollars from royalties (what they get from setting default search engines on their browser) and 25 million dollars in subscription revenue (Pocket and VPN subscriptions type things - products they actually sell).
Now, can you develop a browser on 25 million dollars per year? Maybe it's cutting it short, but for sure there could be a strategy to invest more on this side of the equation to phase out the need to be Google's bitch in a more intentional way.
Source: https://assets.mozilla.net/annualreport/2020/mozilla-fdn-202...
100-200 developers probably roughly costs on the order of 25-50 million a year (assuming a made up number of 250k fully loaded cost with benefits and taxes, which might be lower or higher than their average, idk. This number seems almost too conservative to my gut). From this back of the envelope math, I don't think the royalties business is enough to support the development cost alone.
> Do they all need San Francisco salaries to develop a good browser?
If you don't want them to leave to work on safari or chrome, probably? This experiment was more or less tried by opera, right?
Brave gets away with a lot lower overhead by bascially piggybacking off chrome. Opera similarly gave up selling their own browser engine and cut their development teams while switching to another wrapper on blink. Firefox could become yet another skinning of blink and chrome code, but it's not clear to me how that's helping them with being "Google's bitch in a more intentional way".
I think there are problems with Mozilla's side project expenditures, there is definitely some bloat, and they have had some expensive failures like Firefox phone. However I don't think Mozilla could have survived without Google's funding and people vastly underestimate how expensive quality software is.
Chromium get contributions from a few big companies, why couldn't Mozilla create a "contributor community group" something like Java has? Oracle keeps control over Java but there is a democratic process on what gets into Java/JDK. At some point Samsung was contributing to servo when it still was experimental.
Mozilla regularly accepts code from unpaid community members and has since its inception.
Yes, so it Java and Google and Microsoft... you're still missing the point I made there. Make Servo a cross-company product serving more than just Firefox. More companies contribute to it, lower costs of development.
Did you mean subscription business? Like I mentioned, the royalties were 440 million which is way larger than 25-50. If you put 200 developers on this project, with fully loaded costs of 400k / year each, that's 80 million dollars per year. You add 20 million dollars for administrative and other expenses and we come to 100 million dollars per year burn rate.
In 2020 they made ~25M on subscriptions, if 50 of the 200 developers focus on improving the subscription business, at the current rate of growth they had from 2019-2020, in a few years they could totally phase out of needing royalties at all to cover their $100M / year expenses, with 200 developers earning competitive salaries.
I don't doubt there are developers being paid peanuts with more talent than I will ever see, but I haven't seen them and I know a lot of people spending a lot of money looking, which suggests to me they are rare and hard to build a team out of.
And if they found them, and they fired all the senior bay area folks and rehired these 100k developers tomorrow, are those developers experienced writing fault tolerant c++ in a multi-decade codebase? And if so, how many will relocate or take remote jobs for way higher salaries after a couple years? Google, Amazon and Microsoft would be happy to have them and pay 300k+ TC for those skills, as well as countless banks and fintech firms.
Here in Spain (which is a first-world country :) a good dev would make about 50k or so..
I think the Silicon Valley area has really skewed expectations of salary (and of course living expenses!). Familiarity with codebase is a problem indeed, but they could start setting up a hub somewhere in Europe.
I think part of the problem is that when they incorporated Mozilla they started thinking as a corporation. Multi-million-dollar-paid CEOs, top-heavy with marketing etc. They should have stayed nonprofit IMO.
1. Stick to building a more private browser
2. Become a non-profit or Benefit Corp
3. Fund #1 through all of us donating and encouraging our less tech savvy connections to use it and donate
And Brave has things that not everyone likes like the bat token stuff. And chromium.
Yes, that is part of the reason why they should be a non-profit - sot that they can work for the public good and not for the good of their corporate sponsor.
> 3. Currently, the donation figure is about $20mil.
Donation figure for what? Currently you CANNOT donate towards Firefox development.
To Mozilla foundation. Most people I heard donating to them don't realize their money aren't and couldn't be put into Firefox development.
They could also try to seek government funding. EU and other non-US countries should have an interest in there being a browser that is not beholden to a US for-profit corporation.
And something like apple's iCloud relay. I would pay for that.
I won't pay for a Mullvad subscription that's less useful than actual Mullvad because it just works in the browser and it doesn't fix all the issues iCloud relay solves.
If they'd sell actual privacy features I'd pay for it totally. Sync too.
Sure it's probably not going to make it but they're still not things they can sensibly afford to do.
Your raising a discussion about mozilla in a brave thread plays right into mozilla's purpose of muddying the waters for actual competition against google. Please don't derail brave discussions with off topic stuff.
https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robo...
- The affiliate link "hijacking" was - if I remember correctly - to sites of crypto companies that partner with them. I'd prefer if this didn't happen, but most seem to be fine when other browsers (Safari, Firefox, etc) add something like "?client=safari" when searching or when their search engine (eg: DDG) use affiliate links to sites like Amazon or Ebay. It's not a new thing.
- The money collection (brave rewards)... if one doesn't understand how the system works, it looks like they are stealing money... but the money is returned to the sender after a while if the website/creator doesn't claim it. Is this that bad?
And then there's them not blocking some trackers (Google, Facebook, etc) by default, but if they did, they would break logins on many websites.
Maybe all this is bad, but I'm not sure if there's any browser out there without a history of shady behaviour. Even Mozilla has messed up a few times.
I don't think anyone ever accused them of stealing that money, but yes, hijacking people's personal brands to collect money without their explicit knowledge is a bad thing.
Imagine if I saw the icon and gave "them" money via Brave instead of joining their Patreon or some other official channel that they explicitly set up. If they don't collect, then yes, I might get my money back - nothing was "stolen". But that was money I wanted to send to the content creator in that particular moment, and that creator will probably never see it. The creator got screwed out of money that otherwise would have gone to them.
Brave gave users BAT to tip content creators. They tipped it, if it wasn't claimed in 90d, Brave returned the BAT to the pool. There was no collecting money. It was Brave's promotional BAT and it never actually left Brave's possession unless claimed.
The issue was that it wasn't clear if the creator had or hadn't signed up. Which was fixed within 48h.
Imagine I presented you with $10 (from my own pocket), and asked you where it should be spent. You told me "Doc's Pub, over on 9th." So I walked over to Doc's Pub, but found them to be closed. So I waited outside for a few hours, just incase they opened up. I later went home and wrote down "try to spend $10 at Doc's tomorrow."
Brave staked users with BAT (from our token sale). Users could direct that BAT to the sites/properties of their choosing. The BAT then went into an omnibus settlement wallet (note: the BAT originated in one Brave wallet, and was sent to another Brave wallet).
There was no hijacking of brands, or anything of that nature. I would encourage you again to please visit the aforementioned link. In it I mention our blog post on the topic, which includes screenshots and more. I hope this helps!
At least for websites I have to manually click the Brave Rewards icon (wasn't prompted to do it on a new profile) and it shows if the site is verified or not:
- My personal website (verified): https://i.imgur.com/WZykI2U.png
- Google[.]com (unverified): https://i.imgur.com/89XvzIz.png
And if we hover over the "unverified creator" text, this is displayed: https://i.imgur.com/IfKQUME.png
I guess the right way to do this is to only allow tips/donations for websites already verified... still, if you're going to use Brave Rewards, you probably have an idea of how it works.
Maybe things are different for creators on platforms like YouTube? I don't know how it works. I couldn't find a way to make a direct contribution with Brave Rewards.
Then what should they do? It sounds like they're between a rock and a hard place
This is only a "problem" for some because they think Brave is actually siding with those services, when in reality there's a good reason to not block them by default.
Grassroots users should support it like the godsend it is.
Multi-Account Containers
Temporary Containers
Sidebery
A man can dream.
Based upon their actions I don't believe that Apple cares about the web beyond the bare minimum they have to to provide a tolerable browser experience for their users until everything happens via Apps.
That's even more true for publicly traded companies
That was just the best answer he had to questions about third-party apps until they had the infra in place for it.
Apple will never tell you ahead of time about changes like that. So, while I wouldn't exactly call it lying, you'll get answers like the above.
It's not a paid app, just part of the walled garden experience.
Most of the money Apple gets from the App Store is from pay to win games - north of 80%. It came out in the Epic Trial.
Apple doesn’t really care if your banking app is a website or an app. They don’t make money either way.
Most apps on the App Store that could be a web app don’t charge users.
But the money they make on ads in the App Store has to pale in comparison to how much they get from Google
Now there must be more but $99 * 20 million is not nothing in annual revenue which is mostly profit.
A “registered developer” is not necessarily a “paying developer”, you can register as a developer to get documentation etc.
If you are working for a company creating an app, not all developers need to pay to publish an app. Also Mac developers don’t pay to distribute an app.
If you have a company with 100 iOS developers, you only need to pay for one account that has permission to submit an app.
If you are exclusively a Mac developer, you don’t have to pay anything unless you are submitting to the Mac App Store.
What the heck is a nothingburger?
Not only that, the data for those apps are on a remote server that is accessible via any other platform. Even when an app uses the standard file picker, you can choose any installed cloud storage device to save and load files - ie iCloud, Dropbox, Google Drive etc.
There is sadly not a version or equivalent on macOS, but Christian has confirmed it is in-development.
[1] https://apps.apple.com/us/app/amplosion-redirect-amp-links/i...
P.S. Pairs well with PiPifier to bypass YouTube not allowing picture-in-picture or playing in the background without a subscription, and a good ad blocker.
Apple sells ads on search indirectly via Google. (Google pays Apple to be the default search engine.)
Google’s payment to Apple is bigger than the revenue Apple makes from the Apple Watch.
They're being paid handsomely, by Google:
> In 2020, The New York Times reported that Apple receives an estimated $8-12 billion per year in exchange for making Google the default search on its devices. According to one analyst, Google's payment to Apple in 2021 to maintain this status quo may have reached up to $15 billion.
1. https://www.macrumors.com/2022/01/05/google-pays-apple-stay-...
Apple sells huge amounts of ads, I believe it's the fastest growing part of the business right now. Estimates are $5 billion in advertising revenue in 2021, with one projection of $20 billion annually within 3 years. In addition to this, Google pays them $15 billion to be the default search engine and sell ads.
https://www.ft.com/content/074b881f-a931-4986-888e-2ac53e286...
DDG sounds like a promising alternative.
Regardless, it's already in their tool box because they make the browser.
They could be re-writing urls and not showing you, if they wanted to. And as long as no one notices, you can keep doing it.
Unfortunately, switching to a different search engine does not prevent you from ever stepping onto AMP again. For example all links in the mobile version of Twitter used to be AMP until recently: https://www.theverge.com/2021/11/19/22791002/twitter-amp-ios...
I only recently became aware that the app existed, so I don't know how/if it deals with all things AMP-based.
It is a cliche but you are not Google’s customer. You are their product. If you don’t find AMP compelling they don’t want to serve you ads anyway.
So yes, it is a loss for Google.
Not all products are profitable.
Like that time Brave replaced links to a site with their own affiliate links? Yeah, I no longer trust them.
The issue was about address bar input autocomplete for two domains, binance.us and binance.com, along with keywords which all browsers offer several possible autocompletions for, we autocompleted by default not just via dropdown suggestion, with referral code attribute identifying us (not the user) to Binance at end of domain name. We fixed this right away and made nothing off of it. But it was a blunder for sure.
I never understood why AMP gets so much hatred from end-users. I understand why publisher hate it (it takes away control), and I understand the monopoly concerns, but for me, as an end-user, 99% of the times, the AMP version is better: faster, with less of the annoyances you described. As for privacy, these 99% are loaded with Google ads and analytics anyways, so not much of a win there. I don't know what your configuration is, what kind of ad-blockers you are using, but I never met the horrors people make AMP to be.
And sure enough, there are sites that are better than any AMP sites, but these almost never have an AMP version. So for me, AMP makes terrible sites a little less terrible, and good sites unchanged.
And here lies the problem. Eventually, these two 'annoyances' will become much bigger than that. The biggest threat, imo, is that these will lead to news organization, journalists, and credible publishers to eventually close up shop as they receive less of the share of revenues.
I do agree with your point about AMP sites generally being a much smoother experience. But at what cost?
If it did not do that I could care less.
But AMP pages are often worse - things like getting cut-down pages with the normal navigation missing or stuff like that. And it breaks URL sharing - if I want to share a link, I just want the regular link, not one with AMP crap in it, but often cutting out the AMP part to try and reconstruct the original URL just doesn't work...
So I've never found it better but only worse, so understandably it just annoys me. If it is just that my tracking and ad blocking is making all the difference, then AMP clearly isn't actually solving the actual issue...
Mozillas effectiveness at diverting/absorbing/stopping other community initiatives that could actually impact google - worth the dollars from google's point of view.
"AMP HTML documents MUST...contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag" [1]
Meaning, "Your content must load and run some Google controlled javascript, that does who-knows-what to your content and end users".
In the past, that's included injecting a big header that pushes your content down, hijacking swipe events on your page, an [X] button that looked like it would delete the AMP banner header, but instead navigated away from your page back to google, etc.
[1] https://amp.dev/documentation/guides-and-tutorials/learn/spe...
The only difference is that it doesn't pass Amp validator, which is necessary for the Bing search result icon. Developers have requested the feature for the Amp validator to include self hosting but it hasn't been added yet (or have any plans to AFAIK).
[1] https://gist.github.com/mdmower/b56e94f0dc36beafb825b0c5e31f...
>Besides algorithm changes, there will be several user-facing changes. For starters, the Top Stories carousel in Search will no longer be limited to AMP content. The Google News website and mobile apps will similarly surface more non-AMP content. Lastly, the AMP lightning bolt icon will no longer be used to badge eligible content:
https://9to5google.com/2021/04/19/google-search-page-experie...
So... they "standardised" it.
Hilariously, OOXML as generated by MS Office is not the standard version by default. The standard version has different XML namespaces and even slightly different capabilities. You can choose this format in Save As, but nobody does.
amp.dev does make a tiny out of context mention at the bottom of the page, that Google runs the AMP CDN.
But overall it's obvious that the AMP Project trying to hide it's Googleyness by being "Open JS Foundation", which itself is a corporate trade group hijacking the word "Open".
https://wptavern.com/amp-has-irreparably-damaged-publishers-...
Sometimes here in Iran AMP is a lifesaver for us. Almost every single useful website/service is banned here due to government’s mass censorship (unbelievably, including tech news websites, some wikis, some regular Linux repos, tweeter, FB, YouTube, and even DuckDuckGo!) and AMPs might help you visiting a webpage in case your VPN doesn’t work properly.
PS: Google services are not filtered here.
Another reason why I'm happy to use Brave both on desktop and especially on mobile.
When I found out about this a few months ago this was the quickest purchase I have made on the App Store in a long time. I despise AMP and how Google has infected the internet with it.
Told all my friends about it, even offered to pay for it for them if they wished. Anything to help AMP die.
This logic needs to stop. We may as all well live in mud huts. Then we can have "real problems". You can presume privilege is your problem, or, we can continue to strive for better conditions always as a culture. Low standards will lead you exactly where you belong, your mud hut.
This was 'fixed' by Signed Exchanges[0] which sites can implement. This is (imho) a cool new web tech that got drowned out in the AMP noise.
Any news on that?
Google needs to continue their developer relations efforts. I think they want to be on the same team as "us", from a technology perspective. Perhaps if only for the sake of adoption.
Very similar to what they tried and failed to do with FLOC
I suspect Google is solidly in too many anti-competitive crosshairs around the world to be able to pull anything like this off.
Maybe you should reach out internally and ask if it's really worth it?
There's always a point where the Government steps in. Don't think you're immune. Don't think that just because you've gotten away with it thus far that anything you do will be tolerated by the public forever.
I don't know WTF they're doing to render but they tried to be too clever.
AMP is presented as "the web on a diet", and AMP's speed advantage supposedly achieved by its clever and enforced constraints. Protecting us irresponsible web developers from coding slow pages. Sounds believable, sounds good.
Problem is, that's not at all the reason AMP is fast. It's fast because as you scroll through Google's search results on mobile, AMP pages are preloaded as you scroll by them. Then you click one and its instantly there, because it was preloaded.
Which is something Google does not do for non-AMP pages, for "privacy reasons". Which is quite rich when you force users of a publication to consume it via Google in the case of an AMP page. Anyway, this is why an AMP page has a 3-5s head-start compared to any other non-AMP page.
As more and more people notice the blatant lie that is AMP "performance", here comes the next manipulative tactic. They show some vulnerability.
"OK OK, maybe this wasn't the proper 'standard' way to do it, but we were in a rush to solve the performance crisis".
The performance "crisis" for which there seems little internal Google consensus, as every single fucking of their own products violate best practices or actively contribute to it (Google tag manager), yet never get a ranking penalty, but I digress.
This next part is a stroke of genius. What really happened here is that Google failed to fully trick the user. They want the user to believe they are on domain.abc whilst in reality they are on google.com. They tried all kinds of hacky glitchy methods to conceal reality but could never make it water tight.
So by admitting to some error and promising to improve their game, they'll now use the standardized approach: signed exchanges.
Good guy Google "listened" to criticism by now implementing a standard that allows them to FULLY trick the user, as it's built right into the browser. So they'll be back.
So whenever Google tries to sell something as good (speed, web standards), know how full of deceit they are. The other tactic is "open source", as if that means anything.
You know what the real disappointment is though? The complete lack of regulation. How on earth can a company that is a monopolist in search, browsers, analytics AND advertising do an obvious power grab like this in the open and just fully get away with it, not a care in the world?
We need modernized digital regulation, drastically.
It's a publicly traded company (which makes rich people richer AND funds our retirement plans). It's simply optimizing its feedback loops. Any publicly traded company gets more and more evil as it extracts more and more value.
To change this, we'll have to recognize how ubiquitous of a utility for all walks of life the internet has become. And begin thinking about certain aspects of it in the same way we do other public utilities.
I may be switching browsers.
I'm mostly happy with Firefox but not entirely. I used brave years ago but wanted to support an open web by supporting competitive software. I've been looking at brave more recently because the web doesn't care and Firefox has made some questionable decisions lately (like pocket and suggested results from sponsors and the turning red ad... which is a good movie but a terrible move by Firefox). I use brave on my phone and I'm pretty happy with it and I hate amp links. This is a compelling change for me.
It only continues to exist as long as Google deems Chromium based browsers a viable means of eliminating worries of antitrust legislation, as only Google employees make direct code contributions.
The same argument can also be made for Firefox since a sizeable portion of their funding comes from Google, but at least they're developing a separate rendering engine.
That is more conducive to a "open web" built on "competitive software" than everyone using Blink and the standards being driven by Googles whimsy.
If AMP is genuinely a way to enhance online user experiences, then make it opt-in, instead of the current no-way-to-opt-out.
Since then networks & phones got faster, a lot faster, and the difference maybe isn't worth the cost anymore. Also I think the amp restrictions have greatly relaxed, making amp just as slow? But "single worst thing"? Hardly. At launch it delivered and big time, the UX experience was night & day.
SXG and WebBundle basically help map that trick out into the browser's domain, rather than some nasty restrictive JS library. It allows eliminating the whole megabyte-sized supersystem of JS nonsense that makes up the AMP library and having just plain ol' regular HTML/JS, while still netting most of the performance benefits of the old approach.
Mobile networks may have improved but the speed of light has not, and so these techniques still have a place in contemporary networking.
All the wasted rendering for all the amp links not clicked sounds like a really great way to churn through mobile battery life unnecessarily. Glad I don't use Google.
Preferching/prerendering existed long, long before AMP did. That wasn't a new AMP technology, although it does communicate that there's going to be less to preferch than other links.
^(.+\.)?amp\..+\.com$
^(.+\.)?ampproject\.org$
The banality of evil
Such a lot of wasted talent.
Google has 500+ staff working on that codebase. When they finally annoy Google and they decide to rewrite the license for future versions, will Brave be able to keep up?
So the fact Chromium is (mostly) open source (Chrome is most certainly not) is certainly not charity or the goodness of their hearts. It is the work of idealistic individuals like Lars Knoll who gave us this among other things like Qt.
This is also true for a lot of other Google projects like Android.
This isn't remotely true. Most of Chromium code is BSD-3-Clause.
> have been notorious in close-sourcing bits when they are able (like the DevTools WebAssembly debugging tools
I'm not a fan of that either, but to be fair it's a Chrome extension[1], not part of Chrome.
> and a ton of other stuff).
Like what? The trend has generally been the other way. Flash was removed, PDFium was released. Video codecs? But they've always been that way.
[1] https://chrome.google.com/webstore/detail/cc%20%20-devtools-...
Yes, because when Apple forked KHTML they made the _least amount_ possible open source and when they faced public pressure and were criticised (note unlike Google - Apple doesn't really have a big business incentive to keep their browser open source anyway) they open sourced the parts that are/were outside WebCore and JavaScriptCore as BSD. Hardly benevolence.
> I'm not a fan of that either, but to be fair it's a Chrome extension[1], not part of Chrome.
That's true - it's also true for other parts of the codebase. I see your point about video codecs, drm and a bunch of other stuff and Google _does_ benefit from the fact companies like Igalia filled with ex-Googlers can contribute significantly to Chromium.
I think it's important to make a distinction here between the engineers "with boots on the ground" - many of them care deeply about the internet and chromium being open and about working on an open source project and the people higher up making the more strategic decisions.
It's also worth mentioning Chromiums is very much a "closed club" with a different (harder) contribution model, builds and meta-builds that work well only if you work for a large-co (otherwise it's built on your machine and takes hours) and it's very unreachable if you're not "in the know" compared to other projects. I don't think that part is malevolence though I just think making an open source project more open is hard.
[1]: It was a little more complicated than just "money grab": https://freedomben.medium.com/centos-is-not-dead-please-stop...
[2]: Pre-empting the inevitable "but the GPL", Red Hat goes above and beyond the requirements of the GPL and could make it way harder to build. Also a huge important chunk of the distro is BSD/MIT/Apache/etc. Without that the GPL'ed only stuff would never be a feasible distro anyway
Brave is also fighting another fight with Google, this time with the Brave for Android browser, where Google has decided that all users want to have Tab Groups. The latest status is that users of the Brave browser for Android still can't get the old Cascade Layout back yet.
More on https://community.brave.com/t/add-tab-cascade-layout-back-to...
https://www.google.com/amp/s/woodworkersworkshop.co.uk/amp/v...
https://apps.apple.com/de/app/amplosion-redirect-amp-links/i...
Where AMP could impact things is for the publisher. Publishers are able to verify their domains/properties, and receive BAT contributions from Brave users visiting their content. If that publisher is having their content served through Google's domain, that would impact their ability to receive support from visitors.
Here's a good sample set (AMP posts on Reddit, sorted (roughly) by popularity):
Think websites that do news, celebrity gossip, music, games and movies.
I remember previously that when I was visiting an AMP link (example: https://www.google.com/amp/s/woodworkersworkshop.co.uk/amp/v...) it was taking me to google.com and displaying a bar on top of the page. Right now google's servers return HTTP 302 redirection and redirect me to the actual page. I'm located in Switzerland. Did something change recently?
Features that should come out on Mozilla will instead come out of Brave...
There are still things about brave that confuse me... like the browser feature that allows giving crypto to content providers...
but as someone who loathes AMP... I support this feature.
Brave sells ads. They get $X normal money from it. The ads are delivered from a local catalog downloaded in bulk (the same way safe browsing blocklists are, for example) and matched on device.
If you opt in to see Brave's ad popups, you get a cut from the revenue those popups generate.
Brave gives this cut as BAT - they buy the coins from the open market.
Brave has a built-in tipping service where you can tip people with BAT. If you do, Brave transfers BAT from your wallet to the tippee (and Brave takes a cut from the transaction).
Tippee has BAT that they can sell because there's at least one buyer of BAT on the market: Brave.
It seems like a sensible system overall, but my specifics may be wrong.
I have always suspected that the current Brave CEO Brendan Eich was a victim of a malicious campaign intended to get him removed from Mozilla (which he co-founded, and later become a CEO of), because he would have been more vocal against Google in Mozilla, and wouldn't have been happy to let the Firefox codebase stagnate while everyone in Mozilla was content with the millions of dollars they were getting from Google. (His religious beliefs / political ideology was just an excuse and just made him an easy target).
Edit: I am not endorsing Brave browser either, as there are some questionable privacy issues with it.
I'm not a fan of them adding this and switching it on, but it's easily disabled...
> Click on the hamburger menu and then select Settings
> Click on Privacy and Security in the sidebar and scroll to Address Bar — Firefox Suggest
> Select or deselect the checkbox for contextual suggestions to turn the feature on or off
> Select or deselect the checkbox for “occasional sponsored suggestions”
Excuse me sir but you definitely sound like a fan.
The really real joke is claiming that proclaiming that Mozilla is a joke is some sort of a joke.
Out-of-the-box I would definitely classify Firefox as ad-ware/spy-ware.
No it's not. That's about as buried as it gets without hiding it in about:config.
"Easily disabled" would be a button right next to the ad that said "never show me this dogshit again."
1. Advertisements appear in places they shouldn’t be. (Yes in Firefox - ads in new tab and address bar).
2. Your web browser’s homepage has mysteriously changed without your permission. (Yes in Firefox - default custom home page)
3. New toolbars, extensions, or plugins suddenly populate your browser. (Yes in Firefox - bundles unwanted, uninstallable extensions)
4. Your computer starts automatically installing unwanted software applications. (Yes in Firefox - studies can install extensions without your knowledge).
5. Collect personal data without your knowledge (Yes in Firefox - ad partners and studies).
Again, technically you are right that there are options to disable some of these things, (most of which are all enabled by default that the majority of users won't be aware of) ... But when a software imitates and behaves like an adware / spyware, Mozilla would do best to listen to their users criticism than call us ignorant.
Even more privacy-respecting options like Vivaldi make their money from search deals, and as much as they try to build their model to be privacy respecting, Brave is still an ad agency.
Next to no one is actually building browsers for a subscription or some other model in that vein. It'd be really hard to get an appreciable userbase that way.
The loss of trust and respect also needs to be considered - when you start doing data collection and introduce intrusive ads, how do I trust you to know the data collection stops?
Google removed ClearURLs from the chrome add-ons store because (I wish I were making it up) the extension's description was too detailed: https://www.ghacks.net/2021/03/25/the-curious-case-of-clearu...
Brave implementing this, while nice, is basically a nothingburger.
Extensions can certainly deliver this type of functionality in large part, but you have to [run an extension]. You need to ran an extension process (with its additional overhead). You need to make sure Google doesn't swoop-in with breaking changes between manifest versions. Then you have to make sure the extension is permitted in the Web Store, and not removed over something as silly as a detailed description.
By delivering this functionality natively, Brave offers a more reliable and efficient solution to the problem of AMP.
But yes, you will need to use a browser to browse the Web
Regards to the "holding site operators and ad revenue hostage," I'm not sure to what you're referring. Perhaps the UI/UX of Brave Rewards ("Payments" at the time) in late 2018? If so, see https://news.ycombinator.com/item?id=31086397 what, I hope, will be a helpful answer.
> By delivering this functionality natively, Brave offers a more reliable and efficient solution to the problem of AMP.
Just because it avoids a separate process doesn't mean it is more reliable or efficient. Further, you offer a subset of the functionality of the URL-cleaning extension I do use, so it's moot.
I don't care if your browser ever becomes a superior product for me. I can't stand the community, who are easily the most aggressive and zealot-y bunch of any open source project I can think of. The comments section of any HN article about Brave becomes a shit-show as Brave users with the emotional maturity of teenagers dogpiling on shouting about how Brandon was the victim of a conspiracy by 'The SJWs', Firefox is "spyware", we're all stupid sheeple for not using Brave, etc.
And then at least one person from Brave shows up and starts condescendingly responding to every comment that isn't supportive of Brave.
There's the history of crypto-bro-y nonsense. The donation-scamming where creators had to "opt out" of Brave pretending to collect donations "for them." And so on.
I also don't want to support a company run by a person who has spent vast amounts of his money supporting some of the most bigoted politicians in our nation's modern history and to causes working to strip people of human rights. I don't want to support him, and I don't want to support people for whom his political activities are not an issue.
- Users who are concerned about AMP can use Brave to bypass Google's infrastructure
- Users for whom AMP is a benefit can continue to use it
- Everybody wins
Your thought experiment is equivalent to "What happens when Google no longer indexes the open web," and I think the answer is "Bing takes Google's place."
>what if AMP is actually a good thing?
People said this when AMP was first announced too.
Good for people with lives comfortable enough to be so off-guard that this didn't set off any alarm bells; but businesses are not your friends.
Thankfully with the benefit of time and hindsight the Texas Attorney General has documented some of the catches for us: https://www.texasattorneygeneral.gov/sites/default/files/ima...
"Google falsely told publishers that adopting AMP would enhance load times, but Google employees knew that AMP only improves the [redacted] and AMP pages can actually [redacted] [redacted] [redacted]. In other words, the ostensible benefits of faster load times for cached AMP version of webpages were not true for publishers that designed their web pages for speed. Some publishers did not adopt AMP because they knew their pages actually loaded faster than AMP pages."
"Google also [redacted] of non-AMP ads by giving them artificial one second delays in order to give Google AMP a [redacted] [redacted] slows down header bidding, which Google uses to turn around and denigrate header bidding for being too slow."
And of course, the reason they did all this:
"Google also designed AMP to force publishers to route rival exchange bids through Google’s ad server so that Google could continue to peek at rivals’ bids and trade on inside information. Third, Google designed AMP so that users loading AMP pages would make direct communication with Google servers, rather than publishers’ servers. This enabled Google’s access to publishers’ inside and non-public user data. AMP pages also limit the number of ads on a page, the types of ads publishers can sell, as well as enriched content that publishers can have on their pages."
https://www.texasattorneygeneral.gov/sites/default/files/ima...
If a publisher simply uses Google Amp on their own site to display websites, then it can be slower.
They slowed the non-AMP ads because they didn't want loading them to interfere with the content the user was interested in reading.
This is what Google may have told the public, and obviously would like you to believe. However, internal Google emails demonstrate very differently: AMP was designed to increase Google's ad revenue.
Same source:
"Google ad server employees met with AMP employees to strategize about using AMP to impede header bidding, and how much pressure publishers and advertisers would tolerate."
I'm not aware of other sources of internal emails on this topic. What were you referring to when you wrote: "internal Google emails demonstrate very differently: AMP was designed to increase Google's ad revenue."?
I was referring to the text in the complaint: The complaint is written off the legal discovery process, presumably in the case of especially a tech company such as Google, the statement that these teams met and discussed this topic would presumably be found in the form of either a meeting invite or the notes from a meeting sent in an internal email.
I think within some margin of interpretation, it's reasonable to state that if the text in the complaint is as such, it's backed by one or more internal emails I personally don't have access to. As I think it's pretty implausible that the Texas AG invented a meeting between the ad team and the AMP team and a reason for it out of thin air.
ec109685's explanation seems plausible and could easily be misexplained in this way if your goal was to get quotes on twitter.
> As I think it's pretty implausible that the Texas AG invented a meeting between the ad team and the AMP team and a reason for it out of thin air.
It doesn't have to be out of thin air to be exaggerated or misconstrued. And I definitely wouldn't rely on indicted Attorney General Ken Paxton for ethical behavior or an even handed application of the law.
That being said, I think it'd be great if all the material in the discovery process was available to the public. A company of Google's size has no excuse to operate in the dark.
This also sets up a situation where the AG can make exaggerated claims now, score the points, and have moved on by the time we get a resolution.
Edit: not sure why I got downvoted. I'm asking a genuine question because I'm always looking for google alternatives, and firefox has been disappointing lately.
Brave does come with Brave Rewards, and optional component which enables users to participate in privacy-preserving advertising (ads are matched locally, on your device). Users who opt-in receive 70% of the associated revenue for ads they see. Rewards are delivered in the form of BAT (and ERC-20 token), which can be kept, or gifted to content creators across the Web as a means of support.
The other 30 percent goes right to Brave's pockets. In other words, they directly profit off of showing you advertisements.
> Rewards are delivered in the form of BAT (and ERC-20 token), which can be kept, or gifted to content creators across the Web as a means of support.
*only if those creators have an ERC-20 wallet. Many creators (like Tom Scott) have had their likeness appropriated without their consent to advertise this monetization scheme, despite the fact that they have no intention of ever using the service. As such, Brave dangles their ad revenue over their head, refusing to pay out in anything other than their own altcoin. It's a scummy design, arguably many times worse than the act of advertising in the first place.
I hate ads, and I go to extreme lengths to stop them and the scummy behavior they inspire. That's why I can't support Brave in good conscience.
Correct. We are able to continue developing Brave with the remaining 30%. In this arrangement, the user chooses whether or not to opt-in, governs the degree to which they will participate, receives more than 2x what Brave gets, and never has their data harvested in the process. Win-win, no?
Regarding the Tom Scott topic, you're quite mistaken there as well. Please see this response (to another user in this thread) for context: https://news.ycombinator.com/item?id=31086397.
Brave offers auto-conversion of received BAT into various other types of assets and currencies. If you prefer Bitcoin, for example, you can choose to have your BAT automatically converted into that asset. No requirement to hold BAT.
Not really? There's no reason you should be entitled to that money. You're effectively doing nothing in this scenario: at least traditional ads actually support the content that is delivered on the site you access. Blocking ads isn't morally objectionable, but playing the role of the middleman and the tax collector certainly is. You can pretend like you deserve the compensation all you want, but from a technical level it's a pretty petty move that's ultimately designed to take advantage of the end-user and turn them into revenue-generating cattle. Yes, they get more money per ad, but they also don't have the benefit of scale. Individually, these users make what, no more than $3 a month from opting-in to ads? Meanwhile, Brave pockets hundreds of thousands. It doesn't add up.
> Regarding the Tom Scott topic, you're quite mistaken there as well. Please see this response (to another user in this thread) for context
So, I wasn't mistaken. Reading through that comment, you're basically admitting that you made a mistake, and had to rush out an update as damage control for a pretty obviously dark pattern. Case closed, don't treat me like a moron.
> Brave offers auto-conversion of received BAT into various other types of assets and currencies. If you prefer Bitcoin, for example, you can choose to have your BAT automatically converted into that asset. No requirement to hold BAT.
But you still need to hold crypto. That's not a refutation for the ERC-20 wallet point.
Ultimately, I think the Brave team is falling into the self-righteous Apple trap. Pretending like you always know what's best for your users and hiding behind a guise of privacy is pretty laughable, and it certainly doesn't make for good optics in the eyes of the greater FOSS and privacy community.
I have the crypto off, but - looking more at the brave site (including the many problems), I'm beginning to err.... be convinced(!?).