3 ms·

I think there are many issue with this take. Brave is a web browser, putting itself between the creator and the consumer is what it does, by definition. It's th

I think there are many issue with this take. Brave is a web browser, putting itself between the creator and the consumer is what it does, by definition. It's the User Agent. In the case of Brave Today, however, only a preview of the content is shown; when the user clicks, they are directed to the source itself (unlike AMP or some other pervasive middle-man). Serving RSS content doesn't require permission; the public feed itself is permission. It's created for the purpose of content syndication (it's in the name). Brave shows only a preview of content (an image, headline, title, date, and maybe a sentence or two from the feed). For the actual content, the user has to go to the resource itself. As for measuring their Brave user-base, publishers were already in a tough spot. Brave reports itself as "Chrome" to these sites. Ideally, the publisher shouldn't need to know if their users are in Chrome or Brave. This feature (Brave Today) doesn't change this relationship in any way. Your hypothetical (if Brave starting copying and distributing, verbatim, websites) is definitely terrible. But that isn't even remotely close to what's happening here; Brave Today shows less content than search results on DuckDuckGo, Google, Bing, or beyond.

CharlesW 6y ago
> Brave is a web browser… I've clarified my comments above to disambiguate, thank you. > Serving RSS content doesn't require permission; the public feed itself is permission. So does Brave not understand the importance of feed metrics for creators? Or if it does, is the plan is to force creators to get metrics for Brave Today users from Brave?
- jonathansampson 6y ago
  Thank you for clarifying. That said, I'm not sure I understand why a feed source needs to know if a viewer is accessing the content via Brave or Chrome. Regarding feed metrics from Brave, what information would we give over? Brave doesn't know who is reading what; we've made Brave Today in such a way that uses and requests aren't handled by the same entity at the same time. The goal is to have no knowledge, while yielding a personalized experience.
  - CharlesW 6y ago
    > Regarding feed metrics from Brave, what information would we give over? There should be none to give, which is perfectly aligned with your goal to have no knowledge. Brave [the company] should consider interfering with RSS metrics as verboten has interfering with web page metrics. That means that clients/user-agents should grab feed updates from the original RSS, using ETags and Last-Modified to avoid unnecessary fetches of unchanged feeds. (Caching for temporary unavailability is normal and fine.) > …I'm not sure I understand why a feed source needs to know if a viewer is accessing the content via Brave or Chrome. You brought this up, but it isn't a concern I've expressed. Brave Today would ideally have a uniquely identifiable user agent for RSS metrics, but I don't know that it's necessary. (That's all I have to say about this. Thanks for listening.)
    - jonathansampson 6y ago
      > You brought this up… Sorry, I thought that's what you meant by "this destroys the ability of creators to get even basic readership metrics for people who might choose to use Brave" earlier. > Brave Today would ideally have a uniquely identifiable user agent for RSS metrics, but I don't know that it's necessary. That's definitely something I could see a publisher requesting in the future; we've done something similar with custom headers in requests, standing in for a unique user-agent string.

CharlesW 6y ago

> Brave is a web browser… I've clarified my comments above to disambiguate, thank you. > Serving RSS content doesn't require permission; the public feed itself is permission. So does Brave not understand the importance of feed metrics for creators? Or if it does, is the plan is to force creators to get metrics for Brave Today users from Brave?

jonathansampson 6y ago
Thank you for clarifying. That said, I'm not sure I understand why a feed source needs to know if a viewer is accessing the content via Brave or Chrome. Regarding feed metrics from Brave, what information would we give over? Brave doesn't know who is reading what; we've made Brave Today in such a way that uses and requests aren't handled by the same entity at the same time. The goal is to have no knowledge, while yielding a personalized experience.
- CharlesW 6y ago
  > Regarding feed metrics from Brave, what information would we give over? There should be none to give, which is perfectly aligned with your goal to have no knowledge. Brave [the company] should consider interfering with RSS metrics as verboten has interfering with web page metrics. That means that clients/user-agents should grab feed updates from the original RSS, using ETags and Last-Modified to avoid unnecessary fetches of unchanged feeds. (Caching for temporary unavailability is normal and fine.) > …I'm not sure I understand why a feed source needs to know if a viewer is accessing the content via Brave or Chrome. You brought this up, but it isn't a concern I've expressed. Brave Today would ideally have a uniquely identifiable user agent for RSS metrics, but I don't know that it's necessary. (That's all I have to say about this. Thanks for listening.)
  - jonathansampson 6y ago
    > You brought this up… Sorry, I thought that's what you meant by "this destroys the ability of creators to get even basic readership metrics for people who might choose to use Brave" earlier. > Brave Today would ideally have a uniquely identifiable user agent for RSS metrics, but I don't know that it's necessary. That's definitely something I could see a publisher requesting in the future; we've done something similar with custom headers in requests, standing in for a unique user-agent string.