Bug 47730 – Web Inspector: grant access to local storage to web inspector

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Web Inspector (Deprecated)

[Pavel Podivilov]

In chrome, Web Inspector uses "chrome:" schema which has very limited permissions. However, we want to use localStorage to store front-end settings.

[Pavel Podivilov]

Created attachment 70884 [details]
Patch.

[Adam Barth]

Comment on attachment 70884 [details]
Patch.

These "grant" API are like grenades without a pin.  We shouldn't have them at all.  A better design might be to run the inspector in the "chrome-extension" scheme.  That way it can have its own public key to define who should have access to its local storage.

[Early Warning System Bot]

Attachment 70884 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4419052

[Eric Seidel (no email)]

Attachment 70884 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4470040

[Pavel Feldman]

Comment on attachment 70884 [details]
Patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=70884&action=review

> WebCore/page/SecurityOrigin.h:124
>      bool canAccessDatabase() const { return !isUnique(); }

At some point we might want to use database and filesystem from within inspector. So the right solution is to make inspector non-Unique on all the platforms.

[Adam Barth]

(In reply to comment #5)
> (From update of attachment 70884 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=70884&action=review
> 
> > WebCore/page/SecurityOrigin.h:124
> >      bool canAccessDatabase() const { return !isUnique(); }
> 
> At some point we might want to use database and filesystem from within inspector. So the right solution is to make inspector non-Unique on all the platforms.

Indeed.  However, we shouldn't do that by granting it magical privileges.  Instead, we should use a URL scheme that doesn't impose uniqueness.

[Pavel Feldman]

> Indeed.  However, we shouldn't do that by granting it magical privileges.  Instead, we should use a URL scheme that doesn't impose uniqueness.

+1. That's exactly what I meant in the "non-Unique" part of the comment.