Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Thu, Jan 11, 2018 at 11:43 AM, Daniel Veditz  wrote:
> On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik 
> wrote:
>>
>> Also good methodology worth repeating:
>>"thinking ... through all the way up to and including the user
>> experience, makes for a much more viable approach"
>
>
> Including, of course, "how will 4chan trolls abuse this?" and "how will
> ad-tech trackers abuse this?"

Why stop there?

What about "how will state-level-actors abuse this to mislead,
surveil, and censor users?"  (only 1/2 :)

While I agree with asking the sorts of questions you're asking, I
think such abuse-cases are a distinctly different class of design
problems/considerations than what I believe was a positive UX design
methodology that Anne expressed, of making sure users can actually
viably get done what they want to get done.

That being said, perhaps consider filing issues to add your questions
to the W3C Security & Privacy questionnaire, especially if you think
we should be asking them for every web standards spec/API/feature we
consider contributing to and /or implementing.

https://github.com/w3ctag/security-questionnaire

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Daniel Veditz]

On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik 
wrote:

> Also good methodology worth repeating:
>"thinking ... through all the way up to and including the user
> ​​
> experience, makes for a much more viable approach"
>

​Including, of course, "how will 4chan trolls abuse this?" and "how will
ad-tech trackers abuse this?"​

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Wed, Jan 10, 2018 at 2:19 AM, Anne van Kesteren  wrote:
> On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre  wrote:
>> WebShare is more a trimmed down version of the WebActivities/WebIntents
>> apis. I think it's unfortunate that instead of fixing the issues with WA/WI
>> they went with a single purpose API - this doesn't scale at all with uses
>> case they don't think about and limits the innovation for content
>> publishers.
>
> It's a little off-topic, but the overall issue with both of those
> technologies was that the approach was too general. And such overly
> generic APIs do not translate to good UX. I think starting small and
> slowly expanding the types of things we want to make extensible, and
> thinking those through all the way up to and including the user
> experience, makes for a much more viable approach.

You're both right.

WA/WI were both way-over-architected*, however with WebShare, it's
overcorrecting the other direction, it's an API that may be too
limited, and in particular limited in such a way that unnecessarily
(and badly) biases large anti-privacy (among other ills) vertical
content silos.

While I generally agree with Anne's philosophy "starting small and
slowly expanding the types of things we want to make extensible", I
think the "which small" needs to be evaluated by a frank "Is this
actually *good* for the open web, neutral, or actively bad?"
(unfortunately the latter in this case).

Also good methodology worth repeating:
   "thinking ... through all the way up to and including the user
experience, makes for a much more viable approach"

Finally Anne is right about it being a little off-topic. This github
issue may be a better place for WebShare follow-ups (more specifics
there): https://github.com/mozilla/standards-positions/issues/27

Thanks,

Tantek

*https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

On Tue, Jan 9, 2018 at 8:51 AM, L. David Baron  wrote:
> On Wednesday 2018-01-03 15:15 +, Jonathan Kingston wrote:
>> I am suggesting the removal of navigator.registerContentHandler
>> 
>> API used to register a web page to handle content types.
>>
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds. We don't have telemetry on this feature however we do
>> know that registerProtocolHandler has around 0.2% usage and this feature is
>> implemented in multiple browsers and isn't specific to Firefox.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169
>>
>> There is a small risk of breakage that we could decide to delay and instead
>> implement telemetry. However if the site is feature testing rather than
>> user agent testing there shouldn't be an issue here. As this API throws
>> errors there is likelihood websites account for it throwing anyway. I would
>> prefer however to let the removal ride the trains due to it's low risk
>> before 61 so our ESR doesn't have it.
>>
>> Alternatively we could restrict this API to Secure Context only due to the
>> risk of passing web content to an insecure context. This would be aligned
>> with our overall plan regarding HTTP APIs.
>>
>> Removal of this feature requires the removal of some internal tests and to
>> stop ignoring a web platform test.
>>
>> The rationale:
>>
>> - This API had bugs filed on it's implementation
>> - Is only implemented by Firefox
>> - The API is now non standard
>> - No other browsers have intent to implement
>
> I'm a little hesitant here -- this is an important feature for
> allowing Web apps to fulfil the function that desktop apps do, and
> I'd rather push to see it expand.
>
> For example, if we added support for registering for text/calendar,
> then Google Calendar could choose to register for that, and thus
> become the handler for random ICS files that I'm served by sites
> that allow me to make appointments.

