#496: Content Indexing API

Visit on Github.

Opened Apr 8, 2020

Hello TAG!

I'm requesting a TAG review of Content Indexing.

The content index allows websites to register their offline enabled content in the browser. This allows the browser to improve their offline capabilities and offer content to users to browse through while offline. This data could also be used to improve on-device search and augment browsing history.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the work on this specification is currently being done: WICG

You should also know that an early TAG review was done here: https://github.com/w3ctag/design-reviews/issues/379

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Apr 1, 2020 (See Github)

Ken: intent to ship is happening in chrome?

Dan: leaves comment asking about venue

Ken: is this about content being shown in other places in the UI - then people will be aggressively caching things in order to get shown...

Dan: if something shows up in the notification tray, that is big money. This requires scrutiny.

... "sites to increase user engagement" - that makes me concerned.

Yves: they want to use periodic background sync to refresh and that part is controversial for privacy reasons.

Ken: leaves comment

[bumped]

Comment by @torgo Apr 28, 2020 (See Github)

Hi @rayankans @jakearchibald - to clarify, is this intended to go from WICG into the Service Workers working group? If so, what is the time-line intended?

Comment by @kenchris Apr 28, 2020 (See Github)

Doesn't this link to the new image resource spec proposal, instead of web app manifest?

Comment by @kenchris Apr 28, 2020 (See Github)

We discussed this in the TAG today, as this will be show in important places (Android Slices etc) there is the chance that people will do something similar to SEO to get this to show up in these places, as that can mean big money. This might also lead to aggressive indexing and bandwidth use.

We believe there should be at least a section in the explainer discussing these scenarios.

Comment by @rayankans Apr 29, 2020 (See Github)

is this intended to go from WICG into the Service Workers working group?

I think the Web Applications Working Group is a better fit for this API.

Doesn't this link to the new image resource spec proposal, instead of web app manifest?

It does now :) I was waiting for the image resource TAG review to go through.

I also added an Abuse Considerations section in the explainer: https://github.com/wicg/content-index#abuse-considerations

Discussed May 1, 2020 (See Github)

Ken: they are waiting for TAG image resource review....... It's closed...

Ken: they added an abuse considerations section but it's small...

Dan: can we encourge them to think more about mitigations against abuse? Should any of the things they've listed be considered to be aprt of the spec itself?

Ken: i think it's difficult... but the spec should also be part of the spec itself...

[ken leaves a comment]

Comment by @kenchris May 12, 2020 (See Github)

Image resource has passed TAG review and that issue is now closed: https://github.com/w3ctag/design-reviews/issues/490

Comment by @kenchris May 12, 2020 (See Github)

We find the Abuse Considerations section a bit short, so maybe it could be expanded a bit. Also can you make sure that something like this makes it into the spec itself?

Comment by @rayankans May 13, 2020 (See Github)

Thanks for the feedback @kenchris.

I expanded the Abuse Considerations section in the explainer to give some more background and include some more ways to handle this scenario.

I also mentioned the scenario in the spec's Privacy Considerations, and added a note within the display algorithm.

Comment by @kenchris May 13, 2020 (See Github)

Thanks you! and thanks for consulting with the TAG!