Document /v3/firefox/save
Categories
(Firefox :: Pocket, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox42 | --- | affected |
People
(Reporter: Yoric, Unassigned)
Details
Pocket places calls to API "/v3/firefox/save". This call doesn't look documented yet. It needs to be documented.
Pocket places calls to API "/v3/getSuggestedTags" as well which also doesn't appear to be documented.
|
||
Comment 2•9 years ago
|
||
(In reply to David Rajchenbach-Teller [:Yoric] (use "needinfo") from comment #0) > It needs to be documented. This kind of entitlement without a clear rationale rubs me the wrong way. This is a Firefox-specific Pocket endpoint, documenting it doesn't seem particularly necessary or high priority, and tracking its documentation in our Bugzilla doesn't really make sense.
|
Reporter | |
Comment 3•9 years ago
|
||
> This kind of entitlement without a clear rationale rubs me the wrong way.
I'm probably missing something. This is a case of Firefox using a (so far) undocumented protocol. I don't see a good reason to not make it a documented protocol. Plus Documentation Is Always Good (tm).|
|
||
Comment 4•9 years ago
|
||
> I don't see a good reason to not make it a documented protocol.
I think the burden of proof goes the other way. What purpose would it serve?|
|
Reporter | |
Comment 5•9 years ago
|
||
Well, undocumented code (and protocols) hinders reviews, maintenance, contributions, refactorings and feature evolution. While this specific piece of code also has a political/PR baggage, which makes discussions on it complicated, I don't see any reasons why it should not strive to support all of the above.
It should be noted that I agree this is should not be a high priority. I believe the priority status put on this was normal. However, I disagree that it is not particularly necessary. Having a documented API regardless of if the function call is to the local OS or to a remote service in a RPC style (such as this case) would be for the purpose of the following: - Make it more easily accessible to others on what data is transferred from the browser (Mozilla Manifesto Principle #4) - Encourage discussion on how the API could be improved or what features could be added (Mozilla Manifesto Principle #5) - Help encourage interoperability with the API (Mozilla Manifesto Principle #6) - Improves transparency (Mozilla Manifesto Principle #8) While it has been pointed out previously that the integration is consistent with Mozilla Manifesto Principle #9 (which I am not disagreeing with), I don't think that needs to be at the exclusion of the other principles.
|
||
Comment 7•4 years ago
|
||
This bug has been closed due to inactivity and/or the potential for this bug to no longer be an issue with the new Discovery Stream-powered New Tab experience, and improvements to Pocket’s integration with Firefox.
Please help us triage by reopening if this issue still persists and should be addressed.
Thanks!
The /v3 end points that are documented are /v3/add, /v3/send and /v3/get
The end points used by browser/components/pocket/content/pktApi.jsm is:
/v3/getItemPreview, /v3/firefox/get-app, /v3/getSuggestedTags and /v3/firefox/get
When Pocket was removed from the Firefox Add-On and integrated into Firefox, the following was stated as reasons to justify it:
(1) The integration is open source (reasonably modifiable by third parties)
(2) The protocol is openly documented
(3) Mozilla Foundation is holding Pocket to it's standards for the privacy policy
(4) Pocket is optional
Claim 1 has been problematic: The undocumented end points go against the spirit of being open source. Third-party modification to pktApi.jsm must use trial and error to determine if the change violates the undocumented use of the end point. This clearly discourages third party involvement in maintaining the code.
Claim 2 has been problematic: The URL pointing to Pocket's developer API does not document the API end points that exist in the integration despite the claim by members of the Mozilla Foundation. This also should have been addressed to deal with the spirit in which Claim #1 was made.
Claim 3 has been problematic: The Mozilla "* privacy not included" project has held other companies to a higher standard that the Mozilla Foundation has held Pocket to. While the privacy policy indicates the user has the ability to delete personal information, there is no statement of the length of data retention. How long after deletion or modification is the old data still held in the database or on backups is not disclosed. Mozilla Firefox accounts has supported two-factor authentication while Pocket still does not seem to offer 2fa from what I can tell. Mozilla has a security bug bounty to encourage third-party review and responsible disclosures, Pocket has agreements with specific unnamed third parties and follows "industry standard practices." This list could go on how much delta there is between Mozilla and Pocket for privacy policy but I'm not sure there is any point in giving further details.
Claim 4 has been problematic: While it is true each individual has the option not to use, the point of advocating a browser to others is to be able to put trust in the browser and the group making it as a whole. Since the Pocket integration, Mozilla Foundation has continued to advocate the importance of running a web browser that is maintained to the ideals of the Mozilla Manifesto. Putting users one click away from an integration that still fails claims 1-3 is not consistent with this advocacy. No one from the Mozilla Foundation when advocating Firefox clears up the lines that have been grayed between how the rest of Firefox is maintained and how Pocket is.
Overall, the philosophy of trying to "address" this issue passively by just waiting 5 years and hoping that makes the issue go away is extremely disappointing. You can close this issue at any time but it isn't because of modification made from the new Discovery Stream, it is due to an on-going half decade long lack of respect and posturing when it comes to the Mozilla Manifesto. I am at a complete lost as to how to best articulate how upsetting that really is.
Description
•