Agreed.

There has also been a bit of a resurgence in Web (feed) reader
development in the past two years (picked up since Google Reader
shutdown), many (most?) open source at that. E.g.

https://woodwind.xyz/

Additional examples here: https://indieweb.org/feed_reader

Were these readers to implement registerContentHandler to register for
the Atom & RSS content types, it would turn the zillions of little
orange [XML] links/buttons on websites into decentralized opt-in
"Follow" buttons for the web, without having to change existing
publishers.

However: I don't know if any of these new readers support
registerContentHandler today (or why they would not have already,
whether not knowing about it, or due to being Firefox only).

I am investigating into these readers and will follow-up.


> Right now desktop calendar apps have more power than web calendar
> apps do here, for no good reason, and it seems like we ought to be
> trying to change that.

Agreed, same with desktop addressbooks, text/directory, vCard,  web
based address books, etc.

The problems with registerContentHandler noted in this thread seem
fixable, especially we're the only remaining (live) implementation, so
not reason enough to deprecate / remove per se.

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[rektide]

I really like this extension mechanism for the web. Unlike, say, 
registerProtocolHandler, which is relatively widely supported, 
registerContentHandler allows extensibility for experiencing resources on the 
web while still remaining on the firm earth of HTTP and the web.

If possible, I'd prefer Firefox move it to Secure Context only rather than 
remove it. The RSS use case alone is a good and a strong use case!

It is very very unfortunate IMO that other browsers have not implemented this 
capability. I would prefer changing that fact than removing the capability from 
Firefox. Failing that, I would prefer Firefox maintain this very longstanding, 
interesting and enriching capability. The ability to grow the amount of content 
the browser can help the user navigate is an important capability, and nothing 
else does the job at all like registerContentHandler(). Ty.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Anne van Kesteren]

On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre  wrote:
> WebShare is more a trimmed down version of the WebActivities/WebIntents
> apis. I think it's unfortunate that instead of fixing the issues with WA/WI
> they went with a single purpose API - this doesn't scale at all with uses
> case they don't think about and limits the innovation for content
> publishers.

It's a little off-topic, but the overall issue with both of those
technologies was that the approach was too general. And such overly
generic APIs do not translate to good UX. I think starting small and
slowly expanding the types of things we want to make extensible, and
thinking those through all the way up to and including the user
experience, makes for a much more viable approach.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Fabrice Desre]

On 01/09/2018 04:59 PM, Jonathan Kingston wrote:

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.


WebShare is more a trimmed down version of the WebActivities/WebIntents 
apis. I think it's unfortunate that instead of fixing the issues with 
WA/WI they went with a single purpose API - this doesn't scale at all 
with uses case they don't think about and limits the innovation for 
content publishers.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.

Also if there is need for web extension functionality here that could
be addressed without having to expose this to the web.

I have an r+ on the patch which disables this in Nightly and early
Beta, unless there are objections I will land this in central in a few
days and we can measure if there is any issues before filing another
removal for stable.


[1] https://github.com/WICG/web-share-target/blob/master/docs/explainer.md



On Tue, Jan 9, 2018 at 4:54 PM, L. David Baron  wrote:

> On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> > I'm a little hesitant here -- this is an important feature for
> > allowing Web apps to fulfil the function that desktop apps do, and
> > I'd rather push to see it expand.
> >
> > For example, if we added support for registering for text/calendar,
> > then Google Calendar could choose to register for that, and thus
> > become the handler for random ICS files that I'm served by sites
> > that allow me to make appointments.
> >
> > Right now desktop calendar apps have more power than web calendar
> > apps do here, for no good reason, and it seems like we ought to be
> > trying to change that.
>
> Though given Anne's point about wanting an API that doesn't do two
> loads of the content, I guess removal is probably the right thing.
> But it would really be good to work on standardizing something
> better here.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[L. David Baron]

