Hello All,
Unsigned Tor Browser 13.0.13 (desktop-only) release candidate builds are
now available for testing:
-
https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.13-build1/
The full changelog can be found here:
-
Hello All,
Unsigned Tor Browser 13.0.6 (desktop-only) release candidate builds are
now available for testing:
-
https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.6-build1/
The full changelog can be found here:
-
Hello All,
Unsigned Tor Browser 13.0.4 release candidate builds are now available
for testing:
-
https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.4/
The full changelog can be found here:
-
Hello All,
Unsigned Tor Browser 12.5.3 release candidate builds are now available
for testing:
- https://tb-build-05.torproject.org/~ma1/builds/release/unsigned/12.5.3/
The full changelog can be found here:
-
Hi intrigeri,
On 24/05/2016 16:56, intrigeri wrote:
>
> FWIW, the request headers always include:
>
> Pragma: no-cache
> Cache-Control: no-cache
Good catch!
https://labs.riseup.net/code/issues/11304#change-58146
Sorry for not having noticed it earlier :(
--
Giorgio Maone
ht
On 25/04/2016 18:18, intrigeri wrote:
>> Right. The server now sets both Cache-Control and Expires headers to
>> "last access time + 2 hours", for IDFs.
>> How can I verify, from the client side, that DAVE honors these?
>> Using some Firefox developer tool, perhaps?
>
Yep, ctrl+k, "Net" tab.
-- G
uce the network traffic, by
giving the revalidating server another way to tell whether the IDF is
stale other than If-Not-Modified-Since, i.e. If-None-Match, but won't
reduce the validation hits: that's a job for Cache-Control and Expire.
Disclaimer: I'm not a caching guru, but this resource may he
F. This is
basically the only way to fix https://labs.riseup.net/code/issues/10685,
as noted in https://labs.riseup.net/code/issues/10685#note-5
Of course you can and should limit the actual network activity by
properly using Chache-Control and/or ETag headers.
The sa
> To end with, can you please give a quick look at our existing JS code,
> and tell us if anything can't possibly work in a Firefox add-on such
> as DAVE, or really, if anything raises a red light:
>
> https://git-tails.immerda.ch/mirror-pool-dispatcher/
>
&
On 30/11/2015 20:32, sajolida wrote:
> Giorgio Maone:
>> thank you for your time filing those tickets :)
>>
>> Unfortunately I can't look at them closely until Monday because I'm
>> traveling, so please forgive me if the answers to my questions below
>> c
s ready in backports and PPA. So we can
> do the beta with the final instructions for them.
> - A version of the extension uploaded to addons.mozilla.org so we can
> point to it instead of maone.net.
>
> Does that seems feasible to you?
> ________
On 19/11/2015 13:17, sajolida wrote:
>>> 2. #bittorrent-minor should also be visible when #use-button
>>>and #install-button are visible. See slides 3 and 4.
>> OK, done in latest commit.
> I don't see this. I tested with 0.2.5 and it didn't work. I also don't
> see any change while search on
0.2.6": {
URL: "dave.xpi",
Hash:
"sha256:c750017b572ebc6417324196f216a13216e5f65de6abd8b1a5a1ce07618ccfdc"
}
);
--
Giorgio Maone
https://maone.net
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.o
On 18/11/2015 19:54, sajolida wrote:
>
> I read this too fast. Actually, we don't want the extension to open the
> file browser of the OS right now. After clicking on the "Next" button,
> people will go through step-by-step instructions and we'll tell them
> when to use the ISO image.
So, when you
On 17/11/2015 17:11, sajolida wrote:
> Giorgio Maone:
> Now you've got the flexibility of choosing to pin the domain cert, the
> issuer's (CA's) cert or both.
> I've seen that in conf.json. Regarding the different kinds of pinning,
> how do you switch from trusting the cert to trus
Status update as of latest commit (extension version 0.2.1) follows.
On 12/11/2015 17:38, sajolida wrote:
> 2. The extension is great because it preserves its state even if you
> close the tab. You can open it again and the result of the verification
> is still there. Still, I think we should
On 12/11/2015 17:38, sajolida wrote:
> We also published an alpha version of that page on the website, for
> testing purposes as well here:
>
> https://tails.boum.org/install/download/
>
> But since the time we synced with Giorgio's code we did some changes, of
> course :) They are visible
On 31/08/2015 20:55, sajolida wrote:
> Giorgio Maone:
>
>> The main roadblock was Mozilla finalizing its add-ons migration strategy
>> to the Electrolysis (e10s) multi-process & sandboxing architecture.
>> Without an ultimate public decision, which has been deemed &q
On 28/08/2015 17:37, sajolida wrote:
In terms of extension code, Maone told us he would be busy with other
extension work over the summer but maybe he's back on track now. Giorgio
what's up? Do you have any ETA for a first prototype? Anything blocking you?
The main roadblock was Mozilla
on the windows
stack) to ensure nothing else can tamper with user's perception.
-- G
On 08/07/2015 02:16, intrigeri wrote:
Hi,
Giorgio Maone wrote (07 Jul 2015 23:24:07 GMT) :
So, just to be clear, *web pages cannot interfere in any way* with the
result of the verification performed
Look at the subject :)
--
Giorgio Maone
https://maone.net
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
instead of install.
Same as B above.
Of course all of this is particularly relevant for those who have
automatic add-ons updates disabled, such as Tor Browser users AFAIK.
Regular Firefox users would usually receive the most recent version of
the extension silently and timely through AMO.
--
Giorgio
On 07/05/2015 18:12, sajolida wrote:
Hi Giorgio,
A few days ago we finished a wireframe of the extension that we believe
is a good start for you to work on. It might still change slightly as we
continue discussing small details of it.
See
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/07/2014 23:35, sajol...@pimienta.org wrote:
Still, I'd suggest not losing focus with that discussion now, and moving on
to the initial
implementation to verify SHA-256 and reconsider all that later on :)
I agree and I'm almost done with
of a MITM while grabbing the hash.
However I agree, this is for a future version and shouldn't prevent us
from shipping basic download+verification.
-- G
best,
Griffin
On July 8, 2014 6:19:07 PM EDT, sajol...@pimienta.org wrote:
Giorgio Maone wrote:
Hi everybody. The blueprint
...@boum.org
mailto:tails-dev-unsubscr...@boum.org.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
--
--
Giorgio Maone
On 06/07/2014 17:01, sajolida wrote:
Ah, and tell us in case you subscribed to the mailing
list, and we will stop putting you in copy.
Just done.
Also, I found Griffin's message in this thread from the public archive:
I can confirm that an option to select an arbitrary file from the
filesystem
tails developer's key and
perform OpenPGP authentication itself.
- -- G
On 06/07/2014 17:01, sajolida wrote:
Together with Giorgio Maone from NoScript and tchou we designed a crazy
new plan to solve a great deal of ISO verification for the masses.
Here it is:
https://tails.boum.org/blueprint
28 matches
Mail list logo
