Manual password entry required

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install NotScripts
2. NotScripts will nag about not having a password, as well as about having a 
password that is too short.

What is the expected output? What do you see instead?

I expect a password mask, where I can put in a password of any length I want 
(pad the password to get it to the required length if you must).

What I get instead is a page with instructions on how to set up a password in 
some God-forsaken corner of my computer's file system.

Adding insult to injury, this site is white text on black background (which'll 
be fun for those of us who set the OS default to high-contrast, because they 
are visually impaired).



What version of the product are you using? On what operating system?

Current version of NotScripts (apparently 0.9.6), on Chrome 6 for Win7 32bit

Original issue reported on code.google.com by cmdjackr...@gmail.com on 8 Sep 2010 at 1:33

[GoogleCodeExporter]

If the password needs to be set only once and never needs to change, why can't 
a random string of characters used for the password? This password could be 
created when the extension is first enabled and it would then be stored with 
the rest of the extension's settings. Since settings get saved across extension 
updates, I think this would fix the problem of the password file getting reset 
on an update too.

Original comment by kevman3000 on 9 Sep 2010 at 4:26

[GoogleCodeExporter]

Manual password entry is currently required because of the asynchronous nature 
of the Google Chrome extensions API and the requirement that we must have 
access to the encryption password right when a page loads. The portion of 
NotScripts that uses the encryption password is the content script and for a 
normal extension, it would use a chrome.extension.sendRequest(...) to retrieve 
the password and updated settings from the portion of the extension where it 
resides since content scripts are sandboxed from everything else. 

chrome.extension.sendRequest(...) is does not return the needed values until 
some portion of the scripts on a webpage have already run. The password file is 
loaded by the content script before it runs it's code because we state to do 
that always in the extension manifest. However, a Google Chrome extension does 
not have permission to write to disk directly and cannot self edit it's 
extension files. 

Apple Safari has a canLoad(...) function that returns immediately and is well 
suited to solve this problem. I'm hoping that Google allows canLoad(...) to 
slip into Webkit so I can simplify NotScripts. Until the, we will have to wait 
and see.

Original comment by optimalcycling@gmail.com on 9 Sep 2010 at 7:14

[GoogleCodeExporter]

Original comment by optimalcycling@gmail.com on 9 Sep 2010 at 7:14

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Please help resolve the password requirement issue by starring this Chromium 
bug report: 

http://code.google.com/p/chromium/issues/detail?id=54257

Original comment by optimalcycling@gmail.com on 27 Sep 2010 at 4:08

[GoogleCodeExporter]

The path on Linux is incorrect for my machine (ubuntu). I had to uninstall the 
plugin to post this comment.

Original comment by jSlim...@gmail.com on 2 Mar 2011 at 8:09

[GoogleCodeExporter]

It seems that I found a solution to this issue. By using programmatic 
injection, I was able to provide the ENCRYPTION_KEY to the content scripts 
without declaring it in a file. Take a look at the attached diff.

It's not 100% perfect at the moment, since blockAfter.js is broken (and I 
didn't want to spend even more time unbreaking it). But as a proof of concept, 
it seems to be working nicely.

Original comment by mathr...@gmail.com on 20 Apr 2012 at 2:26

Attachments:

• nopasswd.patch

[GoogleCodeExporter]

Just to clarify, the brokenness is related only to the fact that (at least for 
me right now), the content scripts declared as document_start seem to be run 
before the programmatic injection. So blockAfter.js is run before 
blockStart.js. But that's it, the whole thing still seems to run before the DOM 
is fully constructed, and before on-page scripts run.

Original comment by mathr...@gmail.com on 20 Apr 2012 at 2:29

[GoogleCodeExporter]

I have looked through the NotScript source files and determined it would be 
easy for the author to allow for setting the password in the extension's 
LocalStorage.  It appears the author may not have known how to have content 
scripts communicate with the extension backend to make this possible, but then 
at some later point the author did figure out how to do this but never 
incorporated it into the password mechanism.

But a more fundamental flaw is that the password should not be required at all, 
as the reason it is required is to allow it to expose extension data to 
websites without the websites being able to read it (but they can easily delete 
it, on purpose or by accident).  I will post a separate issue about my findings.

Original comment by megazzt on 11 Jul 2012 at 2:45

[GoogleCodeExporter]

The instructions do not include password configuration for Chromebook 
instllations of chrome, where OS access is quite likely limited for most users.

I like the cut of megazzt's jib; LocalStorage seems the way to go.

In the meantime, this extension appears unusable for the majority of Chromebook 
users.

Original comment by t...@packetfu.com on 28 Oct 2013 at 12:24

[GoogleCodeExporter]

I have Notscripts loaded on all my Chrome browsers, but I was very sad that it 
cannot run on my Chromebook.  I feel like I'm naked when I go to websites with 
all their scripts running...

Original comment by john.ove...@gmail.com on 5 Sep 2014 at 7:51