On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> I'm a little hesitant here -- this is an important feature for
> allowing Web apps to fulfil the function that desktop apps do, and
> I'd rather push to see it expand.
> 
> For example, if we added support for registering for text/calendar,
> then Google Calendar could choose to register for that, and thus
> become the handler for random ICS files that I'm served by sites
> that allow me to make appointments.
> 
> Right now desktop calendar apps have more power than web calendar
> apps do here, for no good reason, and it seems like we ought to be
> trying to change that.

Though given Anne's point about wanting an API that doesn't do two
loads of the content, I guess removal is probably the right thing.
But it would really be good to work on standardizing something
better here.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[L. David Baron]

On Wednesday 2018-01-03 15:15 +, Jonathan Kingston wrote:
> I am suggesting the removal of navigator.registerContentHandler
> 
> API used to register a web page to handle content types.
> 
> Firefox has an implementation that only can be used to allow a web page to
> handle RSS feeds. We don't have telemetry on this feature however we do
> know that registerProtocolHandler has around 0.2% usage and this feature is
> implemented in multiple browsers and isn't specific to Firefox.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169
> 
> There is a small risk of breakage that we could decide to delay and instead
> implement telemetry. However if the site is feature testing rather than
> user agent testing there shouldn't be an issue here. As this API throws
> errors there is likelihood websites account for it throwing anyway. I would
> prefer however to let the removal ride the trains due to it's low risk
> before 61 so our ESR doesn't have it.
> 
> Alternatively we could restrict this API to Secure Context only due to the
> risk of passing web content to an insecure context. This would be aligned
> with our overall plan regarding HTTP APIs.
> 
> Removal of this feature requires the removal of some internal tests and to
> stop ignoring a web platform test.
> 
> The rationale:
> 
> - This API had bugs filed on it's implementation
> - Is only implemented by Firefox
> - The API is now non standard
> - No other browsers have intent to implement

I'm a little hesitant here -- this is an important feature for
allowing Web apps to fulfil the function that desktop apps do, and
I'd rather push to see it expand.

For example, if we added support for registering for text/calendar,
then Google Calendar could choose to register for that, and thus
become the handler for random ICS files that I'm served by sites
that allow me to make appointments.

Right now desktop calendar apps have more power than web calendar
apps do here, for no good reason, and it seems like we ought to be
trying to change that.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Anne van Kesteren]

On Tue, Jan 9, 2018 at 5:30 PM, Gervase Markham  wrote:
> I'm sure unshipping it is the right thing to do, but it's very sad. :-(
> Allowing web pages to register for content types and protocols seems
> kind of important if you want the web to have the capability of
> seamlessly replacing desktop and mobile apps.

It might still be worth pursuing, but note that the current API is
rather broken and results in two loads of the content (and how it
integrated with navigation/fetching was never really defined in
sufficient detail). A better API would be handing of the stream of the
download somehow to the third-party. Also note that the "protocol" API
is still there.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Gervase Markham]

On 03/01/18 15:15, Jonathan Kingston wrote:
> I am suggesting the removal of navigator.registerContentHandler
> 
> API used to register a web page to handle content types.

I'm sure unshipping it is the right thing to do, but it's very sad. :-(
Allowing web pages to register for content types and protocols seems
kind of important if you want the web to have the capability of
seamlessly replacing desktop and mobile apps.

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Frederik Braun]

On 04.01.2018 04:46, Karl Dubost wrote:
> Jonathan,
> 
> Le 4 janv. 2018 à 00:15, Jonathan Kingston  a écrit :
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds. 
> 
> in Firefox 8, the feeds panel was removed from Firefox. It created a bit of 
> bad press. 
> Some people have developed add-ons to cope with the removal.
> https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox
> 
> If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
> I can see a couple of addons for reading RSS/Atom feeds.

I found 49 addons in DXR.

23 of those occurrences are irrelevant:
- uglify.js has list of known dom properties, which seem important for
mangling.
- Firefox OS simulators
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Karl Dubost]

Jonathan,

Le 4 janv. 2018 à 00:15, Jonathan Kingston  a écrit :
> Firefox has an implementation that only can be used to allow a web page to
> handle RSS feeds. 

