twr

- A valid zip does not begin with, as you would normally expect, a magic number.

- A valid zip can contain arbitrary prepended data.

- A valid zip can contain sections with no identifier value.

- A valid zip can contain arbitrary data between sections.

- A valid zip is validated starting with a tail section located at the end.

- A valid zip can have a valid tail section that contains a valid tail section.

- A valid zip can contain arbitrary appended data.

I don't get it: Why design a format that's so hard to parse? Implementing a single-pass streaming parser is impossible. It should be a basic requirement for most file formats. /usr/bin/unzip cannot even extract from standard input. I'm sure the implementer didn't feel like receiving user complaints about exhausted memory.

Current firmware downloads contain the uboot source code.

Based on the email quotes, Ubiquiti did violate the GPL. It hasn't been proven that they are actively doing so.

Do you have reverse engineering experience on Android?

APK uses the zip format. Extract its contents and compare those, minus the META-INF directory, which contains digests and a detached PKCS#7 signature.

Apps whose code output isn't reproducible can still be compared with a varying amount of IDA analysis.

This isn't just unique to Android: there are multiple ongoing efforts at the moment in the Linux world to lessen frustrations with distribution repositories. Snappy, Flatpak, and AppImage intend to unify application deployment and allow users to install applications from anywhere. In most cases, this could mean pulling directly from the application developer themselves. GNOME and KDE will likely encourage this.

I know some Firefox developers who have grouched at the delay between official releases and when distributions finally deploy them, so this problem isn't exclusive to desktop environment developers.

Back to Android: Moxie had a point when he claimed that Android is more privileged to have a system that provides package verification back to the original developer. It doesn't matter where you get an APK from: the developer's website, Google Play, APKMirror, or Bittorrent. If you have the developer's public signing key, you can verify the authenticity of the APK.

F-Droid represented a serious step backwards in Android security, back when they used to self-sign APKs. It wasn't possible any longer to cut out the distributor from the chain of trust. Fortunately, they reacted to Moxie's criticisms, and F-Droid now retains the original package signature when the build can be reproduced.

From a developer perspective however, encouraging or even tolerating unofficial installation channels for secure communication software is bad. If vulnerable users are in-contact with non-vulnerable users, they unknowingly put both parties at risk. If the ecosystem evolves to the point where this is common, the whole system is insecure.

What Android desperately needs is a high-quality, non-profit, privacy-friendly, charity- and grant-driven app store. It must entice open-source app developers. It cannot do self-builds, except for reproducibility. It needs crash-reporting, analytics, usage metrics, device-specific builds, localization options, and more. It requires dead-simple tools for command-line deploying.

Until then, in my opinion, F-Droid will never be accepted by app developers. F-Droid is for users only. Not for the same purposes, either: for the cautious user, F-Droid mainly shines as a locally-setup repo for self-deployed apps.

P.S.: Perrin & Moxie recently began documenting Signal Protocol: https://whispersystems.org/docs/

Encryption done in untrusted JavaScript is security theater. If these websites offered privacy policies claiming to never read your data, like Riseup does, the end-result would be the same. Safer, actually, because deploying unnecessary crypto increases the vulnerability risks.

Recommending these websites is actively dangerous. Journalists and whistleblowers who take these claims of fraudulent security seriously, are going to be killed. Getting them to understand that email cannot be secured in-browser, is the entire point. That if you have important information to protect, you should be moving onto different approaches.

WhatsApp is literally safer than this, and it's more accessible.

[1] https://www.schneier.com/blog/archives/2012/08/cryptocat.htm...

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

[3] https://rdist.root.org/2010/11/29/final-post-on-javascript-c...

Nearby here, recently, a woman was ambushed and taken off into the woods, and has since vanished.

Supposing hypothetically that her hypothetical tracking beacon was emitting several hundred meters off into the unexplored woods, maybe someone would have noticed. Hypothetically. Sorry.

It's uncommon for bicyclers to go off course. Bikes don't navigate well through trees. And no one wants to leave their valuable possession behind.

And I was being terse before. Normally there would be some attempted contact beforehand.

> How would the police help after a confrontation already has taken place? How fast is the police, really?

In a kidnapping or injury scenario, time is of importance. Alerting the authorities (or anyone nearby, really) can save a life. If first responders wait additional hours because they were alerted too late, that person may die.

