[deleted]
Upspin – Another option for file sharing
151–160 of 170 posts
Re: Upspin – Another option for file sharing
#152I'm worried that there are no user-facing hashes, it seems.
Re: Upspin – Another option for file sharing
#153Earlier quoted context omitted.
Seems like that results in a different problem? Someone could take your email address.
Perhaps the new-user process requires authentication initially via email to confirm that you are in control of that address.
That is exactly how it's described in the documentation, yes.
Re: Upspin – Another option for file sharing
#154Earlier quoted context omitted.
I remember when OAuth was first announced, and the use case was basically this - although this was before social networks became unanimous so it was more like sharing your Flickr photos with a photo printing site. It was a nice idea 10 years ago before everyone built their walls. To describe the content, the idea was everyone would use microformats: http://microformats.org/wiki/hmedia
There's another interesting use-case: OAuth is in its extensions (OpenID Connect & XACML) can be used to create an attributes-based access control system (ABAC) (as distinct from an identity-based or roles-based one). The benefits of such a system are: - It can be privacy preserving. Say you want to buy booze from an online bottle shop. In real life, you'd usually flash your ID to meet the over 18/21 legal requiremen…
> without the overhead of maintaining an ever-growing list of roles
For me it sounds like roles are being replaced with new set of derived attributes (isOver18, is6feetTall) that you'd still need to compute when the government policy changes. Maybe the main benefit would be the possibility of reuse but that could also be achieved with a sufficiently sophisticated role system.
Re: Upspin – Another option for file sharing
#155Earlier quoted context omitted.
It's not a Google product. So no. (not that I'd agree with it not adhering to those roots currently. Just that this project has nothing to do with company policy)
"This is the official list of people who can contribute (and typically have contributed) code to the Upspin repository. The AUTHORS file lists the copyright holders; this file lists people. For example, Google employees are listed here but not in AUTHORS, because Google holds the copyright."
There is a difference between "a Google Product" and "Code to which Google holds copyright". Most importantly, the latter may include all code written by any Google Employee during their employment.
Re: Upspin – Another option for file sharing
#156Earlier quoted context omitted.
And you shouldn't. I wanted to link to various people who have experienced data loss in SpiderOak (me included) due to bugs in the client which have gone unsolved for at least three years. But....they seem to have redesigned their homepage and the forums that used to be available seem to have gone. Here is one example though: https://spekxvision.wordpress.com/2015/10/13/more-spideroak-... So I can only talk from a pe…
Agree, SpiderOak is far from good. Haven't yet experienced data loss, but their sync is very slow and, with custom synced folder (not the 'Hive' one) pretty unreliable. From Crashplan's web page I don't see if they do file sync, what do you recommend for this domain? I'd use OneDrive, but supported Linux client is a must.
You're right. I use Crashplan for backup. Haven't really found a solution for sync that I like. Missing Linux client is a problem for me as well.
Re: Upspin – Another option for file sharing
#157Earlier quoted context omitted.
What problem does this solve for the end-user that isn't already or better solved by Google Drive, Dropbox, or sharing in chat apps like Hangouts or WhatApp? Or is it like, "Here is some cool technology!" without identifying a clear user need this solves, like Google Wave?
Dropbox uses one key for all content... Google drive means google can see all of your stuff... Sharing in hangouts is just like drive... WhatsApp isn't close to this robust... Wave was just really far ahead of its time but you see the modern incarnation in google docs and paper. This is like the infra to build spideroak on your own hardware. It's not the same as a service where you have to trust the operator.
How about MEGA? It's sort of like multi-key Dropbox.
Centralized, but not inherently so; you could stand up clones using its same API, and then create a discovery service mapping bucket names (users, whatever) to servers using that API.
Re: Upspin – Another option for file sharing
#158Earlier quoted context omitted.
This doesn't really clarify what an "unofficial" Google project is. Does it mean that people don't work on it full-time and it's a 20% project? Does it mean that it was developed at home without using Google's resources, so they don't have an ownership interest in it, but they are letting it be hosted on their infrastructure and announced on their blog to be nice? Does it mean that Google isn't sure how long it will…
Looks like it's an open source project by individuals who also happen to be employed by Google, and the extent of Google's involvement is the copyright. Edit: looking at the LICENSE file, scratch that, it appears Google doesn't even own the copyright.
Not really. Google owns the copyright for all code contributed by Google employees on Google time, and currently they are the only copyright holder [1].
In order to contribute you have to sign the standard Google Contributor License Agreement (either [0] or the corporate version) which gives Google a perpetual irrevocable copyright and patent license. Since the project is BSD licensed anyway, unless you're contributing something you intend to patent, you're giving Google nothing by signing the CLA: you still own the actual copyright. (Based on my skimming the agreement; IANAL)
[0] https://cla.developers.google.com/about/google-individual [1] https://github.com/upspin/upspin/blob/master/AUTHORS
Re: Upspin – Another option for file sharing
#159It's a bit unclear how email-based identifiers should work when publishing long-lived, public files. In particular, which email address should you use? Will the general public learn your email address? What about people who want to post publicly and keep their email addresses private? What happens if you switch email providers? Also, there is there any provision for actually making public files available via https? H…
> Will the general public learn your email address?
Yes, if you store ann@example.com/dir/file and share the file path publicly then the valid email address "ann@example.com" leaks out. If you own your own domain then you could have one or more email address only associated with Upspin and store at files@mydomain.com/dir/file. The downside is the username in such paths is less recognizable to your friends than your regular email.
The reality today is anyone who uses any Google service or who has a Facebook page has an exposed @gmail.com or @facebook.com email address that can be spammed, and if he or she signs up for Upspin it's another way for it to leak out. You can use any email address that can receive the confirmation email; I'm not sure if yourusername@users.github.com is a valid email address, and there's no email address with your Twitter handle.
> What happens if you switch email providers?
You would execute a new `upspin signup -dir=dir.example.com -store=store.example.com you@newEmailAddress.com` command, keeping the same directory and storage servers. The question is whether you can tell your directory server and storage server to reuse or alias your directory and storage to those of your previous email address.
Re: Upspin – Another option for file sharing
#160Earlier quoted context omitted.
There's another interesting use-case: OAuth is in its extensions (OpenID Connect & XACML) can be used to create an attributes-based access control system (ABAC) (as distinct from an identity-based or roles-based one). The benefits of such a system are: - It can be privacy preserving. Say you want to buy booze from an online bottle shop. In real life, you'd usually flash your ID to meet the over 18/21 legal requiremen…
> without the overhead of maintaining an ever-growing list of roles For me it sounds like roles are being replaced with new set of derived attributes (isOver18, is6feetTall) that you'd still need to compute when the government policy changes. Maybe the main benefit would be the possibility of reuse but that could also be achieved with a sufficiently sophisticated role system.
I probably chose a bad example. Sticking with welfare, in many countries the payment is means tested. To simplify, let's imagine there's a policy that says "people earning over $1000 a month are not entitled to welfare". At some point politicians decide this is too generous and change it to $1500. In an RBAC, you have to the the roles audit and reassignment. Whereas in the ABAC, because you've already been collecting this attribute so you just change the policy and keep making access-control decisions as normal.