dewitt / opensearch Goto Github PK

Hi,

I would like to cite OpenSearch API in a paper I'm writing.

Any suggestions on how to do this?
Would be nice to include this in the README.

Thanks!

T

Enable GitHub Pages and post the URL onto the repo information (next to the description)

Should go here https://dewitt.github.io/opensearch

The web page won't be usable, but this is the first step

Hello. I'm here from MDN. Can you add in Readme information about what browsers support OpenSearch?

Check out this Pi Brainstorm project idea. Follow this link to read more details about it pi://brainstorm.pi/project/60de794d35accf62f3ce4b7e

You have a little problem with the table of content at the beginning of the opensearch-1-1-draft-6.md file. Paragraphs which have the same name (like Overview, or Example) links to the first occurrence of these paragraph.
For instance, the second Overview link should links to https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md#overview-1 instead of https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md#overview.

To avoid broken links externally, it'd be great to have a URL for the latest publication.

The current specification draft (1.1 Draft 6) adds recommendations do add response metadata to HTML4 and XHTML documents by specifying the OpenSearch namespace in the "profile" attribute of the "head" tag.

This attribute is deprecated in HTML5, and we should use a link rel="profile" instead. Maybe you should write it to the OpenSearch specs.

Before i used this great online tool:
Ready2Search
Cf in documentation of developer.mozilla.org:
Ready2Search - create OpenSearch plugins. Customized Search through Ready2Search

But it seems down now?
Maybe you know a similar tool?

If not can you create one for us ?

Not sure where to ask this, but any idea what happened to

http://a9.com/-/spec/opensearch/1.1/

?

It's 404 now.

We now have 2:

• https://en.wikipedia.org/wiki/OpenSearch
• https://en.wikipedia.org/wiki/OpenSearch_(software)

Hello,

I've recently used an OpenSearch description files to add custom search engines to the Firefox browser. using a OpenSearch XML descriptor file allows any website that has a search page actionable with a GET request to become a custom search engine on Firefox.

This also applies also to websites that do not provide an OpenSearch description XML.

Preparing this XML is easy, the basic workflow I follow is:

1. create 2 files:

• a bare HTML file with the required rel="search" pointing to ...
• ... the OpenSearch XML descriptor in which the Url -> template attribute will be used to perform searches

2. pull up on localhost a web server serving these two files
3. point my browser to localhost and add the custom search engine pointing to an external entity search

Now, in my opinion there's a problem here: the OpenSearch specification allows the browser to not check that the Url -> template parameter is really matching the domain where the files described in point (1) are being served. From localhost I can add a search engine pointing to https://www.newsearchengine.com/search?q={searchTerms}.

This opens scenarios in which a website can point the user to a search page serving malicious content back to the query performed by the user's browser.

Example: www.innocent_site.com has been compromised and the main page is being served with the following injected snippet:

<link rel="search" type="application/opensearchdescription+xml" 
  href="https://www.innocent-site.com/osd.xml"
  title="Our Powerful Product Search"/>

Please note the domain in the href tag is slightly different (a dash instead of an underscore). That XML file can then point the user to anywhere, allowing malicious content download, ransomware or pointing to a phishing site.

Users really are not aware of what is happening because they have no evidence of the visited website in the URL bar.

I've prepared an simple (and innocuous) proof at this url: the XML uses the search engine of the Medium platform, advertised by their OpenSearch descriptor XML.

There should be a way to force a match check of at least the three URLs involved:

1. the domain that serves the OpenSearch decription XML
2. the domain in the href attribute of the OpenSearch decription link tag
3. the domain pointed by the 'Url -> template" attribute in the XML file

If any of these three domains is not matching, the browser should raise a warning.

Mitigating factors:

• the user must be persuaded to add the website to the their own custom search engine list
• this would only affect only Firefox users

however, the OpenSearch XML can be used for orher purposes, the custom search feature is just a tiny part of it.

Opinions?

Google implements this to chrome, and I've used google's implementation to build ontop of their work to provide rich search suggestions in the browser omnibox - https://github.com/AskAlice/search.emu.sh

However, a lot of people are going to be ditching chrome, including me, in the coming months as google enforces Manifest V3, and firefox does not actually support a similar standard from what I can tell. From what I can tell, there is no open standard for rich search suggestions.

here's an example:

