way66

we are working on facebook.... :)

CEO, Jumbo Privacy.

Thanks for your help. I need to think more about it someone also mentioned https://en.wikipedia.org/wiki/K-anonymity

Okay, good point. so maybe we should modify the created datetime of the event more or less 15minutes what do you think?

How would you trust me if I tell you that there isn’t any analytics?

You’re right. Like Dropbox has a free version, and a paid one. Right now we are launching the free version, and paid features will come later.

Absolutely, I’ve designed the product so that my mom can use it. She can’t use a Chrome extension, but she can download an app like Jumbo.

1/ I’m thinking about ways to have trustable 3-parties audit us. Open for more ideas. What do you think?

3/ yes, unroll.me made the wrong calls. But for Jumbo we can’t even access your data, everything happens client-side. You could say that at some point the client will upload all your to our cloud, but that’s really not going to happen. Again, here, how to trust us? First, audits. Second, my reputation. Third, independent researchers would reverse engineering our app, and look at the networks call made. Open for more feedback

Our business model is the one of Dropbox. Pay (you or your employer) for more features.

Hum... and then?

1/ What do you mean confirm what I'm saying for the IP address exactly?

2/ I said we don't use any (mobile) SDKs from 3-parties analytics, but we do use their backend (Segment, Amplitude). We send the requests from our anonymous proxy directly to their servers.

I was worried that mobile SDKs would leak other data (iOS version, device size, ...) that I don't want to know about. And as a general rule we don't like to use SDK/code from 3parties for security reasons.

3/ We use analytics to track how many users are using the app, and how many users are using the cleaning features. This data does help us to make strategic decisions.

Yes, I agree we need to add more options for Twitter. These will come in a future update, in May/June. Thanks for the feedback.

For Facebook, the full list of Settings we support is here: https://blog.jumboprivacy.com/smart-privacy-for-facebook.htm...

Jumbo disables ads personalization, face recogonization, and soon location data storage.

Feel free to ask me more questions.

Pierre CEO Jumbo

You are raising a good question..

Jumbo works 100% client-side, that's why we have built it as a native app.

You can read more on our architecture on our blog: https://blog.jumboprivacy.com/secure-jumbo-never-sees-your-d...

It's quite cool. We don't have any servers processing your data.

Pierre, CEO Jumbo.

No, we will NEVER do that.

Pierre, CEO Jumbo.

that's correct. like Dropbox. thanks for sharing that link ekovarski

Pierre, CEO

I guess I meant... we call a Apple API to ask for a anonymous Device UUID. Precisely: UIDevice.current.identifierForVendor?.uuidString

Do you still think that's "bullshit"?

why?

Jumbo helps in deleting old Google Search, and Alexa voice recordings. So it's beyond social media in that sense. Tomorrow we will support Tinder, and more.

We will open source later this year some part of the iOS app (the parts that changes stuff for you, and download personal data from your phone).

Yes, UNLESS you don't collect device type, OS version and IP address in the first place, which we don't.

Pierre, CEO Jumbo

What fingerprint? We don't send device OS, IP address, geolocation... Impossible to do fingerprint from only a device UUID that does not means anything.

No, because we've designed protection against collecting IP address, device type and OS. We don't use any SDK from Segment, Amplitude, or any third party analytics. Our iOS app only sends a device UUID, an event name (user:opened:app) and some event properties (not personal information). Someone should feel free to reverse-engineer our network requests to confirm what I'm saying.

Also, let's talk about IP address.

We have a CloudFlare worker that sits between our app and our analytics proxy (which role is to send data to Segment). And this worker from Cloudflare is a piece of code that removes the user ip address from the request made to our proxy, hosted on Heroku.

Here is the worker code: https://gist.github.com/pierrevalade/85bbe1e5278b81813e08e7e...

That way, only Cloudflare gets the user IP address (and to my the best of my knowledge I don't know how to access it), and our servers never get it.

Segment sends the data to Amplitude.

Pierre, CEO, Jumbo.

Pierre, here, CEO of Jumbo.

We use: UIDevice.current.identifierForVendor?.uuidString

for the deviceID

Let me know if you think that's not a good idea, but it seemed a unique app device that's completely a black box for us, Segment, or Amplitude.

hey! we're working on support for office 365 on desktop but no plans for support exchange on promise from our desktop app (sorry if that's confusing)

happy to chat more at support@sunrise.am

pierre - ceo @ sunrise

hey – pierre from sunrise here i agree – we will continue to support Google Calendar

hello - pierre from sunrise here we wish we could use a better scope just for milestones in github but unfortunately in order to have milestones and issues in Github API we need to ask for the private repo. https://developer.github.com/v3/oauth/#scopes feel free to ask Github about that too :)

Hey everybody, Pierre from @sunrise. This is the blog post we've just published to give more context:

"Users sometimes ask us why we require the user’s Apple ID and password in Sunrise, instead of using the local Calendar API. That’s a great question to ask, and we understand why users don’t want to share their credentials without context. We’ve thought a lot about that.

The two reasons why we are doing this are: - one, to provide a better user-experience - two, to offer a Sunrise experience everywhere, on all platforms (including web and Android)

Providing a better user-experience

Being able to access the data from our servers, instead of just client-side, has enabled us to write a better calendar app. We are working hard to make synchronization faster and more reliable, and it enables us to send push notifications or alerts to users without them having to open the app.

And this is just the beginning, a lot of new features that we are working on at Sunrise for the future will rely on our server-side infrastructure.

Sunrise everywhere

The two biggest feature requests we get from users are: “when is Sunrise going to launch on desktop” and “what about Android?”.

We understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that.

How does it work? Is this secure?

When you type in your iCloud credentials, they are sent to our server only once in a secured way over SSL. We use them to generate a secure token from Apple. This secure token is the only thing we store on our servers, we never store your actual iCloud credentials.

What’s next?

In the future, we are thinking about ways to take advantage of the local Calendar API for users who don’t want to share their credentials, we understand their point of view.

We are also hoping that Apple will leverage OAuth to authenticate their calendar API, which will make things easier for everyone. We already support OAuth with Facebook, Google, Twitter, LinkedIn, Foursquare and Producteev. We support OAuth where we can.

We are a team of 7 people building a calendar with love & passion, and unfortunately we can’t always move as fast as we want, but as always, we want to address users’ issues with transparency and openness. We’re listening on @sunrise or support@sunrise.am"

Could you explain what is the getInstagramString()? Thanks!

There are 3 tracks (fyi).

Is it fun to come before your interview and hang out with another applicants or everyone is so stressed (fixing the demo!) ?

Good question. I don't know. (intuition = yes).