News for hackers. Stuff that matters.

pupeno

Re:Show HN: Unbreach, a Haveibeenpwned for Businesses on Thursday June 30, 2022 @11:53AM (#31934311)
I think for this crowd, haveibeenpwned.com for businesses is the best way to describe Unbreach. It even uses the haveibeenpwned.com API.

In Unbreach, after you signup, you upload a CSV with all the staff at the company (it’ll have integrations in the future) and Unbreach watches them all for breaches. For the owners/managers it provides a dashboard of all the staff and all the breaches showing you which ones are outstanding and which ones are closed. Here’s an example:

https://uploads-ssl.webflow.com/627d527181555e3edd9c2c5a/627...

For the staff, it provides a TODO list, where each breach is a password that needs changing. It looks something like this:

https://uploads-ssl.webflow.com/627d527181555e3edd9c2c5a/627...

Unbreach supports monitoring email addresses that don’t belong to a person (info@ for example) but are supervised by a person that gets the alerts for it.

If you are familiar with haveibeenpwned this might remind you of domain monitoring. It’s similar in that Unbreach monitors many different email addresses. What Unbreach adds on top of haveibeenpwned is the todo-list aspects and the dashboard.

I built Unbreach because I found myself constantly chasing people at the companies I work for to check that they changed their password after a breach. It’s still rough around the edges. If you give it a try and get stuck or something doesn’t work, please send me a message through the bubble on the bottom right and I’ll help you.

Thank you. I'm trying to get it out by the end of July at the latest.
It's linked on the landing page, but to save you searching for it, the sample chapter is on: https://pablofernandez.tech/2022/06/09/one-on-one-meetings-a...
Hello HN. I've been working remotely since the early 2000s and managing teams since 2011 or so, mostly remotely (whenever I can). During the pandemic I helped the non-remote parts of my company become remote and then I jumped online to help anyone that I could with the transition (this wasn't a service, I did it for free, it was important to me and the world was hurting).

Out of those conversations I ended up with the table of contents of what then became this book. The writing part of the book is done, most of the proof reading has been finished, and I just sent it to be formatted for print and ebook.

I also bought a bunch of ISBNs and registered my consulting company as a publisher to _self-publish_. I don't know why, but I'm finding the process very interesting. I love learning about how other parts of the world work.

What should I call my app?

I'm finishing building a (free) app that checks on you automatically, by email, and when you are not doing well it lets your closest friends know you can use a phone call. I have a name for it, but I might want a better one. What would you call it?

( Read More... | 7 comments | 7 points | on HN )

Should we create change request tickets for each release?

My company is trying to get some processes in order, have more accountability, be better in general. It's a good thing and I'm helping, even leading some of the projects. But now I am being asked to make a change request ticket for each software release. I dislike the idea, am I wrong?This is what we currently do:- All code is in github.- All issues are in Jira.- Almost all commits are...

( Read More... | no comments | 7 points | on HN )
That is correct. It applies whenever a computer program goes from US soil to non-US soil. Wether it's Apple's App Store, Google Play or carrier pigeon, it's the same.
I think the process had two issues. The main one being several steps that though simple, were not specified anywhere, so, figuring them out took a lot of time and phone calls. It's like someone tells you to drive from point A to B, that's easy, but they don't tell you were the car is.

The second problem was a lot of jargon that was in my opinion unnecessary and was internal US government leaking to the end users and you had to learn it to understand the documentation about what to do. Figuring out what SNAP-R stood for took me way to long and it's nothing more than a website registration (from my point of view).

To add to that, maybe Apple is more liable because of their promises to check for quality and problems in the store, while Google allows more things in it. That just means a change for them, you, as the app maker, are always liable.
Apple requires the ERN because Apple is very US centric. For Google, there might be cases in which the ERN is not required because the app never leaves the US (because for other countries it comes from other countries).

Apple is required the ERN to cover their asses, I believe. The ERN is required by the US government, so, if you don't have it, you are breaking the law whether you are using Google Play or Apple. So, you should get it for Google Play too.

My personal opinion, which is not that of a lawyer, is that yes, nearly every app developer will need an ERN.
But everybody is vulnerable to Apple pulling your app because it's non-compliant.
I talked to the export compliance department at Apple. There's a chance that they say "yes, get an ERN" because they have nothing to lose and it's safer for them and in fact, there's no need for it. But I doubt it. I will consult a lawyer to make sure my whole process is good if people want me to get ERNs from them (an idea some people floated with me).
If you are pulling through http and http only, yes. If you are using HTTPS, you are encrypting the requests that may contain arbitrary amount of data and the exception doesn't apply to you anymore.
First, if all your app does is download encrypted information and decrypt it, you might be covered under one of the exceptions.

Obviously the App Store is using HTTPS, so it's not. The App Store is a program by Apple and I'm sure Apple has an ERN to cover their asses.

They don't enforce it at all. Not even the US BIS really looks at your application to approve it as far as I can tell, because mine was approved instantly. They do have a lot of checks to make sure the record of your company and app are somewhat well formed.

When it comes to Apple, they don't check for this, they just want you to be on the record with either an ERN or the claim of no encryption, so that it's not their fault if the US government comes and says "hey, about all those apps you are exporting, are they using munition-level tech?"

This is true, and I think a lot of this applications are breaking the rules. You can easily claim your app doesn't use encryption and Apple will accept it. They don't check to see whether it does or doesn't use encryption. But should something happen, Apple is clear of guilt because they asked you and you would be the one producing a false statement.

I read a lot of blog posts and looked at a lot of information and there's a general advice of "just pretend not to use encryption" or "https doesn't count" which is just wishful thinking from people that didn't want to use ERN and when you go dig deep enough it doesn't hold any water.

What would you rather do, argue with the US government or get an ERN and focus on your business? I know my answer ;)
I talked to a couple of people at Apple and they explicitly told me that use of HTTPS is not covered under the exception. I think that exception was designed to authenticate licences of software. Programs that phone home, get a toke, and decrypt it to verify you paid for it, but that's just a hypothesis.
Throughout the process I found left-overs from the previous processes and yes, it looked much worse. The worst part for me is that there were steps in the process than though simple, they were not defined anywhere and thus it required me calling various departments to ask for clarifications.
For exporting to friendly countries via App Store, you'll need an ERN. I'm not sure if the App Store will accept submission from unfriendly countries. It depends which one I guess.
Yes, it does. I talked to legal as well as export compliance department at Apple and they confirmed this. Maybe they were being overly cautious but so was I.

With HTTPS, what puts you clearly out of every potential exception, is the fact that you are encrypting the requests. Someone asked about this in the blog and I replied with more information.

Last year I learned that to publish an app in the App Store or Mac App Store, if it uses encryption of any kind and yes, HTTPS and SSL count, you need an Encryption Registration (ERN) from the US Bureau of Industry (BIS). Some people claim it's fine to lie to Apple, claim no use of encryption and get in the app store. I'd rather do it the right way.

When I started the process of getting the ERN, I quickly notice it was going to be a long and arduous process and that other people could benefit from the lessons I was learning the hard way, so I decided to document it all in a long blog post.

This is probably one of my most researched pieces ever. The whole process took about two months from the start, researching this thing called ERN, to getting the app published in the Mac App Store, satisfying that what I did was (more or less) correct.

I followed your advice here, I removed the investors part and added a short explanation before each video. I also got the videos transcribed, so that content is in the page as well (for SEO).

Older »