I suggest opensearch suggestion specification includes not just text but also metadata-- suggestion text, suggestion URL, suggestion subtitle, suggestion description, and suggestion thumbnail

The problem

For most use-cases, absolute paths are fine as a website is mostly only hosted on one domain.

However, when it comes to software that is made to be deployed to many different domains, it requires the opensearch file to be edited for each instance of the deployed software (see piped and libreddit having issues with this.

Tried solutions

Even when editing the opensearch file, it can cause issues if that one server can be accessed from multiple domains, for example if it has an onion site on tor.

Another workaround that could actually work would be to edit the file and insert the domain using the Host http header, but that adds a level of complexity that shouldn't be necessary.

Ideal solution

What I request is that the opensearch standard allow for relative paths to be used for search engines, allowing for the browser to use the current host in the url.

Is necessary to use PascalCase tags? or I can use full lowercase?

<ShortName>Web Search</ShortName>

<shortname>Web Search<shortname>

https://github.com/pi-apps/pi-platform-docs/blob/master/SDK_reference.md

The OpenSearch relevance extension seems no longer accessible. Search engines refer to the current Github repository where it is not present either ... Can it be made visible again ?

As part one of updating the OpenSearch spec to be HTTPS-only (or at least, HTTPS-strongly-preferred), update all of the example URLs to be https instead of http.

I request a online open source validator for website opensearch xml in js

Many websites do not implement their own search function, however it is possible to let an external url template power opensearch.

You could let the url template use a search engine of choice like this:
https://aaronparecki.com/2011/07/11/3/how-to-let-google-power-opensearch-on-your-website

However, the search engine that the web authors specifies may not be that of the users preference. If sites can opt-in to allow an opensearch description to use the users current browser to power the search function it could serve as an easy integration for opensearch for all web authors.

[ wearing my IANA link relation registry expert hat]

Hello,

The IANA link relation registry has an entry for search that references http://www.opensearch.org/Specifications/OpenSearch/1.1.

Following that link currently results in a 404, and that Web site now appears to be used for an unrelated search project.

I've contacted the Amazon OpenSearch folks, who pointed me to this repo as authoritative for the link relation.

Could you please confirm this, and provide an updated link for the purposes of the registration?

Thank you,

(tracking in protocol-registries/link-relations#48)

The url http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.1 that's being referenced in this document is being redirected back to this page.

Hi DeWitt and other contributors!

I'm not sure what the process for extending this standard is, so I thought I'd start by opening a bug for discussion.

I'd like to propose adding a new field:

• Name: "manageUrl"
• Type: URL or null
• Meaning: A URL that the user could visit to view, manage, and delete search history or any other data collected by the search engine; null is a declaration by the search engine that they don't collect any such data.

A user agent could then expose this URL in their search engine settings or data deletion surfaces to help users manage their data.

I think an explicit "null" value would be useful to distinguish search engines that simply haven't provided a URL yet, or haven't implemented an UI for users to manage their data, from those search engines that want to affirmatively declare that they don't collect data about users' searches. Though I'm not quite sure yet if it would really be actionable for user agents, as there could be a lot of nuance (e.g. a search engine is collecting data but aggregating and anonymizing it; a search engine is collecting data in a pseudonymous non-authenticated way, so it can't really verify the identity of the user who wishes to view their data). Ultimately, user agents would likely not want to make statements about the privacy practices of third parties.

Thanks!
Martin

The opensearch.org domain will eventually stop serving, so certain high-value documents should be converted to Markdown and served out of the git repository.

The Suggestions specification is currently hosted here:

http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions

And mirrored locally here:

https://github.com/dewitt/opensearch/blob/master/mediawiki/Specifications/OpenSearch/Extensions/Suggestions/1.1/Draft%201.wiki

This issue can be closed when the draft spec is converted to Markdown and checked into the repository.

Dear all,
I have a group of metabolites analyzed by LC-MS and its form is like:
pHILIC_154.1225_1.6
nHILIC_241.087_1.1
pRPLC_261.1446_0.8
nRPLC_495.2962_9.1

I know that HILIC indicates to hydrophilic interaction while RPLC indicates to reverse phase liquid chromatography and n and p indicates negative and positive ionization modes.
my question is what is meant by numbers after these symbols like 154.1225_1.6
Is it molecular weight or anything else?
Hope anyone helps me