in Firefox 8, the feeds panel was removed from Firefox. It created a bit of bad 
press. 
Some people have developed add-ons to cope with the removal.
https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox

If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
I can see a couple of addons for reading RSS/Atom feeds.

Do we have a way to know how many add-ons might break with this removal?


Also
https://github.com/search?utf8=%E2%9C%93=registerContentHandler=Issues


Chromium world.
Implementation https://bugs.chromium.org/p/chromium/issues/detail?id=11359
Disabled inhttps://bugs.chromium.org/p/chromium/issues/detail?id=44984
Discussions in https://bugs.chromium.org/p/chromium/issues/detail?id=86115

WebKit world.
Proposed https://bugs.webkit.org/show_bug.cgi?id=73177 (last activity 2014)



-- 
Karl Dubost, mozilla  Webcompat
http://www.la-grange.net/karl/moz





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

> I like the approach of  disabling a feature (behind a pref) in
non-Release (Beta and Nightly) for a few releases, to see what surfaces in
bug reports.

This is reasonable, it is the approach we will be taking with the device
sensors. Obviously it takes a little more work however I'm guessing the
breakage risk will be higher than events .

As you mention, I'm going to propose that we move to implement a pref to
disable this feature instead. In Nightly and early beta enable this pref by
default and see if we have any issues.

Thanks
Jonathan

On Wed, Jan 3, 2018 at 7:49 PM, Mike Taylor  wrote:

> Hi Jonathan,
>
> > On Jan 3, 2018, at 9:15 AM, Jonathan Kingston  wrote:
> > There is a small risk of breakage that we could decide to delay and
> instead
> > implement telemetry. However if the site is feature testing rather than
> > user agent testing there shouldn't be an issue here. As this API throws
> > errors there is likelihood websites account for it throwing anyway. I
> would
> > prefer however to let the removal ride the trains due to it's low risk
> > before 61 so our ESR doesn't have it.
>
> I’m never confident sites are doing feature detection or handling errors…
> I like the approach of  disabling a feature (behind a pref) in non-Release
> (Beta and Nightly) for a few releases, to see what surfaces in bug reports.
>
> > - Is only implemented by Firefox
>
> (It was also in Opera Presto 11.60+, RIP)
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Mike Taylor]

Hi Jonathan,

> On Jan 3, 2018, at 9:15 AM, Jonathan Kingston  wrote:
> There is a small risk of breakage that we could decide to delay and instead
> implement telemetry. However if the site is feature testing rather than
> user agent testing there shouldn't be an issue here. As this API throws
> errors there is likelihood websites account for it throwing anyway. I would
> prefer however to let the removal ride the trains due to it's low risk
> before 61 so our ESR doesn't have it.

I’m never confident sites are doing feature detection or handling errors… I 
like the approach of  disabling a feature (behind a pref) in non-Release (Beta 
and Nightly) for a few releases, to see what surfaces in bug reports.

> - Is only implemented by Firefox

(It was also in Opera Presto 11.60+, RIP)

--
Mike Taylor
Web Compat, Mozilla


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I am suggesting the removal of navigator.registerContentHandler

API used to register a web page to handle content types.

Firefox has an implementation that only can be used to allow a web page to
handle RSS feeds. We don't have telemetry on this feature however we do
know that registerProtocolHandler has around 0.2% usage and this feature is
implemented in multiple browsers and isn't specific to Firefox.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169

There is a small risk of breakage that we could decide to delay and instead
implement telemetry. However if the site is feature testing rather than
user agent testing there shouldn't be an issue here. As this API throws
errors there is likelihood websites account for it throwing anyway. I would
prefer however to let the removal ride the trains due to it's low risk
before 61 so our ESR doesn't have it.

Alternatively we could restrict this API to Secure Context only due to the
risk of passing web content to an insecure context. This would be aligned
with our overall plan regarding HTTP APIs.

Removal of this feature requires the removal of some internal tests and to
stop ignoring a web platform test.

The rationale:

- This API had bugs filed on it's implementation
- Is only implemented by Firefox
- The API is now non standard
- No other browsers have intent to implement

Thanks
Jonathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform