1 Topic by Quohni

(1 replies, posted in Misc)

Hello,

this idea is not specific to FireGPG, maybe other developers still do that (but I don't know of that).

I know that FireGPG is beta software yet but on the other hand the users are probably not all at the same "beta interest level". So my suggestion is this (if that is possible at all with the Firefox update mechanism): Don't let anybody download every new version immediately. Allow the users to select whether the always want the newest versions or not. Those who don't could get the new versions perhaps one week after the first testers have received it. That would allow you to fix serious bugs (like the one reported by me, haha) before the whole lot ot users is affected by them. Of course, the "second grade beta testers" would not get the same version, just later, but a fixed one (if necessary). You don't need many testers to find bugs by which most users are affected. So my combination gives you all you need as a developer. A few days later, of course, but in case of urgent problems that can be an advantage though. And above all, the "beta experience" is better. The "first grade" beta testers can feel liek being some elite, the others encounter less bugs. Everyone is happy.

Go to forum: Misc

2 Reply by Quohni

(4 replies, posted in Bugs & problems)

OK... I have an organizational suggestion for this forum: I don't know dokuwiki thus I have not looked at that thread. It might make sense (at least in some cases) if you extend a misleading subject by some clarification, e.g:

Problem with dokuwiki and FireGPG

->

Problem with dokuwiki and FireGPG (admin added: no more web page integration with 0.7.2)

This would probably avoid some double reports.


Hauke

Go to forum: Bugs & problems

3 Topic by Quohni

(4 replies, posted in Bugs & problems)

Hello,

I happened to install FireGPG 0.7.2 as the first add-on for a new user and updated to this version for another user on the same system (FF 3.0.5, openSUSE 11.0). Since this update there is no on-web page handling of PGP data any more. I can still mark and verify or decrypt but only by the editor window. Web pages are displayed as if FireGPG was not installed.

How can it be that I am the only one experiencing that...?


Hauke

Go to forum: Bugs & problems

4 Reply by Quohni

(7 replies, posted in Requests)

Your "Yahoo can't handle then what is supposed to handle" argument is valid for webmail (and theoretically proxy servers) only, not for normal web pages because there is nobody between you and the original data who could check it for you.

This leads to the idea to lock your webmail domain for this feature. A further protection would be to only parse such code as HTML which is not only encrypted but signed, too. And the user may decide: "decrypt as plain text" vs. "decrypt as HTML".

In general I would say that you try to care about a problem that is not yours. Checking encrypted contents (just think of SSL protected web pages and filtering proxies) has to be solved at the application level. That cannot be an argument against using encryption. And if HTML cannot be encrypted its an argument against encryption if you need HTML.

Go to forum: Requests

5 Reply by Quohni

(7 replies, posted in Requests)

That wouldn't make any difference to sending the same code unencrypted. A signature even less encryption does not say anything about the quality of the content.

The only possible problem is that the encryption hides malicious code from browser features so that they would not be dangerous if unencrypted. But that would mean that these protection features could easily be circumvented by Javascript (in unencrypted documents) thus this is not a valid argument.

If you want to play it safe you can easily erase all critical tags (<script>) and attributes (href to a different domain, onmouseover and so on).

Go to forum: Requests

6 Topic by Quohni

(7 replies, posted in Requests)

Hello,

I think it's a pity that FireGPG allows to encrypt data only but not HTML tags. It's not very convenient to encrypt all data fields one by one let alone the display problems.

I think often it would make more sense to encrypt parts of the document that include tags. an example:

<div class="firegpgcontainer">
<p>This is my <strong>formatted</strong> text with my <a href="youneverknow.tld">secret link</a>.</p>
</div>

could be transformed into

<div class="firegpgcontainer">
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.9 (GNU/Linux)

hQIOA0NeQ3HmI++IEAf/RwUzty28vpcQmkfpKgzRkd/pxkwTiW0DyFDoXd0Ju420
IXpRzzo6WW7GiBFLc0+eCcIr8bZ/hLcTCtpga7/JiBP8jEkC8VDC78+rAU44lca5
PICYIZ6M2jZoblDwt8pDPxvDsmo4dURGtWAYRnoDS69zBo4GPWZ4QfT/0uEA+oSG
QoemictFa1sYbRwlP5IrTdsCLfy9NfSZg+vT0/I1Pc/AHGSWGgQXDl5c+504yweZ
8yCybE6NqakXLsX0R8ATsiS23bW66VPpsGrI+NRbwjIKg2+/rPiCU5gcbZchPTBB
EywNx/lh4CvDxURBBKSOJLYhefJ8ZCwfljP8s+jNPwf+Is56aQPW1cwuaPxM+2Ys
buPr3KL3yGOI/QbT+UZYcbX5wjLrlAZJ9lH3InLBo9jBZAFF9arO4SoYm3fLaAFs
53oie3eqI6rozXwC+X952YH37BGGXfphnGE5On7BkI7ODCSXKLQRoN8LU4wjeaLZ
fOS3+xLr6rLKkrfTjp07+pSJ7FbNw7pynq6oAOUrqRuTeFGNUX6M8XHUxudyhs5O
HXsU3xHnVKgwPSfPozp9aCphKlfpbtWphL5lrxp++hQiT5slN61z9WtsnUQBSUQ3
4Iwr2dR4HJwwzOIwszBDRmAp4uZD3h2wkr5lBD9rTKu3Fa1zwCG3b7RVpMeYRfTe
mNKWAWDc9kVmRn4tJCV8KbtWyp9IhqQX/sLriNke6gmQLa7fAEN+gsC/i1Ic16eJ
r0CrOxpZp54Tk4XlY1LIje6rrfdJjqNsC5i82W0dxwxLu4eTpIYsPI6TGjMYDew7
qlWL4QHCF7H807eiv5bnNpaITe3smOZarlQJxKke8omorIWK+ThqdbY9p7cZ7Jp6
FtSEH6se/KSe
=A7QW
-----END PGP MESSAGE-----
</div>

That would be correct from an HTML parser's point of view (plain text without illegal characters within <div>). After decryption the result could be added to the Document by adding DOM nodes and their content. This could be restricted to valid code. So it might be necessary to install one of the existing offline validation add-ons. Thus it might make sense to restrict the encrypted DUM subtree to XHTML. Perhaps it is possible to create a new "document" without opening a window in Firefox. Then you could create a temporary document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>

<div class="firegpgcontainer">
<!-- insert decrypted data here -->
</div>

</body>
</html>

have that one checked by a validator add-on and in case of success simply read and copy the DOM nodes and contents from the temporary document into the real one. But that's just an implementation idea by someone who doesn't know anything about this kind of programming. :-)

Go to forum: Requests