canmove, Confirmed users
901
edits
WebAPI/DesignGuidelines: Difference between revisions
Jump to navigation
Jump to search
Note standardizing attack mitigations, highlighting in other specs to avoid monkey patching, and considering exposure to secure origins only (courtesy hsivonen)
(Note standardizing attack mitigations, highlighting in other specs to avoid monkey patching, and considering exposure to secure origins only (courtesy hsivonen)) |
|||
| Line 64: | Line 64: | ||
** use common idioms. | ** use common idioms. | ||
** don't build on top of features specific to one browser. | ** don't build on top of features specific to one browser. | ||
* if you are extending the algorithms of another specification, request that the spec you are extending highlights to its readers the points your spec extends/plugs into | |||
* document and standardize attack vector mitigations so they're done consistently across implementations. | |||
* attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks). | * attempt to avoid "prompt fatigue" (e.g. don't skirt security concerns by prompting to allow the web content to do something as users will have difficulty reading and interpreting the associated risks). | ||
* ensure the API is "webby". | * ensure the API is "webby". | ||
| Line 74: | Line 76: | ||
* the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered. | * the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered. | ||
* standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors. | * standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors. | ||
* sometimes it makes sense to limit API exposure to secure origins only. | |||
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers. | * bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers. | ||
* web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility! | * web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility! | ||