eh78ssxv2f

There are many cases where Google has used dark patterns to gather data from users. Now, the ToS may mention those cases clearly, but that's not an excuse for the Google's behavior.

Recent examples: Google tracking users per Chrome installation ID [1], Chrome exempting Google sites from user site data setting [2], Chrome experimenting with silently proxying user traffic through their servers [3].

[1] https://news.ycombinator.com/item?id=22236106 [2] https://news.ycombinator.com/item?id=24817304 [3] https://news.ycombinator.com/item?id=25337995

Do we know the reasoning behind the bias?

I don't understand how gnucash is more critical than Arduino, wine or nginx. Is gnucash very widely used?

Exactly.

Besides privacy and obvious web-centralization issues, there are bunch of security issues associated with proxying the traffic. Apple and Mozilla brought these issues to the attention of Google during SxG spec discussions. At that time, Google's rebuttal was that SxG is a opt-in feature for sites.

Quoting from [1] (Mozilla's official position on SxG): "Sites opt-in to using this mechanism, and in doing so need to be aware that this comes with some risks, but in doing so they enable a new feature".

This time, Google really did not handle any of the previously discussed security/privacy concerns. Instead, they just went ahead and started proxying the user's traffic without the opt-in from the users or the sites.

[1] https://docs.google.com/document/d/1ha00dSGKmjoEh2mRiG8FIA5s...

I commented on [1] too, but it's worth mentioning here as well as it clearly shows the stark difference between Google and Apple/Cloudflare.

Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them [1].

At exactly the same time, Google here is working on proxying non-Google browser traffic through them without consents from either the user or the publisher.

[1]: https://news.ycombinator.com/item?id=25344358

What a stark difference between Google and Apple/Cloudflare.

Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them.

At exactly the same time, Google is working on proxying browser traffic through them without any consents [1].

[1]: https://news.ycombinator.com/item?id=25337995

How do you guarantee anonymity to the users filling out the survey? The surveyor could send different increment URLs to different users.

For Enterprise Android devices (i.e., the one owned by the employer), the employers always had the option to install device management policy and disable parts of the phone based on those policies (e.h., remotely disable phone of an employee that was terminated). The other evergreen use case is for the parents to remotely disable/control/set policies for the phone for kids.

In this case, the telcos are just using the same device management policy. They can do so because they own the phone (have physical access to it and their legal contacts allow them to do it). I don't think Google did something specific here to enable this feature for telcos.

Note that the iPhones also has similar feature. So, switching is not going to help.

> A search engine from a non-advertising-supported company is great news.

Currently, Apple actually gets money from Google for selecting the latter as its default search engine. Not only Apple will lose that money but would also need to dump money in developing + maintaining the search engine.

May be their goal is to just provide a more privacy-sensitive search but I'm a bit cynical about that motivation. So, the economic model is still unclear to me.

> No the concern is they aren't subject to the laws of our land

What specific laws of the US land are they not subject to?

Agreed. In my mind, if the server is using plain HTTP, and the attacker has control over parts of the network, then plain-old DNS is not the only attack model. The attacker does not need to hack DNS, they can just manipulate the content on the wire.

> If so, then they fire up Nginx and serve poisoned PDFs to anyone who connects to it.

Even if the attacker redirects the traffic, it still needs to serve the HTTPS/SSL certificates. How will the attacker do that?

It's not Google that's preaching this. It's Chrome. Sure, Chrome is owned by Google. but at the scale of Google, you might as well consider them as independent organizations.

> so that basically your client gets to pick the second 1/2 of your address now. And the nice thing is, most major platforms will actually run multiple addresses in parallel, allowing new connections to use a new address while old connections keep using the old one.

This is really interesting and I was not aware of this. Are there any links where I can read about this more? I tried searching around, but did not find anything.

Google is probably so big that we might as well consider Chrome and rest of the Google as separate entities.

They could use video conferencing.

That's a very "brave" position. We will show you ads without following laws of the land (Ctrl-F "FTC" in the github thread). If the user falls for our unlawlful ads, then it's the user that's stupid?

> It's obviously legal when companies in the industry do it.

I'm not familiar with specific laws in UK, but it's possible that the industry has to seek a license before they start experimenting with explosives.

Does anybody has examples of websites that do this? It would be useful to see this in action.

> We've never done anything like "swapping ads with their own".

If I use the Brave in its intended mode, then EFFECTIVELY it does swap ads. By intended mode, I mean the way Brave is supposed to be used. From [1], here are the main selling points of Brave:

1. "Block data-grabbing ads and trackers"

2. "Tip and contribute to websites directly through Brave Rewards"

Turning both those options EFFECTIVELY swaps developer ads with your own ads. The web developer who spent tons of resources in creating the content is effectively at the mercy of the Brave who makes tons of money.

[1] https://brave.com/

That's great. When is it coming to Stable? Also, des the ad traffic generated by Brave also goes through the Tor?

How is the user's IP address hidden from the servers?

> Separate to this, Brave has a rewards system users can choose to enable which can show OS-level notifications of advertiser content in a privacy-respecting way.

Can somebody expand a bit on how the ads are shown in privacy-respecting way? Are they not personalized? That seems unlikely.

If the matching is done locally, is Brave downloading hundreds of ads on the device, and then showing only the one that were picked by local ML algorithm?

I'm still confused by this study. If the brave browser is not contacting the backend, how does it fetch the latest ad block sets or the native ads? It seems like the browser has to contact its own servers to do any of these things.

How would this work with third party cookie blocking that Chrome is planning to start (https://blog.chromium.org/2020/01/building-more-private-web-...)?

In terns of privacy, does it actually help with reducing IP based fingerprinting? I looked up Wireguard and Mullvad help pages, but could not find anything. Only thing I found was Mullvad saying [1] that it uses static IPs and it's not ideal :(

[1] https://mullvad.net/en/help/why-wireguard/

There might be a small subset of websites that do not show popup. However, the question is whether the users adjust their browsing behavior based on those popups or not? If the users have just become acclimatized to clicking on them, then the situation has not really changed in any meaningful way.

This article is also from 2014. I wonder if the return process is smoother now.

AFAICT, the author does not explain it, but why did the author chose this benchmark? Is it a good approximation of what webpages do in the wild?

The "change" that Amazon keeps can be fixed irrespective of how they distribute the money to the authors.

Lets say user pays $10/month fee. Amazon decides it wants to keep $2 and distribute $8 to authors. Now, there are different ways of accomplishing that:

(i) Distribute proportionately based on which books user downloaded. If user downloaded N books during the month, author of each of the books gets $8/N.

(ii) Distribute proportionately based on amount of time spend by user on each book. If user spent T hours in Kindle during the month, and T_1 time on one of the books, then the author of that book gets $8*T_1/ T.

There are pros and cons of both approaches in terms of fraud prevention, user engagement etc.