People who travel tell people when they expect to return. If they leave on a three-hour trip, and experience catastrophe thirty minutes in, it may be 2.5 to 5+ hours before someone makes an emergency call.

> All right, in this case it would actually help. But this does not mean that she should have this capability turned on all the time, 24/7; only while she is doing a physically dangerous activity. Like going hiking – it’s normal to leave word of your planned route, in case of emergency. But not all the time.

Sure. I never suggested around-the-clock monitoring.

She -- and her bicycling friends -- have been carrying tracking equipment for years. They plot their courses and compete on sprint times.

So they are totally used to surveillance. It took me by surprise that so many HNers found the concept anathema.

> Your “nerds” comment is insulting and demeaning.

I guess. It was mostly tongue-in-cheek. I'm one of them.

Sorry for the poor language. It was unwarranted.

Can you explain how this is better than Google End-to-End? (Which isn't completed, I know.)

Or even how it's worth implementing over regular webmail in the first place?

Extensions are obviously not optimal, for the very same reason crypto in JavaScript is not good: timing attacks, cache attacks, optimizations, secure storage (in-memory and on-disk), random-number generation, verifiability, ....

Protonmail suffers from that too. Except it's also subject to key exfiltration. Without an exploit. The server simply promises not to send malicious JavaScript.

It isn't significantly more involved for an attacker who has breached their servers to send malevolent code. It's also not easy to detect.

> We will never have a useable experience for all user if we do not accept compromises.

There are usable end-user interfaces capable of featuring secure cryptography.

Desktop applications. Mobile apps. Browser extensions. Hardware tokens (U2F).

Those can be audited. Inspected. Users can freeze updates.

Trying to implement secure cryptography in JavaScript that is fetched repeatedly from an assailable server is just asking for trouble.

> GPG is already not perfect and we should move away from it anyway

Yes, but that doesn't mean ignoring the advancements that have been made in modern security.

The most appropriate response to securing email is still this: Don't, use a secure messenger; or use out-of-band encryption. It's likely to remain that way forever.

She's dragged off the trail. Her husband notices and notifies the police.

She halts during a physical confrontation. Her friend calls to check up on her, and calls the police when she can't be reached.

She crashes and becomes incapacitated. Someone checks her location after she fails to meet up.

In reality, sports enthusiasts already use expensive tools for this. But the point of my comment wasn't about my affluent friend. It was about similar disadvantaged people facing actual dangers.

Nerds complaining about privacy, while the only threat they face is increased cholesterol levels, just seems so trite.

Awareness is good. Zealotry isn't.

Maybe that's occasionally deserved.

I'm probably more paranoid about surveillance than you are. I wrote positively about this app anyway.

The average commenter here is, more than likely, like me, not really in the target demographic for this app. I'm male, reasonably strong, and capable of defending myself. I don't worry when I leave the house.

Sometimes my female friend, who is passionate about bicycling, tells me about her experiences on the nearby bike trail. Where, every day, she passes by dozens of loitering homeless individuals. Where, some time ago, a woman was dragged off her bike and had her face shattered. Where multiple women have been kidnapped. She expresses fear, but loves her sport enough to overcome it.

She rides on a multi-thousand dollar custom-made road bike that's surely appealing for someone desperate enough.

Who am I to tell her that her fears are overwrought? My physical safety isn't at stake.

For people like her, I think this app is worth consideration. For people like me, I never wanted it.

Anyone who has ever expected an at-risk person to make contact at an estimated time can relate how worrying it is when that person is delayed.

A young woman was abducted recently on a local trail. I don't believe she's been found yet. Perhaps this would have made some difference.

So normally only the build servers contact Intel. Source-based distributions may. But even then the source files are verified with cryptographic hashes (which are in turn signed by the maintainers' private keys).

Edit: I may have misread your question. I thought you were asking by implication if the microcode blob is pulled after the install. If not, then: No. Updates happen when the package manager decides.

https://www.kernel.org/doc/Documentation/x86/early-microcode...

https://gitlab.com/iucode-tool/iucode-tool

https://downloadcenter.intel.com/download/26400/Linux-Proces...

It's also quite unlikely that they can circumvent a basic `tar -c /dev/block/* | gpg -se ...` scheme that's trivially doable on unlockable Android phones. (Replacing the bootloader with a maliciously crafted variant that returns false partition data after bootup would work, but once again: CBSA.)

You're probably safe if you just do an iCloud backup and wipe followed later by a restore.

Certainly do replace the SIM card as soon as possible though, IMO. Unless you can verify it somehow.

  flashrom -p internal -r bios.rom
  ifdtool -x bios.rom
  python3 me_cleaner.py flashregion_2_intel_me.bin
  python2 dump_me.py flashregion_2_intel_me.bin -x
  python2 me_sigcheck.py FTPR_part.bin
  ifdtool -i ME:flashregion_2_intel_me.bin bios.rom
  exit # Skip this line if you're okay with bricking your motherboard.
  flashrom -p internal -w bios.rom.new

intelmetool:

  ME: FW Partition Table      : OK
  ME: Bringup Loader Failure  : NO
  ME: Firmware Init Complete  : NO
  ME: Manufacturing Mode      : NO
  ME: Boot Options Present    : NO
  ME: Update In Progress      : NO
  ME: Current Working State   : Initializing
  ME: Current Operation State : Bring up
  ME: Current Operation Mode  : Normal
  ME: Error Code              : Debug Failure
  ME: Progress Phase          : BUP Phase
  ME: Power Management Event  : Pseudo-global reset
  ME: Progress Phase State    : 0x3b
  ...
  ME has a broken implementation on your board with this BIOS
  ME: failed to become ready

Awesome!

  iptables -t mangle -A PREROUTING -p {udp,tcp} --dport 53 -j TPROXY --on-ip mitm-ip --on-port 53

Since dnscrypt transmits DNS requests over port 443, which is also used by HTTPS, ISPs can't redirect the packets without performing more costly fingerprinting, or else websites would break.

dnscrypt packets are also encrypted and authenticated, so the worst probable thing an ISP could do is, like you said, drop the requests.

https://en.wikipedia.org/wiki/Ahmed_Chalabi

https://www.amazon.com/Man-Who-Pushed-America-Extraordinary/...

I haven't seen the claim proven before, but, I'm not sure it needs to be: the man was an asset to Iran, knowingly or not.

https://stackoverflow.com/questions/23055651/disable-develop...

Chrome on Linux doesn't warn yet (I just tested it) and neither does Chromium.

Such exaggerated mimicry is a regular occurrence in American secondary schools. I saw his exact performance targeted at the "special" kids, some of whom were quite normal, many times in my youth. If Mr. Trump was raised in America, he would know not to use those kinds of expressions.

> You can either accept the evidence that they lied and manipulated the reader, or continue to follow the narrative. Choose wisely.

No, those are not the only narratives. Here's a third: Donald Trump, regardless of his intentions, briefly acted the part of the fool. The media, acting in their own self-interests, covered the story -- with dramatic embellishment -- which had practically been handed to them. Either way, it's his own damn fault.

In the second video, Mr. Trump just moves his hands around a bit, as you say.

I had not seen the first video until now, and I am unfamiliar with the disabled reporter, but I concluded right away that he was embodying someone with a physical/mental disability -- something like Parkinson's or cerebral palsy.

If he was not, then Donald Trump has only himself to blame, for behaving in a misconstruable manner.

GPG is used asynchronously. In many cases, everyone would need to be compromised to go after one person. That raises the chance of discovery.

A browser extension is a fantastically better idea. Google previously prototyped most of the work for this: https://github.com/google/end-to-end

GPG has a track record of being secure against many adversaries, including the NSA. It's used by most Linux distributions for package signing, so you probably already depend on it -- even if indirectly.

I don't expect GPG to be completely secure. But it's not based on deception.

It doesn't have any additional security benefits beyond regular webmail providers that provide TLS:

- Encryption is performed inside the browser. By delivering a modified JavaScript payload, it can steal encryption keys.

- No support for POP, IMAP, or SMTP. If you want to use GPG, you can't.

To see it being compared to Fastmail and Gmail, which don't engage in parlor tricks, is a travesty.

clang++: error: cannot assign to variable 'b' with const-qualified type 'const somestruct *const'

g++: error: assignment of member ‘somestruct::moo’ in read-only object