I think there's a misunderstanding here about how this API uses an on-device AI model. This API takes a piece of input text and a set of rewriting options (e.g. "rewrite this in a more/less formal style"), passes them to a generic AI model which has been trained for the task of rewriting text, and returns the result to the calling site. There are no other inputs to the model. The model does not have access to any other data on your system. We aren't giving sites the ability to chat up your secretary and try to get them to spill your secrets. This is an algorithm with well-defined inputs and outputs. Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome <https://www.google.com/chrome>
On Wed, Sep 11, 2024 at 9:56 PM Domenic Denicola <dome...@chromium.org> wrote: > > > On Thu, Sep 12, 2024 at 1:44 PM Tom Jones <thomasclinganjo...@gmail.com> > wrote: > >> I guess you guys miss the point. I ABSOLUTELY demand the right to block >> any website from running anything they choose through my local AI to what I >> would see if they asked me that question. So the first thing any website >> would do is first figure out what my local AI would say about a query until >> they found one that would give access to my stuff. This is nuts. Please >> stop it now. >> > > Sorry, I still don't understand what you're talking about. Can you give > some sample code using the proposed API that would do something bad, like > "give access to my stuff"? > > >> >> Peace ..tom jones >> >> >> On Thu, Aug 22, 2024 at 5:05 PM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> >>> >>> On Fri, Aug 23, 2024 at 2:45 AM Tom Jones <thomasclinganjo...@gmail.com> >>> wrote: >>> >>>> It seems to me that the security and privacy risks in this proposal are >>>> gigantic. Cross site scripting attacks have been difficult to block and >>>> now the suggestion is to allow some AI, which may change from day to day to >>>> insert attacks. >>>> >>> >>> Can you point to the part of the proposal where an AI inserts attacks? >>> There's no API here for inserting content into the DOM at all, so I can't >>> understand what you're thinking of... >>> >>> >>>> Peace ..tom jones >>>> >>>> >>>> On Wed, Aug 21, 2024 at 11:28 PM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> Contact emailsdome...@chromium.org, fer...@chromium.org, >>>>> kenjibah...@chromium.org, h...@chromium.org >>>>> >>>>> Explainer >>>>> https://github.com/explainers-by-googlers/writing-assistance-apis/blob/main/README.md >>>>> >>>>> SpecificationNone yet, but looking forward to writing one >>>>> >>>>> Summary >>>>> >>>>> A JavaScript API for transforming and rephrasing input text in the >>>>> requested ways, backed by an AI language model. >>>>> >>>>> Blink componentBlink>AI>Rewrite >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAI%3ERewrite> >>>>> >>>>> Motivation >>>>> >>>>> Browsers and operating systems are increasingly expected to gain >>>>> access to a language model. By exposing this built-in model, we avoid >>>>> every >>>>> website needing to download their own multi-gigabyte language model, or >>>>> send input text to third-party APIs. The rewriter API in particular >>>>> exposes >>>>> a high-level API for interfacing with a language model in order to >>>>> transform inputs for a variety of use cases [1], in a way that does not >>>>> depend on the specific language model in question. [1]: >>>>> https://github.com/explainers-by-googlers/writing-assistance-apis/blob/main/README.md#rewriter-api >>>>> >>>>> Initial public proposalhttps://github.com/WICG/proposals/issues/163 >>>>> >>>>> TAG reviewNone yet; waiting to move to WICG first >>>>> >>>>> TAG review statusPending >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> This feature has definite interoperability and compatibility risks, >>>>> due to the likelihood that different implementations will use different >>>>> language models, prompts, and fine-tunings, and even within a single >>>>> implementation such as Chrome, these pieces will likely change over time. >>>>> Additionally, not all browsers and operating systems will have a built-in >>>>> language model to expose, and not all devices will be able to run one. We >>>>> are taking a variety of steps to attempt to mitigate these risks. For >>>>> example, the specification is designed to allow the API to be backed by a >>>>> cloud-based language model, which could help extend it to more users. And >>>>> the high-level nature of the API, which hides the details of the specific >>>>> language model, prompts, etc., makes it harder for developers to depend on >>>>> specific outputs: they are just getting a rewrite, and not e.g. structured >>>>> data. Finally, the API surface is designed with many clear points of >>>>> failure, that encourage the developer to probe for capabilities ahead of >>>>> time and fall back to other techniques if a capability is not available. >>>>> Nevertheless, interoperability and compatibility risk remains high for >>>>> these sorts of APIs, and we'll be closely monitoring it during the >>>>> prototyping period. >>>>> >>>>> *Gecko*: No signal; waiting to move to WICG before asking >>>>> >>>>> *WebKit*: No signal; waiting to move to WICG before asking >>>>> >>>>> *Web developers*: No signals/weak mixed signals. We have many private >>>>> expressions of interest in the use case, but initial public reaction to >>>>> the >>>>> specific API in https://github.com/WICG/proposals/issues/163 has been >>>>> mixed. >>>>> >>>>> *Other signals*: >>>>> >>>>> Activation >>>>> >>>>> This feature would definitely benefit from having polyfills, backed by >>>>> any of: cloud services, lazily-loaded on-device models using WebGPU, or >>>>> the >>>>> web developer's own server. We anticipate seeing an ecosystem of such >>>>> polyfills grow as more developers experiment with this API. >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> None >>>>> >>>>> Debuggability >>>>> >>>>> It is possible that giving DevTools more insight into the >>>>> nondeterministic states of the model, e.g. random seeds, could help with >>>>> debugging. See related discussion at >>>>> https://github.com/explainers-by-googlers/prompt-api/issues/9. >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?No >>>>> >>>>> We hope to work on web platform tests for this feature, but how much >>>>> we can guarantee as testable beyond the surface API is unclear, given the >>>>> nondeterministic nature of the output. >>>>> >>>>> DevTrial instructions >>>>> https://docs.google.com/document/d/1wIoSQx29-WBlEDO297iF9a43DXUcbjxJqctdGxcXY6I/edit?usp=sharing >>>>> >>>>> Flag name on chrome://flagsrewriter-api-for-gemini-nano >>>>> >>>>> Finch feature nameEnableAIRewriterAPI >>>>> >>>>> Requires code in //chrome?True >>>>> >>>>> Tracking bughttps://issues.chromium.org/issues/358214322 >>>>> >>>>> Estimated milestones >>>>> DevTrial on desktop 129 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5112320150470656?gate=5156545160282112 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-1W7%3Dt-em4tpr71xdYLia-LQM5E0VWbARSZmUC2xvQuA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-1W7%3Dt-em4tpr71xdYLia-LQM5E0VWbARSZmUC2xvQuA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9Jhe7o59mX5tJPD%3DcZQb2oL3mNi-T57wA86fPXn55OPw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9Jhe7o59mX5tJPD%3DcZQb2oL3mNi-T57wA86fPXn55OPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9V1K3%2BJfBYNr9BB1wO3pmPD889D0Lyn9VfRrgkTRY6tA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9V1K3%2BJfBYNr9BB1wO3pmPD889D0Lyn9VfRrgkTRY6tA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMa0w3wAHpH_ExqyorkTZuBpegao%3DoGqcBh70oJSsVT4zw%40mail.gmail.com.
